Section 12 — Right to Correction and Erasure of Personal Data

Like Section 11's access right, Section 12 applies to personal data processed on the basis of the Data Principal's own consent — including the voluntary-provision consent under Section 7(a) — in accordance with any requirement or procedure under other applicable law. It's the same scoped relationship Section 11 works within, just pointed at correction and erasure instead of visibility.

Correct, complete, update — 12(1) and 12(2)

A Data Principal has the right to correction, completion, updating and erasure of her personal data. On receiving a correction request, the Data Fiduciary must: (a) correct inaccurate or misleading personal data; (b) complete incomplete personal data; and (c) update the personal data. These three are framed as duties, not discretionary courtesies — once a request identifies what's wrong, fixing it isn't optional pending internal review.

Erasure on request — 12(3)

Separately, a Data Principal can request erasure of her personal data in the manner prescribed, and the Data Fiduciary must erase it unless retention is necessary for the specified purpose or for compliance with law. This sits alongside, not on top of, the Fiduciary's own proactive erasure duty under Section 8(7) — that duty triggers automatically once consent is withdrawn or the purpose is reasonably assumed to no longer be served, regardless of whether the Data Principal asks. Section 12(3) is the reverse angle: it gives the Data Principal her own lever to request erasure at any time, even before the purpose has naturally run its course, subject to the same two exceptions.

What doesn't meet the bar

A blanket refusal to erase data with no legal basis cited doesn't satisfy this section, and neither does forcing account closure as a precondition for deletion, or retaining data "just in case" a purpose might resurface later. The retention exceptions are specific — an ongoing specified purpose, or a genuine legal retention requirement — not a general reservation of discretion.

Erasure also has to actually propagate. Section 8(7)(b) requires a Data Fiduciary to cause its Data Processors to erase any personal data it made available to them for processing, which means a request answered by deleting a front-end profile while backups, logs and analytics copies sit untouched hasn't really been fulfilled — deletion that doesn't reach every copy the data was shared into isn't erasure in the sense this section and Section 8(7) together require.

Why this matters in practice

Correction and erasure requests are where the gap between a privacy policy's promises and a company's actual data architecture shows up fastest — a request is easy to answer at the account-profile layer and much harder to answer once the same data has fanned out into a data warehouse, a marketing tool, and a processor's own systems. Getting this right depends on knowing, ahead of time, everywhere a given piece of personal data actually lives.

Illustration: a customer notices her billing address is out of date on an e-commerce account and requests a correction. The company must update it under 12(2)(c). If she separately asks the company to erase her account entirely, the company must comply under 12(3) unless it can point to a genuine reason — for instance, a tax-record retention law — that requires keeping some of her data regardless of her request.

How Section 12 connects to the rest of the Act

Section 11 supplies the visibility a Data Principal typically needs before she knows what to correct or ask to have erased. Section 8(7) and 8(8) set the Fiduciary's own, request-independent erasure duty running in parallel to this section's request-driven one. Section 13 gives the Data Principal a grievance route if a correction or erasure request under this section goes unanswered or gets refused without a valid basis.