TSC-P2.1 Guidance

To meet the tsc-p2.1 guidance requirement, you must clearly communicate the privacy choices individuals have across the full personal information lifecycle: collection, use, retention, disclosure, and disposal. Operationalize it by publishing accurate notices and just-in-time prompts, implementing request/consent workflows, and retaining evidence that the choices were presented, captured, honored, and periodically reviewed ¹.

Key takeaways:

• Publish a single, authoritative set of privacy “choices” that matches how your systems actually process personal information ¹.
• Build repeatable workflows to capture, track, and honor choices across products, regions, and third parties ¹.
• Keep audit-ready evidence: versioned notices, consent/opt-out logs, ticket records, and control testing results ¹.

TSC-P2.1 is a Privacy criterion within the AICPA Trust Services Criteria used in SOC 2 examinations. It is not a “privacy policy exists” checkbox. Auditors will look for a working system where individuals are told what choices they have about their personal information, and the organization can prove those choices were actually available, presented at the right time, and respected in downstream processing ¹.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat TSC-P2.1 like an operational requirement with four deliverables: (1) a defined set of user choices (what a person can say “yes/no” to), (2) a communication layer (privacy notice + just-in-time disclosures), (3) an execution layer (workflows and technical enforcement so choices are honored), and (4) an evidence layer (logs, tickets, and review/testing artifacts). If any layer is missing, teams end up with “paper compliance”: notices that overpromise, or preference centers that do not map to real data flows.

This page gives requirement-level guidance you can implement quickly: who it applies to, the concrete steps, what artifacts to retain, and the exam questions you should be ready to answer.

Regulatory text

Excerpt (TSC-P2.1): “The entity communicates choices available regarding the collection, use, retention, disclosure, and disposal of personal information” ¹.

What the operator must do:
You need a controlled, repeatable way to (a) define what choices individuals have, and (b) communicate those choices in a manner that matches actual processing across your systems and third parties. The “choices” must cover the lifecycle listed in the criterion: collection, use, retention, disclosure, and disposal ¹. Practically, auditors expect you to show where these choices are presented (privacy notice, in-product prompts, contracts or onboarding flows), and how the organization ensures the choices are honored afterward ¹.

Plain-English interpretation (what TSC-P2.1 requires)

TSC-P2.1 requires two things to be true at the same time:

1. People can make meaningful privacy choices about how you handle their personal information ¹.
2. You tell them about those choices in a clear, accessible way, aligned to your real data practices ¹.

“Choices” may include consent, opt-out, preference settings, or other selectable options depending on your product and applicable privacy commitments. SOC 2 does not prescribe which choices you must offer; it evaluates whether you communicate the choices you claim to offer, and whether your controls support that communication and follow-through ¹.

Who it applies to (entity and operational context)

This applies to any organization undergoing a SOC 2 examination that includes the Privacy category ¹. In operational terms, it applies wherever your organization:

• Collects personal information through websites, apps, support channels, sales motions, integrations, or telemetry.
• Uses personal information for product delivery, analytics, marketing, fraud prevention, HR, or customer support.
• Shares personal information with third parties (processors, sub-processors, analytics providers, ad platforms, support tools).
• Retains and disposes of personal information under a documented retention schedule.

Common scoping reality: you may have different “data subjects” (end users, customer admins, prospects, employees). TSC-P2.1 applies to the populations included in your SOC 2 Privacy scope statement and system description. If the scope is unclear, auditors will challenge whether your communications cover what is actually in scope.

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

Step 1: Define the “choice catalog” (your authoritative list)

Create a controlled document that lists each privacy choice you offer and maps it to lifecycle stages ¹.

Minimum fields to include:

• Choice name (e.g., marketing opt-out; cookie preferences; data retention exception request)
• Population (end user, customer contact, employee)
• Where communicated (privacy notice section; in-product screen; cookie banner; contract addendum)
• How captured (checkbox; preference center; email link; support ticket)
• What systems enforce it (CRM, marketing automation, data warehouse, product flags)
• Who owns it (Product, Marketing Ops, IT, Privacy)
• SLA/handling target (your internal target; keep it consistent with what you communicate externally)

Practical tip: keep this as a table in a GRC system or controlled repository with change history. If the list is scattered across web pages, product flows, and internal wiki pages, it will drift.

Step 2: Align notices and just-in-time prompts to the choice catalog

Your privacy notice and in-product disclosures must reflect the choice catalog and the actual data flows ¹.

Execution checklist:

• Confirm the privacy notice describes choices across collection, use, retention, disclosure, disposal ¹.
• Add just-in-time disclosures where the notice is not enough (e.g., before enabling telemetry; before collecting sensitive fields; before sharing to a third party integration).
• Ensure the language matches reality. If you say “you can delete your data,” you need a workflow that reliably performs deletion (or a clear explanation of limits you apply).

Step 3: Implement operational workflows to honor choices

Auditors will test whether choices are honored in operations, not just stated ¹.

Build workflows for:

• Consent/opt-out capture: record the event, timestamp, source, and policy version shown at the time.
• Propagation: ensure downstream systems respect the choice (e.g., suppression lists for marketing; flags for analytics; data sharing toggles).
• Retention/disposal execution: connect choices to your retention schedule and deletion processes. If disposal is handled through batch jobs, define a control that verifies execution results.
• Third party alignment: where personal information is disclosed to third parties, confirm contracts and configurations support the individual’s choices where relevant ¹.

If you need a system of record, Daydream can act as the control hub: store the choice catalog, map it to systems and third parties, attach evidence, and run scheduled reviews and control tests without chasing screenshots across teams.

Step 4: Put monitoring and review on a calendar

