TSC-P6.1 Guidance

TSC-P6.1 requires you to disclose personal information to third parties only when you have the data subject’s explicit consent for that disclosure ¹. To operationalize it fast, build a consent-to-disclosure rule set, tie it to a third-party disclosure inventory, enforce it in workflows (procurement, product, support), and retain auditable evidence that consent existed before each disclosure.

Key takeaways:

• Explicit consent must be provable at the time of disclosure, not inferred after the fact ¹.
• Operational success depends on mapping “disclosures” to real systems and third parties, then gating them through consent checks.
• Auditors will look for documented controls, consistent operation, and testing evidence aligned to your SOC 2 scope ¹.

The tsc-p6.1 guidance requirement shows up in SOC 2 Privacy engagements when your service collects, uses, or shares personal information and relies on consent as the permissioning basis for third-party sharing ¹. The trap is thinking of this as a policy-only requirement. In practice, it is a workflow and evidence requirement: you need to know which third parties receive personal information, under what circumstances, and how your organization captures, records, and enforces explicit consent before any disclosure occurs.

For a CCO or GRC lead, the fastest path is to treat TSC-P6.1 like a “gating control.” Create an authoritative inventory of third-party disclosures, define what “explicit consent” means for your context (product UI consent, signed authorization, or documented opt-in), then implement checks at the points where disclosures happen: integrations, exports, customer support, and onboarding. Your audit story must connect four things: (1) policy/procedure, (2) technical/operational enforcement, (3) monitoring and periodic review, and (4) a reliable audit trail ¹.

Regulatory text

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

Operator translation: if your organization shares personal information with any third party (processors, subprocessors, partners, affiliates, consultants, payment providers, analytics tools, shipping providers, etc.), you must be able to show that the individual explicitly agreed to that disclosure before it occurred, consistent with what you told them ¹.

What an auditor typically expects to see under this criterion:

• A documented rule for when explicit consent is required for third-party disclosures.
• A mechanism to capture and store explicit consent in a retrievable way.
• A way to prevent or detect disclosures that are not covered by explicit consent.
• Evidence that you monitor, review, and test the control in operation ¹.

Plain-English interpretation (what counts as “explicit consent”)

“Explicit consent” is permission that is affirmatively given and can be evidenced. For SOC 2, the key is not the UI design debate; it’s whether your control design and evidence show consent was explicitly obtained for the disclosure scenario ¹.

Practical markers of explicit consent you can defend in an audit:

• An opt-in checkbox that is unchecked by default and references the disclosure category.
• A signed authorization (including electronic signature) that authorizes sharing with a class of third parties.
• A recorded preference setting tied to the identity of the data subject and time-stamped.

Weak patterns that often fail scrutiny:

• Pre-checked boxes.
• Buried consent language that is indistinguishable from general terms.
• “Consent” inferred from product use without an affirmative action tied to the disclosure.

Who it applies to (entity and operational context)

This applies to organizations undergoing a SOC 2 engagement that includes the Privacy category and that disclose personal information to third parties as part of delivering the service ¹. You will feel this requirement most in these operational contexts:

• SaaS with subprocessors: hosting, support tooling, observability, analytics, communications platforms receiving end-user personal information.
• B2B platforms with customer data exports or integrations: API-based sharing with customer-selected third parties.
• Services teams: support or professional services sharing data with subcontractors or partners.
• Marketing operations: ad-tech, lead enrichment, event platforms, or email providers receiving identifiable data.

Scope matters. If your SOC 2 description claims you obtain consent for third-party disclosures, auditors will test it where disclosures actually happen.

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

Step 1: Build a “third-party disclosure inventory”

Create a list of third parties that receive personal information, and classify each disclosure. Minimum fields:

• Third party name and service provided
• Data categories disclosed (e.g., identifiers, contact info, usage data)
• Disclosure method (API, batch export, embedded script, manual sharing)
• Disclosure trigger (user action, system event, support workflow)
• Consent requirement (yes/no) and rationale
• System of record for consent evidence
• Owner (business + technical)

This inventory becomes your audit backbone. Without it, you will miss silent disclosures (embedded SDKs, logs shipped to vendors, support attachments).

