TSC-P7.1 Guidance

TSC-P7.1 sits in the SOC 2 Privacy criteria and focuses on a practical outcome: when a person asks, you can tell them what personal information you disclosed to third parties. Many organizations can describe their privacy program at a high level, but struggle to produce a complete, consistent accounting because disclosure data is scattered across procurement, security, engineering, and product operations.

For a CCO or GRC lead, the fastest path is to treat this requirement as a reporting capability backed by three foundations: (1) a defined population of third parties who receive personal information, (2) a reliable map from personal information categories to systems and disclosure pathways, and (3) a fulfillment process with quality checks and an audit trail. If your program already supports data subject access requests (DSARs), TSC-P7.1 is the “disclosure to third parties” slice that often needs more rigor: you must show your work, not just provide a narrative.

This page gives requirement-level implementation guidance you can hand to Privacy Ops, Security, Procurement, and Engineering to build the capability and pass SOC 2 testing with predictable evidence.

Regulatory text

Requirement (TSC-P7.1): “The entity provides data subjects with an accounting of personal information disclosed to third parties.” ¹

Operator interpretation: You need a way to generate, on request, a defensible list of disclosures of a person’s personal information to external parties. The accounting must be complete for the scope of your SOC 2 privacy boundary and consistent with how you actually share data (processors, service providers, partners, affiliates, and other recipients that qualify as third parties in your context).

What “accounting” should contain (practical minimum)

Auditors typically expect you can produce a report that answers:

• What personal information was disclosed (category-level is acceptable in many programs; document your standard).
• Which third parties received it (name and/or category, depending on your policy and contracts).
• Purpose of the disclosure (business purpose and processing purpose).
• Timeframe (a defined lookback period aligned to your policy and system retention).
• Source systems used to generate the accounting, so the auditor can reperform.

Plain-English interpretation of the requirement

If a customer, user, employee, or other data subject asks, you must be able to say: “Here are the third parties we shared your personal information with, what we shared, and why.” This is not the same as your public privacy notice. The privacy notice is general; TSC-P7.1 expects you can respond at the individual level using operational records.

The hard part is completeness. Most teams miss disclosures that happen through:

• Customer support tooling (ticket attachments, call recordings, chat transcripts)
• Product analytics and error monitoring
• Email and marketing platforms
• Subprocessors inside cloud services
• One-off exports to consultants, auditors, or implementation partners

Who it applies to

Entities

• Any organization undergoing a SOC 2 examination that includes the Privacy category and the TSC 2017 criteria set, including TSC-P7.1 ¹.

Operational context (where this breaks in practice)

You are in scope if your organization:

• Discloses personal information to any third party (service providers, subprocessors, partners, contractors, professional services firms, cloud providers).
• Has multiple systems where personal information can be exported or accessed externally.
• Accepts DSARs (or equivalent privacy rights requests) and needs consistent fulfillment.

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

Step 1: Define the scope of “personal information” and “third party” for your SOC 2 boundary

• Align with your SOC 2 system description and privacy commitments.
• Document what counts as a “disclosure.” Include API transfers, batch exports, third-party access, and managed services that process data on your behalf.
• Decide your reporting granularity (categories vs. specific fields). Write it down; auditors test against what you claim you do.

Deliverable: “Accounting of Disclosures Standard” (1–2 pages) owned by Privacy/GRC.

Step 2: Build (or refine) a third-party disclosure inventory tied to your data map

Create a ledger that links:

• Third party name
• Service/function
• Personal information categories shared
• Systems of record where the data originates
• Disclosure method (API, SFTP, UI access, embedded SDK, email, manual export)
• Purpose
• Contractual controls (DPA, confidentiality, onward transfer limits, retention terms)
• Owner (internal accountable team)

This inventory should reconcile with:

• Your third-party register (TPRM/procurement)
• Your subprocessors list (if published)
• Your data inventory / RoPA-like record (even if you don’t call it that)

