The entity provides data subjects with an accounting of personal information disclosed to third parties

This requirement sits in the SOC 2 Privacy criteria and is operationally harder than it sounds. “Accounting of disclosures” means you must be able to tell a data subject what personal information you disclosed, to which third parties, and under what context, based on what actually happened in your environment. Auditors will not accept a generic list of subprocessors if you cannot connect disclosures to the data subject and the relevant period, nor will they accept an ad hoc manual approach if it cannot be repeated reliably.

For most service organizations, the fastest path is to treat this like an engineering and governance problem: you need a defined record of disclosures (a ledger), a controlled request intake and identity verification process, and a consistent output format that is understandable to a data subject and defensible in an exam. The operational scope is broader than “vendors” because disclosures may occur to partners, customers (in certain roles), affiliates, consultants, and infrastructure providers.

If you already run a DSR program, this requirement typically fails on two gaps: incomplete inventory of third parties receiving data, and missing event-level evidence that the accounting you provide is complete. This page gives requirement-level steps and the evidence set you need to pass a SOC 2 Privacy review.

Regulatory text

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

Operator interpretation (what you must do):

• You must be able to produce an accounting for a data subject that identifies personal information disclosed to third parties.
• The accounting needs to be based on your actual disclosure pathways (systems, integrations, exports, sharing) rather than a purely theoretical policy statement.
• You must be able to demonstrate the process is designed (documented, owned, scoped) and operating (used for real requests or tested) with retained evidence. ¹

Plain-English interpretation

If a person asks, “Who did you share my personal information with?”, you must be able to answer with a defensible list based on your records. That answer must cover third parties that received their data through your operations, including subprocessors, service providers, and other external recipients in scope.

This is not the same as:

• Publishing a generic subprocessor list (helpful, but often insufficient by itself).
• Saying “we may share with service providers” in a privacy notice (that’s notice, not an accounting).
• Assuming your procurement tool has the full list (it rarely captures API-based sharing, support tooling, or outbound data feeds).

Who it applies to

Entity scope

Applies to service organizations seeking SOC 2 reporting against the Privacy criteria where the organization processes personal information and discloses it to third parties as part of service delivery. ¹

Operational context (what typically triggers it)

You are in scope if any of the following occur:

• You use third parties to host, process, support, analyze, or deliver services where personal information flows to them (cloud hosting, ticketing, email/SMS, monitoring, payment, analytics, customer support).
• You disclose personal information to partners or customers through integrations, exports, shared workspaces, or managed services.
• You permit third-party access (admin access, support access, implementation consultants) that results in disclosure.

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

Step 1: Define “disclosure” and the accounting output

Create a short control standard that answers:

• What counts as “disclosed to a third party” (e.g., transfer, making available via integration, granting access that permits viewing/downloading).
• What your accounting will include at minimum: third party name, category/role, purpose, personal information categories, and time period covered.
• What is out of scope (example: internal affiliates only, if your definition and SOC 2 scope justify that), and how you document exceptions.

Artifact: “Accounting of Disclosures Standard” (1–2 pages), approved by the CCO/Privacy Lead.

Step 2: Build a complete inventory of third parties receiving personal information

Start with procurement and security vendor lists, then expand using technical discovery:

• Subprocessor list (privacy).
• Vendor/third-party register (TPRM).
• System architecture diagrams and data flow diagrams.
• API integration catalogs (inbound/outbound).
• Logs of data exports (S3 shares, file transfer, BI extracts), support tooling, and marketing tooling.

Make the inventory useful for the accounting by adding fields:

• Third party legal name
• Service/function
• Data types/categories shared
• Systems involved (source system and transfer method)
• Purpose of disclosure (service delivery, support, fraud prevention, analytics, etc.)
• Whether disclosure is continuous (API) or event-based (export)

Artifact: “Third-Party Disclosure Inventory” (table or GRC system record).

Step 3: Map personal information elements to systems and disclosure paths

Auditors look for completeness. You need a data map that ties:

• Personal information categories (e.g., identifiers, contact details, device data, payment-related data if applicable)
• Systems of record
• The disclosure pathways to each third party (integration, shared database, support access, ticket attachments, etc.)

Keep it practical: a table that links “system → data categories → third parties → transfer mechanism” is usually enough if it’s maintained.

Artifact: Data map / data flow matrix aligned to the disclosure inventory.

Step 4: Create the “disclosure ledger” you can query per data subject

This is the core operational move. You need a mechanism to produce an accounting for a specific person. Choose one of these patterns:

Pattern A (preferred): Central ledger

• A structured dataset (in a GRC tool, database, or DSR platform) that records disclosures by:
  • data subject identifier(s)
  • third party
  • data categories
  • date/time or date range
  • purpose and system source

Pattern B: Deterministic reconstruction

• If event-level logging is not feasible for all transfers, define deterministic rules:
  • “If user existed in system X during period Y, then disclosures to third parties A/B/C occurred via integration Z.”
• This approach must be backed by system configuration evidence showing the integration actually runs and what data it sends.

Common exam hangup: A subprocessor list alone does not prove a given person’s data was disclosed. Your ledger or reconstruction method must connect the dots.

Artifacts: Ledger schema/documentation; sample extracts; integration configuration evidence.

Step 5: Operationalize a DSR workflow that produces the accounting

Implement a documented process in your ticketing system or DSR tool:

1. Intake: Accept requests through defined channels (web form, email).
2. Identity verification: Verify requester identity and authority (including agents, if you allow).
3. Scope confirmation: Confirm relevant timeframe and identifiers (email, account ID).
4. Query: Pull results from the ledger or run the reconstruction playbook across in-scope systems.
5. Review: Privacy/legal review for completeness and to avoid disclosing secrets (e.g., security-sensitive details); do not omit required disclosure info.
6. Response: Provide the accounting in a clear format (table) with plain language.
7. Retention: Store the request, queries run, and response package as evidence.

Artifacts: DSR procedure; ticket workflow states; response template.

Step 6: Put ownership, training, and quality checks in place

Assign operational owners:

• Privacy/Compliance owner for policy and response approval.
• Security/IT owners for data maps and integration inventories.
• TPRM owner for third-party inventory accuracy.

Add quality controls:

• Quarterly reconciliation between third-party register and disclosure inventory.
• Change management trigger: any new third party receiving personal information requires updating the disclosure inventory and ledger logic before go-live.

Artifacts: RACI; training records; reconciliation reports; change management checklists.

Step 7: Test it like an auditor will

Run a tabletop test using a realistic data subject:

• Generate the accounting end-to-end.
• Validate third parties included match the disclosure inventory.
• Retain evidence of the test and remediation actions.

Artifacts: Test plan, test result package, remediation tickets.

Required evidence and artifacts to retain (audit-ready)

Use this as your evidence checklist:

• Accounting of Disclosures Standard (definition, minimum output, scope boundaries) ¹
• Third-Party Disclosure Inventory with owners and last review date
• Data map/data flow matrix linking systems to third parties and data categories
• DSR procedure including identity verification and response review
• Request records: tickets, communications, verification steps performed
• Accounting outputs provided to data subjects (redacted copies if needed)
• System evidence supporting ledger/reconstruction: integration configs, logs, export job configs
• Reconciliation evidence between procurement/TPRM records and actual disclosure list
• Testing evidence (tabletop or sample runs) and remediation records

Common exam/audit questions and hangups

Auditors commonly ask:

• “Show me how you identify all third parties that receive personal information.”
• “For this specific data subject, show the accounting you produced and how you derived it from systems.”
• “How do you ensure new integrations or tools get added to the accounting process?”
• “Who reviews the response for completeness and correctness?”
• “What evidence shows the control operated during the period?”

Hangups that stall exams:

• Inventory mismatch (TPRM list differs from engineering reality).
• Reliance on tribal knowledge (“we think we only share with…”).
• No proof of operation (procedure exists, but no completed requests or tests).

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating the subprocessor list as the accounting.
   Avoid: Keep the subprocessor list, but also maintain per-system disclosure pathways and a way to tie them to a data subject.

