Article 16: Right to rectification

Article 16 is straightforward on paper and easy to fail in practice. The requirement is not “have a privacy policy that says you correct data.” It is: when a data subject tells you their personal data is inaccurate, you must be able to correct it without undue delay, and you must also be able to complete incomplete data, including by collecting a supplementary statement when that is the right fix for the processing purpose. (Regulation (EU) 2016/679, Article 16)

For a CCO or GRC lead, operationalizing Article 16 usually breaks in three places: (1) unclear role and scope (controller vs. processor, which datasets, which products), (2) fragmented systems and downstream sharing (data corrected in one system but not in analytics, logs, tickets, or a third party), and (3) weak evidence (no clear record of what was asked, what was changed, why, and when). This page gives you requirement-level guidance to stand up a rectification process you can run repeatedly, defend during audits, and scale across business units and third parties.

Regulatory text

GDPR Article 16 (excerpt): “The data subject shall have the right to obtain from the controller without undue delay the rectification of inaccurate personal data concerning him or her. Taking into account the purposes of the processing, the data subject shall have the right to have incomplete personal data completed, including by means of providing a supplementary statement.” (Regulation (EU) 2016/679, Article 16)

Operator interpretation (what you must do):

• Accept requests to correct personal data from the individual (or an authorized agent).
• Determine whether the data is inaccurate for the relevant purpose, or incomplete for the relevant purpose.
• Correct it, or complete it (including a supplementary statement where completion is appropriate), without undue delay.
• Make the correction effective across the places the data is used, not only where it was first collected.
• Keep a defensible record of the request, your decision, and the changes.

Plain-English interpretation of the requirement

Article 16 gives people the right to fix bad data about themselves. “Rectification” covers obvious corrections (wrong address, misspelled name, incorrect date of birth) and also “completion” (your record is missing a needed field or context, and the individual provides an additional statement that completes the record for the processing purpose). (Regulation (EU) 2016/679, Article 16)

Two practical points matter:

1. Purpose matters. Accuracy is judged against why you are processing the data. Data can be “accurate enough” for one purpose and misleading for another. Your workflow needs a way to route purpose-specific questions to the business owner of that processing.
2. Completion is not always overwriting. Sometimes the right operational fix is to append a supplementary statement rather than replacing a prior entry (for example, “customer disputes this field” or “updated documentation provided on [date]”), especially when you must preserve an audit trail or record integrity.

Who it applies to (entity and operational context)

Applies to:

• Controllers: You decide purposes and means of processing personal data; you are directly responsible for fulfilling Article 16 requests. (Regulation (EU) 2016/679, Article 16)
• Processors (operationally impacted): Even though Article 16 is addressed to controllers, processors must support controllers contractually and technically because the controller cannot rectify data in systems the processor operates. Map this as a service obligation in your data processing agreements, and ensure your tooling supports correction workflows.

Operational contexts where rectification must work end-to-end:

• Customer and user accounts (profiles, billing, identity attributes)
• HR and applicant tracking data (employees, contractors)
• Support systems (ticketing tools that store personal data in free text)
• Marketing systems (lead records, suppression lists)
• Risk, fraud, and trust & safety systems (where “supplementary statement” patterns are common)
• Analytics and data warehouses (derived datasets that may need reprocessing)
• Third parties that receive personal data (payment processors, fulfillment providers, CRMs, cloud platforms)

What you actually need to do (step-by-step)

1) Establish role-and-scope for Article 16 (foundation control)

Create a register that answers, per product/process:

• Are we a controller, joint controller, or processor for this dataset?
• What personal data categories are in scope?
• What systems store it (systems of record and secondary stores)?
• Which third parties receive it and for what purpose?

This prevents the common failure mode where the privacy team accepts a request but cannot execute it because ownership and system coverage are unclear.

2) Build a rectification intake and triage workflow

Minimum intake requirements:

• One or more public channels (web form, email, portal) that are monitored.
• Structured fields: requester identity, data to correct, proposed correction, context/purpose, supporting documentation (optional), and whether the requester wants to add a supplementary statement.

Triage rules:

• Route by data domain (billing, HR, support, trust & safety).
• Flag high-impact data elements (identity, eligibility, financial) for stronger verification and approvals.
• Decide whether the request is “correction,” “completion,” or “dispute requiring supplementary statement.”

3) Verify identity and authority (without collecting excess data)

Operational goal: confirm the requester is the data subject (or authorized agent) using reasonable methods aligned to the risk of the data being changed. Avoid building a process that asks for new sensitive data when it is not needed. Record what you did to verify, and why it was sufficient for this request type.

4) Assess accuracy/incompleteness against processing purpose

Assign a decision owner per processing activity (often the business process owner, with privacy oversight). Decision outcomes:

• Approve correction: data is inaccurate for the purpose.
• Approve completion: data is incomplete for the purpose; collect missing info or accept supplementary statement.
• Reject: request is not supported, the data is already accurate for the purpose, or you cannot validate the proposed change.

Your file should show the rationale, not just the conclusion. Keep the language factual and purpose-tied.

5) Execute the change across systems (including derived and downstream stores)

This is the “real work” control.

Build a system propagation checklist:

• System of record update (authoritative source)
• Replication targets (CRM, ERP, billing, IAM, marketing)
• Unstructured stores (support tickets, call notes, document stores)
• Analytics/warehouse refresh and derived tables where feasible
• Logging/monitoring references (where correction is possible and appropriate)
• Third party notifications or update requests, based on your sharing map

Practical pattern: create “rectification tasks” per system owner with completion evidence (screenshots, change logs, tickets, API logs). If your environment is complex, use a workflow tool (including Daydream) to generate and track these tasks from the scope register, so requests don’t stall in coordination loops.

6) Handle “supplementary statement” correctly

When completion by supplementary statement is appropriate, define:

• Where the statement is stored (and how it is linked to the original data)
• Who can see it (role-based access)
• How it is presented to downstream users of the data (so they don’t act on outdated information)
• Whether it triggers re-decisioning (credit, eligibility, account actions)

7) Close the request with a clear outcome record

Close-out package should include:

• What was corrected/completed
• Effective date and systems updated
• If rejected: why, tied to processing purpose
• Any residual limitations (for example, immutable records where you recorded a supplementary statement instead of overwriting)

Required evidence and artifacts to retain

Keep these artifacts per request as an “evidence packet”:

• Intake record (timestamp, channel, request details)
• Identity/authority verification record (method, outcome)
• Decision record (approve/reject; correction vs completion; rationale tied to purpose)
• Execution evidence: change tickets, system logs, screenshots, database audit logs, workflow task completions
• Downstream propagation record: list of systems and third parties notified/updated, with completion evidence
• Communications to the requester (acknowledgement, clarifications, final response)
• Exceptions and remediation notes (what failed, how it was fixed)

Program-level artifacts (auditors ask for these first):

• Article 16 role-and-scope register (systems, data categories, third parties)
• Written operating procedure with owners and escalation paths
• Training/enablement for request handlers
• Metrics dashboard (qualitative is fine): backlog visibility, aging, and exception trends

Common exam/audit questions and hangups

Expect questions like:

• “Show me your Article 16 procedure and who owns each step.”
• “How do you ensure rectifications propagate to analytics and third parties?”
• “How do you decide whether data is ‘inaccurate’ versus ‘disputed’?”
• “What is ‘without undue delay’ in your operating model, and how do you prevent stalling?”
• “Show three recent rectification cases end-to-end, with evidence.”

Hangups that trigger deeper testing:

• Free-text systems (support tools) with personal data scattered in notes
• Multiple “sources of truth” with conflicting fields
• Third parties that cannot update records promptly or have unclear contracts
• Business teams making silent changes without evidence

Frequent implementation mistakes and how to avoid them