TSC-P2.1 is easy to “implement once” and then break. Add a lightweight governance loop aligned to releases and third-party changes ¹.

Monitoring actions to standardize:

• Review privacy notice and in-product choice surfaces when product onboarding changes.
• Revalidate third-party disclosures when adding analytics, support tooling, marketing vendors, or new subprocessors.
• Sample-test requests (opt-out, deletion, preference changes) to confirm end-to-end completion, including downstream systems and third parties.

Step 5: Test control effectiveness and document results

Your SOC 2 auditor will ask how you know the control works ¹.

A practical testing approach:

• Select representative choices (marketing opt-out; cookies; deletion/disposal; data sharing toggle).
• For each, test: communication → capture → enforcement → evidence.
• Document the test steps, sample selection logic, results, and remediation if gaps exist.

Required evidence and artifacts to retain

Keep artifacts that prove communication, availability, operation, and review/testing ¹.

Evidence checklist (audit-ready):

• Versioned privacy notice and change log (with approval trail)
• Screenshots or recordings of in-product choice prompts and preference center flows (versioned)
• Consent/opt-out logs (exportable) showing timestamp, user identifier, and choice value
• Data request intake and fulfillment tickets (deletion, retention exceptions, disclosures)
• Retention schedule and disposal procedures; job run logs or deletion reports tied to systems
• Third-party inventory entries showing which third parties receive personal information and what configuration/contract terms support choices
• Periodic review records (meeting notes, sign-offs, or task completion evidence)
• Control test plan and test results, plus remediation tracking ¹

Common exam/audit questions and hangups

Expect auditors to press on these areas ¹:

1. “Show me where the choices are communicated.” They will request the notice and product UI evidence for scoped systems.
2. “How do you ensure choices are honored downstream?” You need mapping to systems (CRM, data warehouse, email tooling) and proof of suppression/enforcement.
3. “What happens when you disclose data to third parties?” They will ask for vendor/subprocessor alignment and how changes are governed.
4. “How do you know this still works?” They will want periodic review and testing evidence.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Privacy notice overpromises. Fix by tying every stated choice to a workflow owner, system enforcement point, and evidence source.
• Mistake: Preference center exists, but data pipelines ignore it. Fix by documenting propagation paths and implementing suppression at each “send” system (email platform, ad tools, analytics exports).
• Mistake: Retention and disposal are undocumented or manual. Fix by writing a disposal procedure, assigning ownership, and retaining disposal logs tied to systems ¹.
• Mistake: No periodic review. Fix by adding a recurring review triggered by product releases and third-party onboarding ¹.
• Mistake: Evidence is a scramble. Fix by storing artifacts in a single system with control IDs, dates, and scope notes; Daydream is a practical fit for that operating model.

Enforcement context and risk implications

SOC 2 is an audit framework, not a regulatory enforcement regime ¹. Your risk is still real: if your SOC 2 report includes Privacy, weak TSC-P2.1 control design or missing evidence can lead to exceptions, delayed reports, or a scope reduction that creates customer trust friction. Operationally, mismatched privacy choices also increase complaint risk and contractual exposure if you commit to choices you cannot reliably honor.

Practical 30/60/90-day execution plan

Days 1–30: Build the baseline and stop the bleeding

• Confirm Privacy is in scope for your SOC 2 and identify in-scope products and data subject groups.
• Draft the choice catalog and map each choice to systems, owners, and communication surfaces.
• Inventory all existing communications: privacy notice, cookie banner, preference center, in-app prompts, support macros.

Days 31–60: Implement workflows and evidence capture

• Implement or fix consent/opt-out logging and tie it to policy versioning.
• Build request workflows for choice execution (tickets, automation, runbooks).
• Align third-party disclosures: validate subprocessors and ensure choices can be honored in data sharing configurations.
• Set up the evidence repository structure (folders or GRC tool objects) and start collecting artifacts continuously.

Days 61–90: Prove effectiveness and operationalize reviews

• Run control tests for a sample of choices end-to-end; document results and remediation.
• Establish a recurring review cadence linked to releases and third-party onboarding.
• Update your SOC 2 system description inputs (as applicable) so the narrative matches implemented controls and actual choices ¹.

Frequently Asked Questions

Do we need a preference center to satisfy TSC-P2.1?

No. TSC-P2.1 requires that you communicate available choices and can support them operationally ¹. A preference center is one common mechanism, but just-in-time prompts, account settings, or ticket-based workflows can also work if they are consistent and auditable.

What if our product has no optional data collection, so there are few “choices”?

Then your “choices” may be limited, but you still must communicate what choices exist across collection, use, retention, disclosure, and disposal ¹. Document the minimal set (for example, marketing opt-out, account deletion) and ensure the notice matches reality.

How detailed should the communication be for retention and disposal choices?

Provide enough clarity so a person understands what options they have and how to exercise them, aligned to your actual retention and disposal practices ¹. If you have constraints, state them plainly and route requests through a defined workflow.

What evidence is most persuasive to auditors for “communication”?

Versioned privacy notices plus dated screenshots of the product flows where choices are presented ¹. Pair that with logs showing choices captured under the corresponding version of the notice or UI.

How do third parties affect TSC-P2.1?

If you disclose personal information to third parties, your communicated choices must remain true after disclosure ¹. That usually means contract terms, configuration controls, and operational steps to propagate opt-outs or deletion requests where applicable.

We operate in multiple regions with different privacy obligations. Can we have different choices by region?

Yes, but you must communicate the region-specific choices clearly and ensure your systems enforce the right behavior for each population ¹. Auditors will look for a clean mapping from region → notice/UI → enforcement logic → evidence.

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