TSC-P5.1 Guidance

TSC-P5.1 requires you to give verified data subjects a secure way to access the personal information you store about them. To operationalize it fast, define what “stored personal information” means in your environment, implement strong identity verification and authentication, build a repeatable access workflow, and retain an auditable record of requests, responses, and approvals ¹.

Key takeaways:

• Scope first: inventory where personal information is stored and what you will disclose back to the data subject ¹.
• Access must be gated by identification and authentication, not email-only checks or informal support processes ¹.
• Evidence wins audits: keep request logs, identity verification records, and response packages tied to each request ¹.

If your SOC 2 report includes the Privacy category criteria, auditors will expect a working, controlled mechanism for data subjects to access their stored personal information under TSC-P5.1. This is an operational requirement, not a policy-only checkbox: you need a process people can follow, systems that enforce it, and records that prove it operated during the audit period ¹.

Most implementation failures come from two gaps. First, teams underestimate scope: “stored personal information” often lives across production databases, support tooling, CRM, data warehouses, and third-party sub-processors. Second, teams treat access as a customer support courtesy rather than a controlled privacy workflow, which leads to weak identity verification, inconsistent outputs, and incomplete audit trails.

This page translates the tsc-p5.1 guidance requirement into a concrete operating model: who owns intake, how to verify identity, how to compile the response safely, how to deliver it securely, and what artifacts your auditor will ask for. The goal is speed with control, so you can pass audit scrutiny without building a bespoke privacy engineering program from scratch.

Regulatory text

Requirement (TSC-P5.1): “The entity grants identified and authenticated data subjects the ability to access their stored personal information” ¹.

What the operator must do:
You must implement a method (self-service portal, authenticated account view, or controlled service workflow) that allows a data subject to access the personal information you store about them, but only after you identify and authenticate them ¹. Practically, this means:

• A defined intake channel for access requests.
• Identity proofing rules appropriate to risk.
• Authentication controls that prevent unauthorized disclosure.
• A consistent, reviewable response package.
• Secure delivery to the verified subject.
• An audit trail that shows each step happened.

Plain-English interpretation

TSC-P5.1 is about preventing privacy disclosures to the wrong person while still enabling legitimate access. Auditors are looking for two outcomes:

1. Data subjects can access the personal information you hold about them without unreasonable friction.
2. Your process proves you did not hand personal information to an impersonator ¹.

A strong implementation reads like an internal runbook: “If request comes in via Channel X, confirm identity using Method Y, collect data from Systems A/B/C using Procedure Z, perform review, deliver through Secure Method Q, log everything.”

Who it applies to

Entity types: Organizations undergoing a SOC 2 audit that includes the Privacy criteria ¹.

Operational contexts where this becomes real:

• B2C products where end users have accounts and profiles.
• B2B SaaS where “data subjects” may be end users inside a customer tenant (employees) or consumer contacts stored in your customer’s dataset.
• Companies that store personal information in support systems (ticketing, call recordings, chat logs) and operational tools (billing, fraud, analytics).
• Environments with third parties processing personal information on your behalf (sub-processors). You still need a process to retrieve and present the subject’s data where applicable to what you “store” or control ¹.

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

1) Define scope: what “stored personal information” includes

Create a written scope statement that answers:

• Which data categories are in-scope (account profile, identifiers, billing contact info, support content, device identifiers, logs, etc.).
• Which systems are authoritative sources.
• What you will exclude and why (for example, data that is not retrievable by subject identifier, or data you do not store).
• What “access” means in your model: view in-app, export file, or curated report ¹.

Output: “Data Subject Access Scope” document (one to two pages) plus a system/data map.

2) Choose the access mechanism (self-service vs. serviced)

Pick one primary route and document the fallback.

Option A: Self-service (preferred when you have accounts)

• In-app “Profile” and “Download my data” page behind login.
• Re-authentication for sensitive exports (e.g., password re-entry or MFA step-up).
• Clear notice of what is included.

Option B: Serviced workflow (common in B2B and non-authenticated subjects)

• Intake form or ticketing workflow.
• Identity proofing rules based on risk (see next step).
• Standard response templates and secure delivery.

Auditors accept either approach if it’s controlled and evidenced ¹.

3) Implement identification, identity proofing, and authentication controls

TSC-P5.1 explicitly requires identified and authenticated data subjects ¹. Your control design should separate:

• Identification: determining which data subject record you are dealing with (subject ID, account ID, email, customer tenant).
• Authentication: confirming the requester is that person.

Practical control patterns:

• If the subject has an account: require login, plus step-up authentication for exports.
• If no account exists: require a verified channel plus additional proof (for example, a one-time code to a previously verified email/phone on file).
• For high-risk records (financial, government ID, or sensitive categories): require stronger proofing and manager approval before release.

Hard rule for operators: do not rely on “email from the address on file” as your only check unless you can show that address was previously verified and protected with appropriate account security. Document your reasoning.

4) Build a repeatable workflow with ownership and SLAs

Document a workflow that includes:

• Intake: where requests arrive (portal, email alias, support form).
• Triage: confirm request type is “access,” not deletion or correction.
• Identity verification: checklist and evidence to collect.
• Data collection: which teams/systems must respond (product, data, support, billing).
• Review: privacy or security review before release for edge cases (shared accounts, tenant conflicts, suspected fraud).
• Delivery: secure channel (authenticated portal download, encrypted file transfer, or secure email with separate password channel).
• Closure: log the outcome and retain evidence.

Assign RACI:

• Responsible: Privacy Ops / Support Ops
• Accountable: CCO / Privacy Officer
• Consulted: Security, Legal, Engineering
• Informed: Customer Success for B2B tenant requests

5) Standardize the response package

Define what the data subject receives:

• Human-readable summary (what systems were searched, what data types are included).
• Export format (JSON/CSV/PDF) appropriate to your product.
• Redaction rules (for example, do not disclose other individuals’ personal information in shared records).
• A “cannot provide” path with documented rationale for missing/unavailable data.

Consistency reduces errors and makes audit sampling easier.

6) Maintain an audit trail end-to-end

TSC-P5.1 audits often come down to evidence of operation: show the control ran, not just that it exists ¹. Your logging must capture:

• Request receipt date/time and channel
• Requester identifiers
• Identity verification steps performed and result
• Systems queried and by whom
• Approvals (if required)
• Delivery method and confirmation
• Exceptions and escalations

If you run this through a ticketing system, enforce required fields so the record is complete.

7) Monitor and review the process

Set a periodic review cadence to catch drift:

• Sample completed requests for completeness and correct verification.
• Review exceptions (failed verification, suspected impersonation, tenant disputes).
• Update the data map when new systems store personal information ¹.

If you use Daydream to manage privacy operations, treat it as the system of record for request intake, tasking, and evidence packaging so audit exports are consistent across teams.

Required evidence and artifacts to retain

Auditors typically want documentation plus samples. Retain these artifacts ¹:

• Policy/procedure: Data Subject Access Procedure (runbook) mapped to TSC-P5.1.
• Scope statement: definition of stored personal information and in-scope systems.
• Workflow evidence: screenshots or configuration exports for portal controls, MFA/SSO settings, ticket workflows, required fields.
• Request register: list of access requests with status and timestamps.
• Sample request packets: for selected requests, include identity verification evidence, query notes, approval, and the delivered response (redacted as needed).
• Audit trail logs: immutable logs from ticketing system and portal download logs.
• Periodic review records: review checklist, findings, and remediation tickets.
• Testing results: internal control test scripts and outcomes showing the process works ¹.

Common exam/audit questions and hangups

Auditors tend to probe these areas ¹:

• “Show me how you ensure the requester is the data subject.”
• “Where do you store personal information, and how do you know you didn’t miss a system?”
• “Provide a sample of access requests from the audit period with complete evidence.”
• “How do you handle shared accounts or data that includes other individuals?”
• “Who can approve disclosures, and how is that approval recorded?”
• “What’s your fallback if the subject cannot authenticate?”

Hangup to anticipate: your team can describe the process verbally, but cannot produce complete, consistent records for sampled requests.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails TSC-P5.1	Fix
Treating access as an ad hoc support task	No consistent authentication or evidence 1	Force intake through a defined workflow with mandatory fields
Weak identity verification	Risk of disclosure to an impostor 1	Require login or step-up verification; document exceptions
No clear definition of “stored personal information”	Missed systems and incomplete responses	Maintain a scoped data map tied to subject identifiers
Response delivered over insecure channels	Exposure risk and audit concern	Use authenticated portal downloads or secure file transfer
Poor evidence retention	Fails sampling even if work was done 1	Save a standardized evidence packet per request

Enforcement context and risk implications

SOC 2 is an audit framework, not a regulatory enforcement regime, so you will not find “TSC-P5.1 enforcement cases” in public regulator dockets based on this criterion alone ¹. Your practical risk is:

• Audit exceptions that delay or qualify your SOC 2 report.
• Customer trust impact when procurement teams see weak privacy controls.
• Increased likelihood of unauthorized disclosure if identity verification is informal.

Treat TSC-P5.1 as a disclosure-prevention control with privacy outcomes.

Practical 30/60/90-day execution plan

Days 0–30: Stand up the minimum viable control set

• Appoint an owner (Privacy Ops or GRC) and confirm audit scope includes Privacy.
• Write the Data Subject Access Procedure (runbook) mapped to TSC-P5.1 ¹.
• Define “stored personal information” scope and list in-scope systems.
• Choose intake channel and enforce a single workflow (ticket form with required fields).
• Implement basic identity verification rules and an escalation path for exceptions.

Days 31–60: Harden authentication, delivery, and evidence

• Add step-up authentication for exports if you have self-service access.
• Standardize response templates and export formats.
• Implement secure delivery method and restrict who can send disclosures.
• Create a request register and evidence packet structure for audits.
• Run a tabletop test: simulate an impostor attempt and confirm the workflow blocks it.

Days 61–90: Make it auditable and sustainable

• Conduct a periodic assessment of completed requests and document findings ¹.
• Add monitoring: alerts for unusual request patterns or repeated failed verification attempts.
• Expand data map coverage to new systems and relevant third parties.
• Perform control testing and store results for the audit.
• If you use Daydream, configure automated evidence collection and auditor-ready exports so sampling does not become a scramble.

Frequently Asked Questions

Does TSC-P5.1 require a self-service “download my data” button?

No. It requires that identified and authenticated data subjects can access their stored personal information, which can be met with a controlled serviced workflow ¹.

What counts as “identified and authenticated” for access requests?

The requester must be tied to a known data subject record (identified) and must pass an authentication or verification method that you define and apply consistently ¹.

If we are B2B SaaS, who is the data subject?

Often it is the end user within a customer tenant, but it can also be individuals whose personal information is stored in your customer’s dataset. Your procedure should define which requests you accept directly versus route through the customer ¹.

How do we handle records that include other people’s personal information?

Build a review step that redacts or excludes third-party personal information in shared content (tickets, collaboration notes, messages) before releasing the package.

What evidence do auditors ask for most often?

A documented procedure plus sampled access requests with identity verification proof, data collection notes, approvals, delivery confirmation, and a complete audit trail ¹.

Can support handle these requests, or does it need to be Legal/Privacy?

Support can run the workflow if you provide a runbook, required verification steps, and an escalation path for edge cases. Auditors care about control design and evidence, not the department name ¹.

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