The entity discloses personal information to third parties with the explicit consent of data subjects

To meet the entity discloses personal information to third parties with the explicit consent of data subjects requirement, you must (1) define what counts as a third-party disclosure, (2) collect explicit, informed consent before the disclosure, (3) log and enforce consent at the moment of sharing, and (4) retain evidence that consent was obtained and honored in production.

Key takeaways:

• “Explicit consent” must be affirmative, specific, and recorded before any third-party sharing of personal information.
• Operationalize the control by binding consent to a purpose, a third party (or category), a data set, and a time window, then enforcing it in systems.
• Auditors will ask for end-to-end proof: notice text, consent records, data-sharing inventory, technical enforcement, and exception handling.

SOC 2 Privacy criteria expects you to control how personal information moves outside your environment. TSC-P6.1 is simple on paper: if you disclose personal information to third parties, you do it with the explicit consent of the data subject. In practice, teams fail this requirement for one of three reasons: nobody agrees on what “disclose” includes, consent is captured but not enforced downstream, or the evidence trail is incomplete when an auditor samples transactions.

This page translates TSC-P6.1 into an operator-ready control you can implement quickly. You’ll set disclosure boundaries (what’s in scope), implement a consent model that is specific enough to survive audit sampling, and build a repeatable evidence package. The goal is not to generate more paperwork; it’s to make third-party sharing predictable, reviewable, and defensible during a SOC 2 examination.

Primary source: AICPA 2017 Trust Services Criteria (revised points of focus 2022) (AICPA TSC 2017).

Regulatory text

Requirement (TSC-P6.1): “The entity discloses personal information to third parties with the explicit consent of data subjects.” (AICPA TSC 2017)

What the operator must do:
You must ensure that any outbound sharing of personal information with a third party is conditioned on explicit consent from the individual, and you must be able to prove that consent existed at the time of disclosure. That means:

• your notices and consent prompts are clear enough to be “explicit,”
• consent is captured as an auditable record tied to the individual and the disclosed data,
• your systems and processes enforce consent (not just collect it),
• exceptions are defined, approved, and tracked if your program permits any non-consent disclosures (if you claim no exceptions, your inventory and technical controls must match that claim).

Plain-English interpretation

If you share someone’s personal information with an external organization, you need the person to actively say “yes” to that sharing, and you must keep a record that stands up to sampling. Pre-checked boxes, vague “we may share” language, or consent that is impossible to connect to a specific disclosure event will create audit findings.

Who it applies to

Entity scope: Service organizations seeking SOC 2 coverage for the Privacy criteria (AICPA TSC 2017).
Operational scope: Any team, system, or workflow that sends personal information to a third party, including:

• analytics, ad/marketing partners, and attribution tools
• customer support platforms and CRMs
• payment processors and fraud providers
• hosting, monitoring, and logging services if personal information is embedded in telemetry
• integrations and APIs where customer data is transmitted to a partner app
• professional services and subcontractors with access to personal information

A common scoping trap: teams treat “third-party disclosure” as only selling data or only marketing. For SOC 2 Privacy, treat it broadly as any sharing outside the entity boundary, then narrow via documented rationale.

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

Step 1: Build a third-party disclosure inventory (the “where does PI go” list)

1. Enumerate third parties that receive personal information (directly or via access).
2. For each third party, record:
   • purpose of disclosure (why data is shared)
   • categories of personal information shared (e.g., identifiers, contact details, usage data)
   • method of transfer (API, SFTP, embedded script, manual export)
   • system of record that initiates the transfer
   • whether the third party is a subprocessors/contracted processor, partner, or independent recipient (use your internal classification consistently)
3. Identify “shadow disclosures”: logs, error traces, session replay, email forwarding, spreadsheet exports.

Output: Third-party disclosure register (this becomes your audit sampling universe).

Step 2: Define what “explicit consent” means in your program

Create a written standard that answers, in one page:

• what qualifies as explicit (affirmative action required; no bundled consent; no pre-checked boxes)
• what information must be presented at the time of consent (who receives data or recipient category, what data, purpose)
• how consent is captured and stored (system, fields, immutable logs)
• how consent is withdrawn and how withdrawal affects future disclosures

