The entity communicates choices available regarding the collection, use, retention, disclosure, and disposal of personal information

To meet the the entity communicates choices available regarding the collection, use, retention, disclosure, and disposal of personal information requirement (SOC 2 TSC-P2.1), you must clearly tell individuals what privacy choices they have and make those choices real in operations (systems, workflows, and third parties). Publish the choices, capture and honor preferences, and retain evidence that the choices were presented and followed. ¹

Key takeaways:

• Communicate choices at the point of collection and anywhere your use/disclosure/retention changes. ¹
• Operationalize choices with workflows: intake, identity verification, fulfillment SLAs, and suppression lists. ¹
• Keep auditor-ready evidence: screenshots, consent logs, preference records, and testing showing choices are enforced. ¹

SOC 2 Privacy criteria expects more than a posted privacy policy. TSC‑P2.1 focuses on whether people are told what choices they have related to the full data lifecycle: collection, use, retention, disclosure, and disposal of personal information. If your company collects personal information through a product, website, mobile app, support channel, or integrations, this requirement is about making sure the individual’s options are understandable, accessible, and consistently presented.

For a CCO or GRC lead, the fastest path is to treat “choices” as a controlled system: define what choices you offer, decide where you present them, implement capture and propagation across systems, and prove it happened. Auditors usually look for mismatches between what you say and what your systems actually do (for example, you claim users can opt out, but marketing still sends email; you claim deletion is supported, but backups and third parties are ignored). TSC‑P2.1 is “medium” severity in many SOC 2 programs because it can become a report exception quickly when evidence is thin or execution is inconsistent, even without a breach. ¹

Regulatory text

SOC 2 Trust Services Criteria – Privacy (TSC‑P2.1) excerpt: “The entity communicates choices available regarding the collection, use, retention, disclosure, and disposal of personal information.” ¹

Operator interpretation (what you must do):

1. Define the privacy choices you offer (opt-in/opt-out, preference controls, retention options where applicable, access/deletion pathways, disclosure controls). ¹
2. Communicate those choices clearly to the individual, in context (where data is collected and where it is used or shared). ¹
3. Make the choices enforceable through processes and technical controls, and retain evidence that choices are honored end-to-end. ¹

Plain-English requirement meaning

A person whose personal information you handle should be able to understand:

• What information you collect and what happens if they refuse or limit it.
• How you use it (including optional uses like marketing, analytics, product improvement).
• How long you keep it and what triggers deletion/disposal.
• Who you share it with (including categories of third parties) and what choices they have.
• How they can request disposal (or other actions) and what the process looks like.

For SOC 2, the “communicates choices” bar is met when communication is not hidden, not misleading, and not contradicted by operational reality. ¹

Who it applies to

In-scope entities

• Service organizations undergoing a SOC 2 engagement that collect, process, transmit, store, or disclose personal information. ¹

Common operational contexts that trigger this control

• Web/mobile onboarding (sign-up forms, “contact us,” trial flows).
• Cookies and tracking (preferences, opt-out/opt-in where applicable).
• Customer support (tickets often contain personal information; disclosure to subprocessors is common).
• Marketing operations (email/SMS preferences, suppression).
• Product telemetry and analytics (choices around optional data collection).
• Data sharing with third parties (cloud hosting, support tooling, CRM, analytics, payment processors).

If personal information flows through multiple systems, your choices must propagate across those systems or your “communication” becomes empty. ¹

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

Step 1: Build a “choices inventory” tied to data lifecycle stages

Create a one-page matrix that lists:

• Choice (e.g., marketing opt-out; cookie settings; account deletion request; data sharing limitation where offered)
• Lifecycle stage (collection/use/retention/disclosure/disposal)
• Where presented (UI screen, footer link, settings page, just-in-time notice)
• How captured (checkbox, toggle, form, email link, preference center)
• System of record (where the preference lives)
• Downstream systems impacted (CRM, email tool, analytics, data warehouse)
• Owner (Product, Legal, Marketing Ops, Security/GRC)

This becomes your SOC 2 control design artifact for TSC‑P2.1. ¹

Step 2: Standardize the communications (layered notices)

Use a layered approach:

• Short notice at the point of collection (what you collect + key choices + link to full notice)
• Full privacy notice (expanded detail)
• In-product settings / preference center (where the individual can act)

Make sure your language matches the choices you truly support. If you cannot operationalize a “retention choice,” don’t imply it exists. ¹

Step 3: Implement capture + propagation as an engineered workflow

Auditors will test whether your choices are honored. Build or document a workflow with:

• Preference capture (UI or form submission)
• Identity binding (account ID, email, device identifier, cookie ID, or a documented method)
• Propagation mechanism (API sync, webhook, scheduled job, manual ticket with controls)
• Enforcement points
  • marketing sends check suppression list
  • analytics tags check consent state
  • support disclosures follow ticketing workflow
  • deletion requests trigger tasks across systems and third parties

If you rely on manual steps, add a control: ticket templates, required fields, approval gates, and completion checks. ¹

Step 4: Cover retention, disclosure, and disposal explicitly

Many teams cover collection and use, but fail the “retention/disclosure/disposal” language. Address each:

• Retention: publish retention principles and where the person can request deletion (or what is automatic). Map retention to systems.
• Disclosure: name categories of third parties and the purpose of sharing; point to a subprocessors list if you maintain one.
• Disposal: explain how to request deletion and what it means operationally (account closure, de-identification, backup handling described at a high level).

You do not need to promise outcomes you can’t verify; you do need a truthful description of your process and options. ¹

Step 5: Train the “human interface” teams

Privacy choices fail in support and sales channels. Provide:

• Macros/scripts for support: where to send requests, what to collect, what not to promise
• Escalation path to privacy ops/security
• Rules for disclosure (for example, when a customer asks for logs that may include personal information)

Training evidence matters as much as product UI screenshots in SOC 2 testing. ¹

Step 6: Test and keep operating evidence

Run periodic checks:

• Submit opt-out, confirm no further marketing is sent.
• Change cookie preferences, confirm tags stop firing where applicable.
• Submit deletion request, confirm systems and key third parties receive the instruction.

Use Daydream (where it fits) to keep a living evidence binder: control narrative, screenshots, sampled tickets, exports from preference systems, and test results mapped to TSC‑P2.1 so your audit doesn’t become a scavenger hunt.

Required evidence and artifacts to retain

Keep artifacts that show both communication and operation:

Communications evidence

• Current privacy notice and change log/approval record
• Screenshots of just-in-time notices, consent screens, cookie banner, preference center
• Copies of relevant onboarding or support forms that present choices

Operational enforcement evidence

• Consent/preference logs (exports showing timestamp, user ID, preference state)
• Suppression list logic documentation (how marketing tools honor opt-outs)
• Tickets for privacy requests (intake, verification, actions taken, closure notes)
• Data retention schedule or retention mapping (system-by-system)
• Subprocessor/third-party inventory showing disclosures and purposes

Governance evidence

• Control design document for TSC‑P2.1 (narrative + RACI)
• Training materials and attendance/acknowledgments for teams handling requests ¹

Common exam/audit questions and hangups

Auditors commonly ask:

• “Show me where a user is told their choices at collection.” ¹
• “Demonstrate an opt-out end-to-end, including downstream tools.” ¹
• “How do you communicate retention and disposal options?” ¹
• “How do you ensure third parties honor deletion/disposal requests?” ¹
• “What happens when data is collected through support or sales channels?” ¹

Hangups that cause exceptions:

• policy says one thing; product does another
• choices exist, but only for logged-in users (no path for prospects/support contacts)
• deletion described vaguely with no evidence trail
• no proof that third parties were included in fulfillment

Frequent implementation mistakes (and how to avoid them)

1. Overpromising choices you can’t execute.
   Fix: draft choices from your actual system capabilities; add roadmap items separately. ¹

2. Treating cookie consent as the only “choice.”
   Fix: explicitly cover retention, disclosure, and disposal in both notice and workflows. ¹

3. Preferences stored in multiple places with no source of truth.
   Fix: designate a system of record and document propagation. ¹

4. Manual fulfillment without controls.
   Fix: ticket templates, required approvals, and completion verification steps. ¹

5. Ignoring third parties in disposal requests.
   Fix: link privacy request workflows to your third-party inventory and DPA contact process. ¹

Enforcement context and risk implications

SOC 2 is an attestation framework, not a regulator. Your immediate risk is a SOC 2 exception or a qualified opinion if auditors cannot validate that choices are communicated and honored. Downstream, misleading or inconsistent privacy choice communications can also create exposure under privacy and consumer protection laws, but this page stays anchored to SOC 2 evidence expectations per the Trust Services Criteria. ¹

Practical 30/60/90-day execution plan

Days 1–30: Define and document the control

• Build the choices inventory matrix (collection/use/retention/disclosure/disposal). ¹
• Draft or revise the privacy notice sections that describe choices, focusing on accuracy. ¹
• Identify systems of record for consent/preferences and gaps in propagation.
• Write the TSC‑P2.1 control narrative: “what we communicate,” “where,” “how we capture,” “how we enforce,” “what evidence we keep.” ¹

Days 31–60: Implement workflows and evidence capture

• Implement or harden preference capture (product settings, preference center, cookie banner config).
• Add support intake workflow for privacy requests (form or ticket type) with verification and closure requirements.
• Update third-party inventory entries to show disclosures and disposal request routing.
• Start saving evidence monthly: screenshots, exports, and sampled tickets mapped to TSC‑P2.1. ¹

Days 61–90: Test, fix, and prepare for audit sampling

• Perform end-to-end tests for opt-out and deletion requests across key systems and third parties.
• Remediate mismatches between notice text and actual behavior.
• Train support/sales teams; retain attendance and job aids. ¹
• Package evidence in a tool (Daydream or your GRC system) so audit requests can be satisfied quickly with consistent samples.

Frequently Asked Questions

Do we need an in-product preference center to satisfy TSC‑P2.1?

Not strictly, but you need a clear way for individuals to see and exercise choices. If you only offer email-based requests, document the process and retain tickets proving consistent fulfillment. ¹

What counts as “communicates choices” for retention and disposal?

You should describe what options exist (for example, account deletion request) and how to initiate them. Then keep evidence that requests flow through systems and, where applicable, to third parties. ¹

We share personal information with third parties. Do we have to list every one publicly?

TSC‑P2.1 focuses on communicating choices; teams commonly communicate categories of recipients and purposes, plus a subprocessors list where maintained. Ensure the disclosures you describe match your third-party inventory. ¹

How do we show auditors that opt-outs are honored?

Provide screenshots of the choice being presented, an export/log showing the preference captured, and evidence of enforcement in downstream tools (for example, suppression list membership or campaign exclusion). ¹

What if we can’t delete data from backups immediately?

Don’t imply immediate deletion if your process doesn’t support it. Describe your disposal process truthfully at a high level and show the operational steps you do perform and track. ¹

Who should own this control: Legal, Security, or Product?

Assign shared ownership: Legal defines the promise, Product/Engineering implements capture and enforcement, Security/GRC runs testing and evidence. Put the RACI in the control narrative so audits don’t stall. ¹

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