Step 2: Define a consent rule set your teams can apply

Write a short procedure that answers:

• What disclosures require explicit consent versus those covered by contract performance or other permissions described in notices (keep it aligned to your privacy commitments).
• What counts as explicit consent in your product and offline workflows.
• How consent is refreshed if disclosure purposes or third parties materially change.
• What happens if consent is withdrawn.

Keep it operational: decision tree beats prose. Example decision points:

1. Is personal information disclosed outside the organization?
2. Is the recipient a third party acting for the service or for its own purposes?
3. Did the data subject take an affirmative action that authorizes this disclosure category?
4. Can we retrieve a timestamped record tied to the data subject?

Step 3: Implement consent capture and a system of record

Pick a single source of truth for consent status and history. Common patterns:

• Product consent table keyed by user ID with timestamps and consent version.
• Consent management platform logs exported to your data warehouse with retention controls.
• For offline consents, store signed authorizations in a controlled repository with indexing.

Design requirement: you must be able to answer, for a given disclosure event, “what consent existed at that time?” ¹.

Step 4: Gate disclosures at the points of execution

Add control points where disclosures occur:

• Integrations/API sharing: require a “consent=true + consent_version” attribute before enabling an integration that transmits personal information.
• Exports: restrict export jobs to approved purposes; require selection of consented population.
• Support tooling: prevent attaching or forwarding personal information to external third parties without an approval step that checks consent status.
• Embedded third-party scripts/SDKs: treat data collection that transmits identifiers as a disclosure and ensure consent gating occurs before script activation where applicable.

Step 5: Add monitoring, review, and periodic assessment

Auditors will ask how you know the control is working ¹. Set up:

• A periodic review of the disclosure inventory against procurement records, SSO app catalog, and data flow maps.
• Exception reporting (disclosures without consent signal, unusual export volumes, new third-party endpoints).
• A scheduled control test where you sample disclosure events and confirm consent evidence exists and matches the rule set.

Step 6: Maintain an audit trail that ties consent to disclosure

For each disclosure channel, ensure logs capture:

• data subject identifier (or a consistent pseudonymous ID)
• third party recipient (system/service)
• timestamp
• consent status and consent version at the time
• initiating actor (system/user) and change history

If you cannot tie consent to disclosure, you will end up with “we believe consent existed” narratives that auditors typically challenge.

Required evidence and artifacts to retain

Organize evidence so you can hand it to auditors quickly:

Governance artifacts

• Privacy policy/procedure covering third-party disclosures and explicit consent ¹.
• Defined roles and responsibilities (product, legal/privacy, security, vendor management).

Operational artifacts

• Third-party disclosure inventory with approvals and last review date.
• Data flow diagrams or system maps showing where disclosures occur.
• Consent UX screenshots or consent language samples (by version).
• Consent system-of-record schema or configuration documentation.

Evidence of operation

• Sampled disclosure logs showing consent attribute/version.
• Change tickets for new third-party disclosures showing consent impact assessment.
• Monitoring reports and exception tickets with resolution notes.
• Periodic assessment results and remediation tracking ¹.

Testing artifacts

• Internal control test plan, sampling approach, and results.
• Auditor walkthrough support: query outputs, screenshots, and log extracts (minimize manual compilation by standardizing reports).

Tooling note: platforms like Daydream can reduce scramble by centralizing the disclosure inventory, mapping third parties to data types, and packaging evidence requests into repeatable audit-ready collections.

Common exam/audit questions and hangups

Expect questions like:

• “Show me where explicit consent is captured, and how it is tied to the user identity.” ¹
• “List the third parties receiving personal information in scope, and show approvals.”
• “Pick five disclosures; prove consent existed before each disclosure.”
• “How do you prevent a new integration from going live without consent review?”
• “What happens when a user withdraws consent? Show revocation propagation.”
• “How do you test this control and document results?” ¹

Hangups that stall audits:

• Disclosures via logs/telemetry that were not treated as “third-party disclosures.”
• Consent captured in one system, while disclosures occur in another without a join key.
• Inability to show historical consent state (only current preference is stored).