Keep the definition aligned to TSC-P6.1’s plain meaning. Avoid vague internal language like “implied consent is acceptable,” unless you can defend it within the SOC 2 Privacy narrative and your commitments.

Step 3: Implement consent capture tied to disclosures (not just to accounts)

For each disclosure type in your register, pick a consent pattern:

Disclosure scenario	Recommended consent pattern	What must be recorded
Marketing/advertising sharing	Opt-in checkbox or toggle separate from Terms	Timestamp, consent text/version, purpose, recipient category, user ID
Product integration initiated by user	“Connect” flow with clear data-sharing statement	Integration name, scopes/data categories, timestamp, user/admin identity
Support ticket sharing to a platform	Consent embedded in privacy notice + explicit support submission statement if needed	Notice version + event record that user submitted ticket under that notice
Bulk exports to a partner	Admin-only action gated by contract + end-user consent where required	Export approver, dataset, partner, consent basis mapping

Operational rule: Consent needs to be referenceable from the disclosure event. If an auditor samples a data transfer, you should be able to retrieve the matching consent record without manual reconstruction.

Step 4: Enforce consent at the moment of disclosure

Collection without enforcement fails in practice. Add controls in the path where disclosures occur:

• Application logic checks: before calling a third-party API, verify consent flag and purpose match.
• Tag management governance: block third-party tags/scripts unless the user has opted in, and document how the block works.
• API gateway or middleware policies: validate consent claims for outbound sharing services.
• Data pipeline controls: ensure ETL jobs filter out records without consent before sending to third parties.
• Manual process controls: for one-off exports, require a checklist and approval that confirms consent status.

Step 5: Version and preserve consent language

Auditors will look for drift: the consent record says “v3,” but you can’t produce what “v3” was. Put consent text under change control:

• store the exact consent language and UI screenshot per version
• map effective dates
• require review/approval before changes go live (privacy + legal + product, as applicable)

Step 6: Handle withdrawal, changes, and exceptions

Define and test:

• how a user withdraws consent (UI control or request intake)
• how quickly withdrawals propagate to disclosure systems (define an internal SLA as a policy commitment you can meet)
• what happens to already-disclosed data (contractual deletion requests, if applicable, and process to trigger them)
• whether any disclosures occur without consent, and if so, how they are approved, documented, and communicated in your privacy commitments (keep the story consistent with TSC-P6.1 and your public notices)

Step 7: Monitor and prove operation (make it auditable)

• Run periodic reconciliations: disclosure logs vs. consent status at time of transfer.
• Sample disclosures monthly and verify the evidence chain end-to-end.
• Track defects as incidents: “disclosed without consent” should have severity, containment, and corrective actions.

Daydream fit (when it’s the natural resolution): teams often have the consent record in one system, the disclosure logs in another, and third-party inventories in spreadsheets. Daydream can act as the control hub to assign owners, collect evidence, and keep your disclosure register, consent control design, and operating evidence packaged for SOC 2 testing.

Required evidence and artifacts to retain

Keep evidence in a form that supports sampling and re-performance:

Policy & design

• Privacy policy/notice excerpts describing third-party sharing and consent approach
• Consent standard (explicit consent definition, withdrawal handling)
• Data flow diagrams showing outbound sharing points (high-level is fine if it is accurate)
• Third-party disclosure register (with owner and last review date)

Operational evidence

• Consent records export (fields: user/subject identifier, timestamp, consent purpose, consent text/version, method)
• System logs showing consent enforcement at disclosure time (API logs, ETL job logs, tag manager settings evidence)
• Screenshots or configuration exports from consent management tooling
• Change tickets/approvals for consent language revisions
• Samples of disclosures mapped to consent records (auditor-ready workbook)

Third-party governance tie-in

• Contracts/DPAs or relevant third-party terms that reflect the authorized purpose of sharing (store references, not necessarily full agreements in the audit binder)
• Subprocessor lists and onboarding documentation if your program treats those recipients as third parties receiving personal information

Common exam/audit questions and hangups