Tip that reduces audit pain: assign each disclosure pathway a stable ID so you can show changes over time without rewriting everything.

Deliverable: “Third-Party Disclosure Ledger” (spreadsheet, GRC system record, or privacy tooling export).

Step 3: Implement a repeatable request workflow to produce the accounting

Minimum workflow stages:

1. Intake: authenticated channel (portal, email alias, ticket type) with required fields.
2. Identity verification: proportionate to risk; document your method and exceptions.
3. System query plan: which systems you must query for disclosures.
4. Compilation: generate the accounting using the disclosure ledger + system evidence (logs, exports, vendor reports).
5. Quality review: second-person review for completeness and redactions.
6. Delivery: secure transmission and standard template language.
7. Closure + logging: record what was provided and keep an immutable audit trail.

Deliverables:

• SOP: “Accounting of Third-Party Disclosures Request Handling”
• Response template (customer-facing)
• Ticketing workflow with required fields and approvals

Step 4: Create “source-of-truth” evidence for disclosures (don’t rely on memory)

Your accounting must be based on records. Common evidence sources:

• Data pipeline configs (destinations configured for exports)
• Vendor administration consoles showing data sharing settings
• Access logs for third-party accounts
• File transfer logs and integration job histories
• CRM/marketing platform export logs
• Support system integrations and app lists

If logs are incomplete, document compensating controls:

• Restrict disclosure channels to controlled integrations
• Require approvals for manual exports
• Centralize third-party access via SSO and role-based access

Deliverable: Evidence map: “Where disclosure proof lives” by system.

Step 5: Establish monitoring, review, and change control

Auditors look for “operating effectiveness,” not just a policy. Put a cadence around it:

• Review the disclosure ledger when onboarding/offboarding third parties.
• Review when engineering adds integrations or new data flows.
• Periodically revalidate that listed disclosures match actual configurations.

Deliverables:

• Quarterly (or defined) review checklist and sign-off record
• Change management hooks: procurement intake + security review + privacy review

Step 6: Test the control like an auditor would

Run a tabletop test:

• Pick a sample data subject.
• Produce the accounting within your stated process.
• Validate completeness by cross-checking against your third-party list and key systems.

Deliverables:

• Test plan + results
• Remediation tickets for gaps found

Required evidence and artifacts to retain

Keep artifacts in an audit-ready folder with clear naming and dates.

Evidence type	What it proves	Examples
Policy/SOP	Control is designed	Accounting SOP, identity verification procedure, response template
Disclosure ledger	You know who receives data	Third-party disclosure inventory, subprocessors mapping
Data inventory linkage	Completeness of population	Data map tying PI categories to systems and third parties
Request records	Control operates	DSAR tickets, intake forms, approvals, delivery confirmations
System evidence	Accounting is based on records	Integration configs, export logs, access logs, admin screenshots
Review & monitoring	Ongoing governance	Periodic review sign-offs, onboarding checklists, change tickets
Testing results	Effectiveness	Control test documentation, exception handling, remediation evidence

Common exam/audit questions and hangups

Auditors commonly press on these points for the tsc-p7.1 guidance requirement:

1. Population completeness: “How do you know this includes all third parties that receive personal information?”
2. Definition of disclosure: “Does third-party access count, or only transfers? Show your definition.”
3. Evidence basis: “Is the accounting derived from logs/configuration, or a manually maintained spreadsheet?”
4. Subprocessors: “How do you handle cloud providers and their subprocessors inside your scope?”
5. Consistency: “Do different teams produce different answers depending on who handled the request?”
6. Exceptions: “What happens if you cannot confirm a disclosure due to retention limits?”

Prepare crisp answers, then map each answer to artifacts listed above.

Frequent implementation mistakes and how to avoid them

• Mistake: treating the privacy notice as the accounting.
  Fix: build a per-data-subject reporting workflow backed by records and a ledger.