Frequent implementation mistakes (and how to avoid them)

1. No authoritative disclosure inventory.
   Fix: reconcile procurement, app catalog, and data egress logs into one owned list.

2. Consent language doesn’t match reality.
   Fix: tie consent versions to release management; require privacy review for new third-party sharing paths.

3. Manual processes with no audit trail.
   Fix: move approvals into ticketing with required fields (third party, data, purpose, consent basis) and attach evidence.

4. Assuming “processor” equals “no consent needed.”
   Fix: do a disclosure-by-disclosure analysis against your privacy commitments and scope statement; document the rationale for when explicit consent is required ¹.

5. No control testing.
   Fix: schedule recurring samples of disclosure events and record pass/fail plus remediation actions ¹.

Enforcement context and risk implications

SOC 2 is an audit framework rather than a regulatory enforcement regime ¹. Your practical risk is audit findings: exceptions can lead to qualified opinions, delayed reports, customer trust friction, and increased scrutiny of your privacy program. Operationally, weak consent-to-disclosure controls also raise incident risk: unauthorized disclosures are hard to contain and harder to explain without clean evidence.

Practical 30/60/90-day execution plan

First 30 days: get to “known disclosures + documented rule”

• Assign an owner for TSC-P6.1 across privacy + security + product.
• Draft the consent-to-third-party-disclosure procedure and decision tree ¹.
• Build the initial disclosure inventory from: vendor list, subprocessors page, SSO app catalog, and top integrations.
• Identify your consent system of record and gaps (missing timestamps, missing versioning, missing identity mapping).
• Pick two high-volume disclosure paths and define gating requirements.

Days 31–60: enforce in workflows and start producing evidence

• Implement gating on integrations/exports/support workflows where feasible.
• Add logging fields required to tie disclosure events to consent status/version.
• Create standard audit queries/reports for: disclosure events, consent history, exceptions.
• Stand up monitoring and an exception process (ticket templates, owners, SLAs you define).
• Run your first internal control test sample; document results and fixes ¹.

Days 61–90: harden, test, and make it repeatable

• Expand the disclosure inventory coverage to long-tail tools (analytics, marketing, BI, email, customer success).
• Perform a periodic assessment: reconcile inventory against new contracts and new outbound data routes ¹.
• Add release gating: privacy/security review required for any new third-party disclosure.
• Compile an “audit packet” with policy, inventory, sample evidence, monitoring outputs, and testing results.
• If you use Daydream, align your third-party register, data types, and evidence collection to reduce recurring audit work.

Frequently Asked Questions

Does TSC-P6.1 mean we need explicit consent for every subprocessor?

No single answer fits every service design, but auditors will expect you to follow your stated privacy commitments and show explicit consent where your program requires it for disclosure to third parties ¹. Document the rule and apply it consistently.

What’s the minimum evidence to prove “explicit consent” in a SOC 2 audit?

You need a retrievable record tied to the data subject and timestamped, plus a way to show the consent covered the disclosure scenario and was obtained before disclosure ¹.

Our consent is stored in a CMP, but disclosures happen in backend services. Is that a problem?

It’s workable if you can reliably join disclosure events to consent state at the time via a shared identifier and consent versioning. Auditors commonly flag gaps where only current consent is accessible, or where event logs can’t be linked to the subject.

How do we handle consent withdrawal for ongoing third-party disclosures?

Define revocation behavior per disclosure type (stop future transfers, disable integration, delete/limit processing where applicable) and record the revocation event. Then show that downstream systems honor the change through logs, tickets, or automated enforcement evidence.

Are embedded analytics scripts considered “third-party disclosure”?

Treat any transmission of personal information to an external party as a disclosure for inventory and control design purposes, then apply your consent rule set. If the script sends identifiers or user-linked events to a third party, auditors will likely ask how consent is handled.

What will cause a TSC-P6.1 exception even if we have a policy?

The common failure is a disconnect between policy and operation: a third party receives personal information but you cannot show explicit consent evidence tied to the disclosure event, or you cannot show control testing and monitoring ¹.

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