What to Do When a Correction Request Involves Disputed Facts
Section 12 gives Data Principals a right to correction, but the Act also requires them to submit only verifiably authentic information. Here is how to handle the request when the two sides disagree on the facts.
The legal framing of a disputed correction
Section 12 gives a Data Principal the right to have their personal data corrected, completed, and updated. That right is not unconditional on the requester's side either - Section 15 obliges the Data Principal to furnish only verifiably authentic information when exercising this right, which gives the Data Fiduciary a legitimate basis to ask for supporting evidence rather than simply accepting an assertion at face value.
The practical tension shows up when the record you hold and the correction being requested rest on genuinely conflicting evidence - a changed address that a delivery log contradicts, or a corrected date of birth that clashes with an earlier verified document. Neither side is automatically right, and the process needs to be built to handle that ambiguity rather than assume good faith or bad faith by default.
Gathering evidence without stalling the request
The first step is to ask the Data Principal what supporting documentation backs the requested correction, and to be specific about what would resolve the dispute rather than issuing a vague request for more proof. A specific ask - the underlying document type, a reissued certificate, a bank statement - moves things forward faster than a generic request for verification.
At the same time, check your own records for the source of the data being disputed. If the original entry came from a third-party data source or a processor, that is worth flagging early, since correcting it may require reaching back into that upstream relationship rather than just editing a local field.
When the dispute cannot be resolved on the merits
Sometimes the evidence on both sides is genuinely inconclusive. In that situation, document the basis for whatever decision you make - accept the correction, decline it, or apply a partial correction with a note - and communicate that reasoning to the Data Principal in plain terms rather than a form rejection.
A Data Principal who disagrees with your decision retains the right to escalate through your grievance mechanism under Section 13, so treat your written reasoning as something that may be reviewed later, either internally or by the Board. A decision with a documented, defensible rationale survives that scrutiny far better than a silent denial.
Building consistency across similar cases
Disputed correction requests are rare enough that many organizations handle each one from scratch, which produces inconsistent outcomes for similar fact patterns. A short internal standard - what counts as sufficient evidence for a name correction versus a date-of-birth correction, for instance - reduces that variance and gives your team something concrete to point to when a decision is questioned.
It also helps to loop in whoever owns data quality more broadly, since a disputed correction can be an early signal of a systemic data entry or ingestion problem rather than a one-off error.
Where to go next
The Evidence Tracker on this site is built for exactly this kind of situation - keeping a clear record of what was requested, what evidence was submitted, and how the decision was reached, so the file is ready if the case is ever escalated.