TSC-P5.2 Guidance

The tsc-p5.2 guidance requirement is a privacy-operational control: if an individual tells you their personal information is wrong or incomplete, you need a governed way to correct it (or append a clarifying note) and prove you did it. For SOC 2 Privacy, auditors commonly look for two things: (1) a documented procedure that describes how corrections happen, and (2) evidence that the procedure ran in practice for real tickets during the audit period.

This criterion is easy to under-scope. Teams often handle corrections informally (support edits a profile record) without confirming identity, without propagating changes into CRM/billing/analytics copies, and without keeping a durable record of what changed. That gap becomes an audit finding because the control is not “we can edit data,” it’s “we reliably process data-subject-provided corrections across the environment.”

Operationalizing TSC-P5.2 means building a single, testable workflow that spans Support, Privacy/Legal, Security, and the system owners who actually store or sync personal information. If you already run a DSAR program, treat this as the “rectification” branch of that program and tighten evidence around completion and propagation.

Regulatory text

Requirement (TSC-P5.2): “The entity corrects, amends, or appends personal information based on information provided by data subjects.” ¹

Operator meaning: You must have a process that receives correction requests from individuals, validates the request, updates the relevant personal information (or appends a clarifying annotation when outright replacement is not appropriate), and records what you did. The process must work across the systems and teams that touch personal information, not only the “primary” application database.

Plain-English interpretation

If a person says “my name is misspelled” or “this address is outdated,” you need to:

1. Confirm the request is legitimate (identity and authority).
2. Decide whether you will correct, amend, or append (and when each applies).
3. Make the change in the right places (systems of record and replicas).
4. Tell the requester the outcome (completed, partially completed, denied with reason).
5. Keep proof for auditors.

“Append” matters in practice. Some records should not be overwritten (for example, a historical transaction record). In those cases, you keep the original record for integrity and add an annotation or a linked “current value” field, with clear logic for how the business uses it.

Who it applies to

Entity scope: Any organization undergoing a SOC 2 engagement that includes the Privacy category and represents that it processes personal information. ¹

Operational context where this shows up:

• Customer account/profile data changes initiated by the individual
• HR/people operations for employee personal information
• Marketing databases (email, phone), CRM, support tooling
• Identity systems (SSO directories) that store names/emails
• Third parties processing your personal information (e.g., CRM, ticketing, payroll providers)

Data scope: Personal information you control in your environment, plus copies you cause to exist through syncing, exports, and integrated third parties.

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

Use this as an implementation checklist you can hand to Support Ops and Privacy Ops.

1) Define the correction request channels

• Choose your intake methods (privacy email alias, web form, support ticket category).
• Write a short intake script for Support: what to collect, what not to collect, and when to route to Privacy/Legal.
• Ensure intake captures: requester identity, what data is claimed incorrect, proposed correct value, and where they saw it.

Control outcome: All correction requests become trackable cases, not ad hoc chat messages.

2) Verify identity and authority

• Set identity verification rules based on risk and account context:
  • Authenticated users: require login and in-product submission where possible.
  • Unauthenticated requests: require reasonable verification (match to account email, order details, or other non-sensitive proof).
  • Authorized agents: require written authorization and verify the agent’s identity.
• Document acceptable verification methods and “fail closed” rules.

Audit focus: Auditors look for a defined verification step and evidence it occurred, because incorrect updates can create account takeover and fraud risk.

3) Decide whether to correct, amend, or append

Create decision logic that system owners can follow:

Scenario	Correct	Amend	Append
Typo in profile field used operationally	Yes	Sometimes	Rare
Disputed narrative text (support notes)	No	No	Yes (add note)
Historical invoice address tied to a past transaction	Usually no	Sometimes	Yes (add “current address” while preserving history)
Identity attributes used for authentication (email/phone)	Yes, with stronger verification	Sometimes	Rare

Document who approves non-routine decisions (Privacy, Legal, Security, Data Owner).

4) Execute the change across systems (system-of-record + replicas)

Build and maintain a personal information data map for correction propagation. Minimum operational view:

• System of record for each attribute (e.g., name in app DB; billing address in payments tool).
• Replication paths (ETL to data warehouse, CRM sync, marketing list sync).
• Third parties that store the attribute.

Execution steps:

• Update the system of record first.
• Trigger sync jobs or manual updates for known replicas.
• If you cannot update a replica (tool limitation or legal retention need), record an exception and document compensating steps (annotation, suppression, or segmentation).

Practical note: This is where teams fail audits. They update one tool and forget the data warehouse or downstream exports.

5) Communicate the outcome to the data subject

• Confirm completion and summarize what was changed (avoid sending sensitive data back in plain text).
• If denied or partially fulfilled, provide the reason and next steps (e.g., “we cannot overwrite transaction history, but we appended a note and updated current profile data”).

6) Maintain an audit trail of each request

For every request, retain:

• Request intake record (ticket/form/email)
• Verification evidence (method used and outcome)
• Approval/decision record (especially for append vs overwrite decisions)
• Proof of change (system logs, screenshots, database audit log entry, change request record)
• Completion communication and closure

7) Monitor, review, and test control effectiveness

• Assign ownership (Privacy Ops or GRC) to review a sample of closed correction tickets periodically for completeness and propagation.
• Track recurring failure modes: missing verification, incomplete system updates, poor documentation.
• Feed results into training and runbook updates.

SOC 2 auditors expect you to show that the control is not only documented but operating and tested ¹.