• “Show me three examples of personal information disclosures to third parties and the matching explicit consent records.”
• “How do you prevent third-party tags from firing before opt-in?”
• “What happens if a user withdraws consent? Show system behavior and logs.”
• “How do you know your inventory of third-party disclosures is complete?”
• “When consent language changes, how do you preserve old versions and connect them to historical consent records?”

Hangup pattern: teams provide a privacy policy and a checkbox screenshot, but cannot demonstrate that disclosures were technically blocked when consent was absent.

Frequent implementation mistakes (and how to avoid them)

1. Bundled consent inside Terms of Service.
   Fix: separate consent from contract acceptance; make it purpose-specific.

2. Consent captured, but not connected to the data transfer.
   Fix: include consent lookup in outbound services; store consent version and purpose alongside disclosure events.

3. Unknown third-party disclosures through logs and analytics.
   Fix: review telemetry payloads, session replay tools, and tag manager inventory; treat them as disclosures if personal information is present.

4. No version control for consent text.
   Fix: store consent language in a repository with approvals; record effective dates.

5. Withdrawal path exists but does not propagate.
   Fix: implement propagation workflow and validate it with tests; keep evidence of test runs.

Enforcement context and risk implications

SOC 2 is an attestation against the Trust Services Criteria rather than a regulator-driven enforcement regime. Your practical risk is a SOC 2 finding (control design gap or operating ineffectiveness) if you cannot prove explicit consent existed and was enforced for disclosed personal information (AICPA TSC 2017). The business impact is deal friction, customer security reviews, and remediation work under audit timelines.

A practical 30/60/90-day execution plan

Days 1–30: Get to a defensible design

• Stand up the third-party disclosure register with owners.
• Draft the explicit consent standard and map it to each disclosure type.
• Identify the top disclosure paths (analytics, marketing tags, support, integrations) and document current-state enforcement.
• Implement consent text versioning and approvals (even if manual at first).
• Define withdrawal workflow and internal propagation expectations.

Days 31–60: Build enforcement and evidence

• Add consent checks to outbound APIs and data pipelines for the highest-risk disclosures.
• Lock down tag manager governance; document how tags are blocked pre-consent.
• Create an auditor sampling workbook template: disclosure event → consent record → evidence link.
• Run a pilot test: pick a small sample of disclosure events and prove you can retrieve consent records quickly.

Days 61–90: Operationalize monitoring and audit readiness

• Implement periodic reconciliation between disclosure logs and consent status.
• Train engineering, marketing ops, and support on “no consent, no share” procedures.
• Add change management checkpoints: no new third-party disclosure goes live without register entry and consent mapping.
• Package evidence in Daydream (or your GRC system) by control objective: design docs, logs, and sample sets.

Frequently Asked Questions

Does “third party” include subprocessors like cloud hosting or error monitoring tools?

Treat any external organization that receives or can access personal information as a third party for purposes of your disclosure analysis. If you exclude a category, document the boundary and ensure your data flows support that claim (AICPA TSC 2017).

What qualifies as “explicit” consent for SOC 2 Privacy?

Explicit consent requires an affirmative action that is specific to the disclosure and purpose. Record the consent in a way you can retrieve during audit sampling, including the consent language/version and timestamp (AICPA TSC 2017).

Can we rely on a general privacy policy statement instead of an opt-in?

A general statement rarely provides strong evidence of explicit consent by the individual. If you use notice-based consent, you still need an event or workflow that demonstrates the person affirmatively agreed under that specific notice version.

How do we handle user withdrawal of consent if data has already been sent to a third party?

Your control should stop future disclosures after withdrawal and trigger whatever downstream actions your agreements and privacy commitments require. Keep a record of the withdrawal event and the actions taken so you can prove operation.

What evidence will an auditor most likely sample?

Expect samples of actual disclosure events and the related consent records, plus configuration evidence that disclosures are blocked without consent. Auditors also test change management around consent language versions (AICPA TSC 2017).

We have multiple products and regions. Do we need different consent flows?

You need consent that matches the actual disclosure purposes and commitments for each product context. If requirements differ by region or product, reflect that in your consent model, register entries, and evidence approach.

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