1. Only correcting the front-end profile. Fix: build a system propagation checklist tied to the scope register; require closure only after task completion evidence is attached.
2. Treating rectification as a pure privacy task. Fix: assign data domain owners (billing, HR, product) and make them accountable for accuracy decisions for their purpose.
3. Over-collecting identity proof. Fix: use risk-based verification and document the method; avoid creating new sensitive data stores.
4. No handling for “completion” via supplementary statement. Fix: define where supplementary statements live, how they are displayed, and who reviews them.
5. No third-party loop. Fix: add contractual and operational steps for processors/third parties; track confirmations.

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog, so this page does not list specific cases.

Operational risk is still concrete:

• Consumer harm risk: inaccurate data drives wrong decisions (billing errors, eligibility decisions, account restrictions).
• Regulatory defensibility risk: if you cannot show an auditable trail of “request → decision → correction propagated,” you will struggle to demonstrate compliance with Article 16’s “without undue delay” standard. (Regulation (EU) 2016/679, Article 16)
• Third-party risk: if a processor hosts the authoritative dataset and cannot correct it quickly, your controller obligations become hard to meet in practice. Treat this as a due diligence and contracting issue, not just a DSAR workflow issue.

Practical 30/60/90-day execution plan

First 30 days (stabilize)

• Publish a single intake path and internal routing (even if manual).
• Stand up the Article 16 role-and-scope register for top systems and top data domains.
• Draft the operating procedure: verification, decisioning, execution, propagation, closure evidence.
• Identify your top third parties that store or operate on personal data and confirm they can support rectification requests.

Days 31–60 (operationalize)

• Build the system propagation checklist per data domain and assign system owners.
• Implement evidence packet standards in your ticketing/workflow tool.
• Add a “supplementary statement” pattern and approval rules for dispute-like cases.
• Run tabletop exercises using realistic requests (billing address change, name correction, support ticket correction).

Days 61–90 (scale and harden)

• Expand scope register coverage to secondary stores (data warehouse, marketing tools, support platforms).
• Add QA: periodic sampling of closed requests to confirm propagation and evidence completeness.
• Formalize third-party workflows: notification templates, tracking, and contract updates where needed.
• If you need automation and audit-ready packaging, configure Daydream to generate system tasks from your scope register and compile evidence packets consistently across teams.

Frequently Asked Questions

Do we have to overwrite historical records to comply with Article 16?

Not always. If overwriting breaks record integrity or auditability, completion via a supplementary statement can be the right approach, as long as downstream users can see the corrected context and stop relying on the inaccurate data. (Regulation (EU) 2016/679, Article 16)

What counts as “without undue delay” for rectification?

Article 16 requires prompt action but does not define a specific number of days in the provided excerpt. Operationally, you should define internal targets by request risk and complexity, then track aging and escalations so requests do not stall. (Regulation (EU) 2016/679, Article 16)

How do we handle rectification when data is spread across multiple systems?

Treat propagation as a control, not an ad hoc task. Maintain a scope register and a per-domain checklist of systems and third parties, then require closure evidence from each system owner before you mark the request complete.

If we’re a processor, do we need our own Article 16 process?

You need an operational capability to support the controller’s Article 16 obligations because the controller cannot rectify data inside your platform without your help. Make it a contracted service obligation and test it during onboarding and periodic reviews.

Can we refuse a rectification request if we believe our data is correct?

You can reject a proposed correction when the data is accurate for the processing purpose, but you must document the assessment and rationale. If the issue is more “dispute” than “correction,” consider completion via supplementary statement where appropriate. (Regulation (EU) 2016/679, Article 16)

Do we need to notify third parties we shared the data with?

Article 16 itself focuses on rectification by the controller. In practice, if you shared the inaccurate data and can reasonably update recipients, you should operationalize that step because leaving downstream recipients unchanged defeats the correction’s effect; track it through your sharing map and third-party workflow.