Required evidence and artifacts to retain

Maintain these artifacts in your GRC repository (or a dedicated audit evidence folder), linked to the control:

Policy and procedure artifacts

• Privacy/DSAR procedure covering corrections/rectification (explicitly naming “correct, amend, append”)
• Identity verification standard for privacy requests
• Data map / system inventory for personal information attributes relevant to correction propagation
• RACI: Support vs Privacy vs Security vs System Owners responsibilities

Operational evidence (audit-period samples)

• A set of completed correction cases showing end-to-end handling
• Screenshots or exports from ticketing system showing timestamps, assignee changes, and closure notes
• Change logs from systems of record (where available)
• Exception register for cases where data could not be overwritten, with documented rationale and compensating steps
• Review/testing evidence: periodic QA checklist, findings, and remediation notes

Common exam/audit questions and hangups

Auditors tend to ask variations of:

• “Show me the documented process for receiving and processing personal information corrections.”
• “How do you verify the requester’s identity before changing personal information?”
• “Which systems store the personal information you corrected, and how do you ensure updates propagate?”
• “Provide samples from the audit period and evidence of the actual changes.”
• “How do you handle cases where you cannot overwrite information (append vs correct)?”

Hangups that create findings:

• You can’t demonstrate propagation beyond the primary application.
• Tickets don’t show identity verification.
• No evidence of review/testing; only a written policy exists.

Frequent implementation mistakes and how to avoid them

1. Treating correction requests as normal support edits.
   Fix: Force all corrections through a dedicated ticket type with required fields (verification method, systems touched, outcome).

2. No clear “append” standard.
   Fix: Write decision rules for immutable records and disputed content. Require approvals for exceptions.

3. No system inventory for propagation.
   Fix: Maintain a living map of where personal information fields live and sync. Tie it to your change management process so new integrations get added.

4. Weak evidence retention.
   Fix: Standardize closure notes and attach system proof (audit log export, screenshot, or admin activity record).

5. Third parties ignored.
   Fix: Add a “third party touched?” checkbox in the workflow and maintain playbooks for common tools (CRM, marketing, payroll).

Enforcement context and risk implications

SOC 2 is an audit framework, not a regulatory enforcement regime. Your risk is still real: mishandling corrections can cause account security issues (wrong party changes a record), operational harm (shipments to wrong address), and privacy trust loss. For SOC 2, the practical consequence is a control deficiency if you can’t show consistent operation and evidence ¹.

Practical 30/60/90-day execution plan

First 30 days: get to a working workflow

• Draft/refresh the correction procedure (include correct/amend/append definitions).
• Implement a dedicated ticket type with required fields and an approval step for exceptions.
• Define identity verification methods for authenticated vs unauthenticated requesters.
• Run a tabletop test with Support + Privacy + one system owner using realistic scenarios.

Deliverables: procedure, ticket workflow, verification checklist, initial evidence template.

Days 31–60: cover your systems and third parties

• Build the attribute-level data map for the personal information you commonly correct (name, email, phone, address).
• Identify systems of record and downstream replicas; document propagation steps per system.
• Add third-party propagation playbooks for major tools.
• Start capturing “proof of change” consistently (admin logs, screenshots, exports).

Deliverables: data map, propagation runbooks, exception register template.

Days 61–90: prove operation and add monitoring

• Sample completed tickets and perform QA against a checklist; document findings and fixes.
• Train Support and system admins on the workflow and evidence expectations.
• Set a recurring review cadence owned by GRC/Privacy Ops.
• If you use Daydream, centralize the workflow evidence, map tickets to the control, and package samples for the auditor without scrambling across tools.

Deliverables: QA results, training records, audit-ready evidence package, monitoring schedule.

Frequently Asked Questions

What’s the difference between “correct,” “amend,” and “append” in practice?

“Correct” replaces inaccurate data used operationally. “Amend” updates a record while preserving context (for example, adding a corrected value plus metadata). “Append” adds a clarifying note or linked record when overwriting is inappropriate or would break integrity.

Do we need to update analytics and the data warehouse too?

Yes, if those systems hold the personal information that was corrected and you use it. If you cannot realistically update historical datasets, document the limitation and your compensating approach (for example, update the system of record and stop future sync of the incorrect value).

How do we handle correction requests that conflict with fraud or security controls?

Increase verification requirements and route to Security for review when the attribute is used for authentication or account recovery. Document the decision and keep proof of the verification and approvals in the case record.

What evidence is “good enough” for a SOC 2 auditor?

A written procedure plus closed cases showing identity verification, the decision (correct/amend/append), proof the change occurred, and completion notice. Add a periodic review record to show the control is monitored and tested ¹.

Can Support own this control, or does it have to be Privacy/Legal?

Support can run intake and execution for routine requests if the workflow enforces verification and documentation. Privacy/Legal should own the procedure, exception handling rules, and periodic QA because auditors will ask who governs consistency.

We use third parties (CRM, payroll). Do we need to correct data there too?

If the third party stores the inaccurate personal information under your control and it’s within scope, include it in propagation steps. Where you cannot directly edit, document the request path (admin change, support request to the provider) and retain evidence that it was completed.

Related compliance topics

• 2025 SEC Marketing Rule Examination Focus Areas
• Access and identity controls
• Access Control (AC)
• Access control and identity discipline
• Access control management

Footnotes

1. AICPA Trust Services Criteria 2017, 2017