2. Mistake: Forgetting non-procured third parties.
   Examples: freemium tooling, embedded analytics, consultant access, support screen-sharing tools.
   Avoid: Drive discovery from SSO app catalogs, browser extension policies, network egress allowlists, and API management.

3. Mistake: No linkage to identifiers used across systems.
   Avoid: Maintain an “identifier crosswalk” (email, user ID, CRM ID, device ID) so your query step is repeatable.

4. Mistake: Responses that are hard to understand.
   Avoid: Use a table with consistent columns: third party, purpose, data categories, how shared, timeframe.

Enforcement context and risk implications

SOC 2 is an attestation framework rather than a regulator, so “enforcement” shows up as:

• Qualified opinions, control exceptions, or failed privacy criteria mapping.
• Customer trust friction during security reviews and renewals.
• Contractual exposure if you commit to DSR capabilities and cannot produce an accounting during an incident or dispute.

The risk is not theoretical: inability to account for disclosures usually indicates incomplete third-party visibility, weak change management around integrations, and unreliable DSR execution. Those weaknesses also increase incident response complexity because you cannot quickly identify who received what data.

Practical 30/60/90-day execution plan

First 30 days: Get to a defensible design

• Assign an owner and approve the Accounting of Disclosures Standard.
• Build the initial Third-Party Disclosure Inventory from procurement, security, and privacy sources.
• Identify top systems that store personal information and list their outbound disclosures.
• Choose your approach: central ledger vs deterministic reconstruction.
• Draft the DSR workflow and response template.

Daydream fit: If you track third parties, systems, and evidence in multiple spreadsheets, Daydream can act as the control hub for your disclosure inventory, evidence collection, and audit request packaging without rebuilding your engineering stack.

Days 31–60: Make it operate

• Implement ledger fields or reconstruction playbooks for each major system.
• Add identity verification steps and reviewer sign-off into your ticket workflow.
• Run at least one internal test request and generate the accounting.
• Reconcile third-party register vs disclosure inventory; open remediation items for gaps.
• Train support and privacy responders on the process.

Days 61–90: Prove repeatability and tighten change control

• Add a change management gate: new third party/integration cannot go live until disclosure inventory and accounting logic are updated.
• Run a second test using a different persona and different identifiers to validate the crosswalk.
• Package evidence for SOC 2: control narrative, artifacts, samples, test records.
• Establish a regular review cadence and assign backup owners.

Frequently Asked Questions

Does “accounting of disclosures” mean we need event-level logs for every transfer?

Not always. A defensible approach can be a central ledger or a deterministic reconstruction tied to system configurations, as long as it reliably identifies the third parties that received the data and you can show your method is complete and repeatable. ¹

Is publishing a subprocessor list enough to satisfy the requirement?

Usually no. A subprocessor list helps with transparency, but this requirement expects you to provide an accounting tied to the data subject and your actual disclosures. Keep the list, then add the linkage to systems, identifiers, and disclosure pathways. ¹

What if we disclose data to third parties through customer-configured integrations?

Treat those as disclosures if your service enables or performs the transfer. Your accounting should reflect the integration recipient category and, where feasible, the specific third party endpoint tied to the data subject’s records.

How do we handle third parties that only have incidental access (support tools, consultants)?

Document whether access results in disclosure and under what conditions (role-based access, ticket attachments, screen sharing). Include those third parties in the inventory and describe the access-based disclosure path in the accounting when it applies.

What evidence will a SOC 2 auditor request to prove the control operated?

Expect to provide completed DSR tickets (or internal tests), the generated accounting outputs, and the underlying system evidence or ledger queries used to produce them, plus documentation showing the process is defined and owned. ¹

We have no DSR requests during the audit period. What do we do?

Run a documented internal test (tabletop or simulated request) during the period and retain the full evidence package. Auditors typically accept testing as operating evidence when real requests are absent, as long as it is realistic and complete.

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 TSC 2017