Skip to content
AuditFront
P5.2 SOC 2

SOC 2 P5.2: Privacy - Correction of Personal Information

What This Control Requires

The entity corrects, amends, or appends personal information based on information provided by data subjects and communicates such corrections to third parties, as committed or required, to meet the entity's objectives related to privacy.

In Plain Language

Inaccurate personal data is a problem for everyone - the individual whose information is wrong, and your organisation making decisions based on bad data. When someone tells you their data is incorrect, you need to fix it everywhere, not just in one database. This means providing a way for individuals to request corrections, updating the data across all systems where it exists, and notifying any third parties who received the incorrect information. For straightforward changes like name or address updates, self-service through account settings is the most practical approach. For more complex corrections, you need a formal request process with clear timelines. Auditors check that corrections actually propagate across all your systems, that third parties are notified when they received bad data, that requests are handled within legally required timeframes, and that you keep an audit trail of what was changed, when, and by whom.

How to Implement

Set up a correction request process. Define how people can request changes (self-service portal, email, support ticket), what information you need to process the request, how you verify the correction is accurate, and how quickly you will complete it. For simple changes like contact details, let users update their own profiles directly. Build correction propagation into your systems. When personal data is corrected in one place, the change needs to reach every system holding that data. Map your downstream systems, integrated partners, and third-party recipients. Automate propagation where possible - manual processes break down as you scale. Notify third parties when you shared incorrect data with them. If a vendor, partner, or service provider received the wrong information, tell them about the correction and ask them to update their records. Keep a record of these notifications and any confirmations you receive back. Plan for disputes. Sometimes you will believe your data is accurate and the individual disagrees. Provide an explanation and an opportunity to appeal. If you cannot resolve the disagreement, append the individual's statement of disagreement to their record. Document how the dispute was handled. Maintain an audit trail. Record every correction request, the original and corrected values, when the change was made, who made it, and which systems and third parties were updated. This supports both audit requirements and any future questions about data accuracy. Enable self-service correction for common data elements. Let authenticated users update their profile, contact details, and preferences without filing a formal request. Add validation rules to ensure the changes produce valid data, and log everything through your audit system.

Evidence Your Auditor Will Request

  • Correction request process documentation with submission channels and timelines
  • Evidence of correction propagation across all systems containing the affected data
  • Third-party notification records when corrections affect shared data
  • Self-service correction capabilities in user-facing applications
  • Correction request tracking log with audit trails of changes made

Common Mistakes

  • Corrections are made in one system but not propagated to other systems containing the same data
  • Third parties who received incorrect data are not notified of corrections
  • No formal process for handling correction requests, leading to inconsistent responses
  • Self-service correction is not available for common data elements like address and name
  • No audit trail of corrections, making it difficult to verify what was changed and when

Related Controls Across Frameworks

Framework Control ID Relationship
ISO 27001 A.5.34 Partial overlap
nist-csf GV.PO-01 Partial overlap

Frequently Asked Questions

Can we refuse a correction request?
Yes, if you can demonstrate the existing data is accurate and the proposed correction is wrong. But you must explain your reasoning to the individual and give them a chance to appeal or submit a statement of disagreement. Document your rationale. Under GDPR, you also need to inform them of their right to complain to a supervisory authority. Refusing without a documented, defensible reason will not go well in an audit.
How do we handle corrections to data in backups?
You do not typically need to correct data in existing backups - it is technically impractical and auditors understand that. Document that older backups may contain pre-correction data. The important thing is having a process to reapply corrections if a backup containing outdated data is ever restored. This pragmatic approach is generally accepted by both auditors and regulators.
What timeline should we commit to for processing corrections?
GDPR requires a response without undue delay and within one month. CCPA does not specify a correction timeline, but reasonableness is the standard. Set internal targets that meet the strictest applicable requirement. Simple corrections like address changes should be processed in days, not weeks. Auditors notice when you consistently use the full allowed timeframe for changes that should be quick.

Track SOC 2 compliance in one place

AuditFront helps you manage every SOC 2 control, collect evidence, and stay audit-ready.

Start Free Assessment