The right of an individual to request correction of inaccurate personal information held by an organisation. If the organisation does not agree to change the record, it must take reasonable steps, which may include appending a correction statement. This right helps preserve data accuracy and fairness in operational decision making.
Expanded Definition
Principle 7, Correction Right, is the privacy and records-governance right to challenge inaccurate personal data and ask an organisation to correct it. In practice, the organisation must either update the record or take a reasonable step such as attaching a correction note when it disputes the change.
This principle matters because data quality is not just a back-office issue, it can shape eligibility, pricing, access, fraud review, and other operational decisions. The correction right is narrower than deletion and different from a simple customer service request: it focuses on accuracy, traceability, and fairness in the record itself.
Definitions and procedures vary across jurisdictions and policy regimes, but the common expectation is consistent, organisations should have a way to receive the request, assess evidence, document the outcome, and preserve the integrity of the record when a dispute remains unresolved. Where accuracy affects downstream automated decisions, correction handling becomes part of the control environment, not just a clerical task.
A useful boundary to remember is that the right concerns personal information held by the organisation, not every opinion, internal note, or independently verified fact. The practical question is whether the record is being used as a decision input and whether it is wrong, incomplete, or misleading in a way that matters.
Examples and Use Cases
- A customer disputes an address, date of birth, or account status entry that is driving a service decision, so the organisation corrects the field or appends a note that preserves the dispute history.
- A financial institution receives a correction request after an onboarding review, and the case file is updated so the inaccurate record does not continue to influence risk scoring or manual review.
- A healthcare or insurance record contains outdated demographic information, and the correction workflow ensures the current record is used for correspondence, eligibility, and billing.
- A data subject provides evidence that a profile attribute was imported incorrectly from a third-party source, and the organisation must reconcile source-of-truth conflicts rather than silently overwrite the record.
- A dispute remains unresolved, but the organisation still needs to keep the original entry for auditability, so it appends a correction statement instead of deleting the historical record outright.
One implementation tradeoff is that correction workflows must balance accuracy with provenance. If teams overwrite records too aggressively, they may lose the history needed for audits or investigations; if they never correct obvious errors, those errors keep propagating into operational systems.
Security Implications
Mismanaging the correction right can turn inaccurate data into a security and governance problem. Bad records can cause false denials, failed verification, misrouted communications, incorrect risk assessments, or poor escalation decisions. In regulated environments, the impact can extend to complaints handling, audit exposure, and inconsistent treatment of individuals.
For security teams, the key issue is not only whether the data is wrong, but whether the organisation can show how it assessed the request and what it did with disputed information. Weak case handling often looks like inconsistent decisions, missing evidence trails, stale data remaining in production systems, or downstream systems continuing to consume an uncorrected attribute.
EU General Data Protection Regulation (GDPR) is a useful authority for understanding how accuracy, rectification, and storage discipline fit together in practice, especially where personal data is used for automated or high-impact decisions.
Practitioner observation: correction handling becomes much harder once the same personal attribute has been copied into many applications. The security and governance risk is usually not the original mistake, it is the persistence of that mistake across reporting, decisioning, and support workflows.
Security, Operational and Governance Implications
Principle 7 is fundamentally about control over record quality, evidence, and accountability. Organisations need to know who can approve a correction, how disputed records are flagged, and how a corrected value is propagated without destroying auditability. That makes the topic relevant to governance as well as privacy.
Operationally, the best correction processes separate factual correction from dispute annotation. That distinction helps preserve lineage while still preventing a known inaccurate value from driving future decisions. It also reduces the chance that frontline teams improvise inconsistent fixes.
CISA Secure by Design is a helpful lens here because systems should make correction, traceability, and safe default handling easier by design rather than relying on manual cleanup after data has already spread.
Where personal data underpins automated workflows, the correction right becomes part of data integrity management. A well-run process supports fairness, prevents stale decisions from accumulating, and gives the organisation a defensible way to maintain both historical integrity and current accuracy.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8, NIST SP 800-63 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 — Organizational Context and Risk Management Strategy | Accuracy and correction handling affect organisational risk and decision quality. |
| ID.AM-08 — Assets and Records Are Inventoried and Managed | The right depends on knowing where personal data is stored and used. | |
| PR.DS-01 — Data-at-Rest Protection | Corrected records still require integrity and controlled handling across storage layers. | |
| Recommendation — Treat correction requests as a governed data-quality risk and route them into accountable ownership. Map personal-data records and downstream consumers so corrections reach every relevant system. Protect record integrity so corrections are preserved without uncontrolled overwrites. | ||
| CIS Controls v8 | 6.1 — Data Recovery and Integrity | Correction workflows need reliable record integrity and recoverable history. |
| Recommendation — Preserve correction history and validate that updated records remain consistent across systems. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | Correction requests often depend on how confidently the organisation can link a person to a record. |
| AAL — Authenticator Assurance Level | Correction portals and disputes rely on authenticated access to personal records. | |
| Recommendation — Use appropriate assurance before accepting high-impact record corrections. Require strong authentication for sensitive correction workflows and record disputes. | ||
| NIST SP 800-53 Rev 5 | AU-11 — Audit Record Retention | Correction handling needs a durable trail of what changed and why. |
| Recommendation — Retain audit evidence for disputed and corrected records so decisions remain explainable. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 15, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