• Mistake: inventory lists vendors, but not disclosures.
  Fix: add “PI categories shared,” “method,” “source systems,” and “purpose” fields; make them required at onboarding.

• Mistake: ignoring “shadow disclosures” via support and marketing tools.
  Fix: include Support, Sales Ops, and Marketing Ops systems in the query plan; add them to periodic reviews.

• Mistake: manual exports without controls.
  Fix: route exports through ticketed approvals, log retention, and controlled storage locations; restrict who can export.

• Mistake: no operating evidence.
  Fix: run at least one internal test case and retain the full audit trail (request, compilation steps, reviewer sign-off).

Enforcement context and risk implications

SOC 2 is an audit framework rather than a regulator-driven enforcement regime, so this requirement is assessed through examination evidence rather than fines tied directly to TSC-P7.1 ¹. The practical risk is still real: if you cannot account for third-party disclosures, you create gaps in privacy commitments, incident response scoping, and customer trust. In SOC 2 terms, the risk becomes a control deficiency or exception that can affect your report outcomes and customer procurement reviews.

Practical 30/60/90-day execution plan

First 30 days: get to a usable baseline

• Assign an owner (Privacy Ops or GRC) and confirm audit scope for Privacy criteria.
• Draft the “Accounting of Disclosures Standard” with definitions and reporting granularity.
• Export your third-party list and identify candidates that receive personal information.
• Stand up a disclosure ledger v1 with required fields and accountable owners.
• Draft SOP + response template; implement a dedicated ticket type in your workflow tool.

Days 31–60: connect the ledger to systems and evidence

• Build the “system query plan” for the accounting (systems that contain PI and disclose it).
• For top systems, document where disclosure evidence lives (logs/configs) and access requirements.
• Add change-control hooks: procurement onboarding requires disclosure fields; engineering integration review includes privacy sign-off.
• Run one end-to-end fulfillment test and capture evidence.

Days 61–90: harden for audit and ongoing operations

• Expand evidence coverage to remaining systems and key third parties.
• Implement quality review and second-person approval for responses.
• Establish a recurring review cadence with sign-off records.
• Perform a mini internal audit: sample requests, reperform report compilation, document gaps and remediation.
• If your evidence is scattered, consider centralizing in a GRC workspace (Daydream can help by turning your third-party register, data map, and request tickets into a single control record auditors can trace end-to-end).

Frequently Asked Questions

Do we have to list every subprocessor our cloud provider uses in the accounting?

TSC-P7.1 requires an accounting of personal information disclosed to third parties ¹. Define in your standard whether you report subprocessors by name, by category, or by reference to your subprocessor list, then apply that approach consistently.

Can the accounting be category-based (e.g., “contact info”) rather than field-by-field?

The criterion does not prescribe the level of granularity; it requires an accounting ¹. Choose a level your systems can support with defensible evidence, document it, and ensure your response template matches.

What if we don’t have logs that show historical disclosures?

Document the limitation, set a clear lookback based on your retention, and implement controls that make future disclosures provable (controlled integrations, export approvals, centralized access logging). Auditors will focus on whether your control design matches what you can evidence.

Does “disclosed” include third-party access, like a support contractor logging into our systems?

Treat access that enables viewing or extracting personal information as a disclosure pathway unless your documented standard excludes it with a reasoned definition. The key is that your definition is explicit and your ledger covers the real ways third parties can obtain PI.

How do we keep the disclosure ledger current without slowing procurement?

Make PI categories shared, purpose, and source systems required fields in the third-party onboarding intake, with a privacy sign-off SLA. Tight scoping helps: “no PI shared” should be an explicit selectable value with an owner attestation.

What evidence is most persuasive in a SOC 2 audit for this requirement?

Auditors favor reperformable evidence: the disclosure ledger tied to system configurations/logs, plus completed request tickets showing compilation steps and reviewer sign-off. A policy alone rarely carries the test.

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