A correction request is a request from an individual to change or amend personal information held by an organisation. The organisation must decide on the request within 20 working days and notify the requester. If the request must be transferred to another organisation, that transfer must happen promptly and within 10 working days.
What a correction request means
A correction request is the formal process an individual uses to ask an organisation to amend inaccurate personal information it holds about them. It is part of data rights handling, but it also depends on accurate records, timely review, and clear ownership.
In practice, the request may be straightforward when the error is obvious, or more nuanced when the organisation needs to verify source records, reconcile conflicting systems, or decide whether the record should be updated, annotated, or left unchanged with an explanation.
Why correction requests matter
Correction requests sit at the intersection of data quality, privacy rights, and operational trust. When organisations hold inaccurate personal data, the risk is not only a poor user experience, but also downstream errors in decisions, communications, compliance handling, and customer support.
They also create a governance expectation: the organisation must be able to identify where the personal information lives, determine whether the requested change is justified, and ensure that the correction is reflected consistently across systems that rely on the same record.
How organisations handle a correction request
The practical workflow usually starts with intake, then validation, then action. The organisation needs a way to receive the request, confirm the requester’s identity where appropriate, locate the affected data, and assess whether the information is in fact inaccurate or incomplete.
When the request is accepted, the correction should be applied to the relevant record and, where needed, propagated to downstream systems or recipients that received the incorrect version. If the request cannot be completed as asked, the organisation should still respond clearly and explain the outcome.
Correction requests and record transfer
Correction requests often reveal a broader records-management problem: the same personal data may exist in multiple systems, ownership boundaries may be unclear, and one team may be relying on another team’s data source. That is why transfer handling and internal routing matter, not just the final edit.
If a request needs to be transferred to another organisation, the handoff should be prompt and controlled so the individual does not lose their place in the process. This is especially important where inaccurate data can spread quickly across linked services or shared workflows.
Risk and Threat Considerations
Correction requests can expose a control gap if organisations treat data amendment as a simple admin task rather than a governed rights process. The main risks are stale personal data persisting across systems, incorrect decisions being made from bad records, and incomplete routing that delays the individual’s ability to get the record corrected.
Failure mechanism: A correction is approved in one system but not propagated everywhere the same personal information is used, or the request is misdirected and never reaches the team or organisation that controls the source record.
Impact: Incorrect personal data continues to drive communications, decisions, and compliance records, which can create legal exposure, customer harm, and operational rework.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while GDPR and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| GDPR | ART.16 — Right to Rectification | Defines the right to request inaccurate personal data be corrected. |
| Recommendation — Assess rectification requests promptly and update inaccurate personal data without undue delay. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Supports controlled handling of who may change personal records. |
| AU-2 — Event Logging | Correction workflows need auditable records of data changes and request handling. | |
| Recommendation — Restrict who can amend personal data and enforce change authorization. Log correction requests and resulting record changes for traceability. | ||
| NIST CSF 2.0 | GV.RR-01 — Roles, Responsibilities, and Authorities | Correction handling depends on clear ownership for reviewing and acting on requests. |
| Recommendation — Assign ownership for intake, review, approval, and propagation of corrections. | ||
| ISO/IEC 27001:2022 | A.5.34 — Privacy and protection of PII | Correction requests are a PII governance activity under privacy protection controls. |
| Recommendation — Implement procedures to handle personal data correction and related privacy rights. | ||
Practitioner Guidance
Why practitioners should care: A correction request is only useful if the organisation can trace the record, verify the change request, and complete the update within a controlled process. That means the real task is not just editing data, but ensuring the correction is durable across the systems that depend on it.
Common misunderstanding: Teams sometimes assume a correction request can be handled locally by the system that received it. In practice, the organisation needs a consistent method for deciding whether the request is valid, whether any exception applies, and where the corrected value must be reflected next.
Practitioner takeaway: Treat correction handling as a governed records workflow, not a one-off data fix, so the amendment is accurate, timely, and auditable.
Related resources from NHI Mgmt Group
- What is the difference between network trust and request-level identity trust?
- Why do access-request workflows matter for NHI governance?
- How should organisations use AI in access request approval without weakening control?
- What is the difference between access request automation and access governance?