The entity provides notice to data subjects about privacy practices

SOC 2 Privacy criteria expect a service organization to be explicit with data subjects about how it handles personal information. For most teams, the hard part is not writing a privacy policy; it’s making the notice (1) complete for your environment, (2) consistent across product, contracts, and support workflows, and (3) auditable over time.

Auditors will test that your notice exists, is accessible to the right people at the right time, and reflects your actual privacy practices. If your data flows change faster than your notice, you will drift out of compliance. If you cannot show what notice a user saw at the time their data was collected, you create an evidence gap that is painful in a SOC 2 examination.

This page gives requirement-level implementation guidance for a Compliance Officer, CCO, or GRC lead who needs to put TSC-P1.1 into operation quickly: scope decisions, step-by-step actions, artifacts to retain, common exam questions, and a pragmatic 30/60/90-day plan.

Requirement: Provide notice to data subjects about privacy practices (SOC 2 Privacy)

Plain-English interpretation

You must tell people, in a reasonably easy-to-find and understandable notice, what you do with their personal information. That notice must be accurate for your service and updated when practices change. You also need a repeatable way to show an auditor: “Here is the notice, here is when it was effective, here is how it was delivered, and here is how we controlled changes.”

This requirement is frequently misunderstood as “post a privacy policy on the website.” Posting is necessary in many contexts, but SOC 2 also cares about notice being provided in the operational reality where data is collected (web app signup, marketing pages, mobile apps, support intake, HR portals, customer integrations, and third parties acting on your behalf).

Regulatory text

SOC 2 Trust Services Criteria (Privacy) excerpt: “The entity provides notice to data subjects about privacy practices.” ¹

Operator meaning: maintain a privacy notice that covers your privacy practices and make it available to data subjects in the contexts where you collect or otherwise process their personal information. Prove it with versioned notices, delivery points, and governance records tied to real processing.

Who it applies to (entity and operational context)

Entity scope (typical SOC 2):

• Service organizations seeking SOC 2 reporting that include the Privacy category (not just Security/Availability/Confidentiality).
• Organizations processing personal information about end users, customers’ end users, prospects, website visitors, job applicants, contractors, or employees.

Operational contexts where notice must be considered:

• Direct collection: account creation, checkout, lead forms, newsletter signups, product telemetry prompts, cookie banners (if used), support tickets.
• Indirect collection: data received from customers (B2B SaaS), resellers, referral partners, enrichment providers, identity providers.
• Sensitive handling moments: when you change purpose, add a new disclosure category, or introduce a new tracking/analytics tool that changes what you collect.
• Third parties: processors/subprocessors that affect what you disclose and why.

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

Step 1: Define “data subject” populations and collection points

Create an inventory of who you collect personal information from and where that happens.

• Populations: prospects, website visitors, product users, customer admins, customer end users, job applicants, employees.
• Collection points: marketing site forms, application signup/login, in-app settings, mobile app permission prompts, support portal, email inbound, HR systems.

Output: “Notice Coverage Map” (table) listing population → collection point → notice mechanism → notice version.

Step 2: Draft (or revise) a privacy notice that matches your processing

Your privacy notice should be written so a reasonable person can understand it, and it must reflect reality. At a minimum, make sure it clearly addresses:

• Categories of personal information you collect (at a usable level of detail for your service).
• Purposes for collection and use.
• Categories of disclosures (including key types of third parties/subprocessors, described by category).
• Retention approach (how you decide how long to keep data).
• Security measures described at a high level (avoid overpromising).
• Individual rights and how to exercise them (intake channels, verification, response workflow linkage).
• Contact methods (privacy email, address if applicable).
• Effective date and how changes are communicated.

Practical drafting rule: if engineering or product would say “we don’t do that,” delete it. If they say “we also do X,” add it.

Step 3: Implement notice delivery where it matters

Pick delivery mechanisms appropriate to each collection point. Common patterns:

• Website footer link to Privacy Notice on all public pages.
• Just-in-time notice near forms (“By submitting…” with link).
• In-product notice at signup or first-run, with a link to the current notice.
• Support intake notice in ticketing portals or auto-replies where personal data is collected.
• Employee/applicant notice in HR portals or offer packet materials (if in scope).

Evidence mindset: an auditor may sample a collection point. Make the notice link obvious, consistent, and testable.

Step 4: Create governance and change control for the notice

SOC 2 problems show up when the notice is outdated. Put a control around changes:

• Assign an owner (Privacy Officer, Legal, or Compliance).
• Define review triggers: new product feature that collects new data, new analytics/ads tools, new subprocessors, new regions, new retention behavior.
• Require cross-functional review (Product + Security + Legal/Compliance) before publishing updates.
• Version the notice and keep an archive.

Control design you can defend: “No material change to personal data collection/use/disclosure goes live until the privacy notice impact is assessed and, if needed, the notice is updated and published.”

Step 5: Tie the notice to your data map and third-party inventory

Your notice is only credible if it aligns with:

• Data inventory / RoPA-like records (even if you don’t call it that).
• Subprocessor list (if you publish one) and internal third-party register.
• Customer contracts and DPAs (avoid contradictions such as “we never share data” while using subprocessors).

If you manage third parties in Daydream, treat subprocessors and data-sharing partners as a tracked population with owners, data categories, and disclosure purposes mapped back to the notice. This makes audits faster because you can show traceability from public notice to operational reality.

Step 6: Test and capture operating evidence

Before the audit window:

• Click-test every notice link from each collection point.
• Confirm the notice is accessible without authentication where appropriate.
• Capture screenshots and/or exported page versions.
• Confirm the effective date and archived versions are retained.
• Run a spot-check: pick one user journey end-to-end and verify notice appears where expected.

Required evidence and artifacts to retain

Auditors will ask for proof that the control exists and operated during the period. Retain:

• Current privacy notice (HTML/PDF) with effective date.
• Archived prior versions with dates (repository, CMS version history, or PDF snapshots).
• “Notice Coverage Map” (collection points and delivery mechanisms).
• Change control records: tickets/PRs, approvals, release notes tied to notice updates.
• Screenshots of notice links on key pages and in-product flows.
• Data processing inventory excerpts that support statements made in the notice.
• Training or internal guidance for staff who publish site/app changes (so they know to trigger privacy review).

Common exam/audit questions and hangups (SOC 2)

Expect these lines of inquiry:

• “Show me where users see the notice at the point of collection.” Be ready with your Coverage Map and screenshots.
• “How do you ensure the notice stays accurate?” Show change triggers, review workflow, and examples of past updates.
• “Which notice version was effective during the audit period?” Provide version history and publication dates.
• “Does your notice reflect your subprocessors and disclosures?” Show mapping to third-party inventory and categories of disclosure.
• “Who approved the last update?” Provide approver names/roles and ticket evidence.

Frequent implementation mistakes (and how to avoid them)

1. Generic template notice that overpromises.
   Avoid absolute statements (“we never share”) unless you can prove it across all systems and third parties.

2. Notice exists, but isn’t provided at real collection points.
   Fix by mapping each intake path and adding links or just-in-time disclosures in forms and product flows.

3. No versioning or archive.
   Fix by publishing from a controlled system (repo/CMS with history) and exporting periodic snapshots.

4. Change control bypassed by Marketing or Product.
   Fix by adding privacy review to release checklists and web tag/analytics onboarding workflows.

5. Privacy notice contradicts contracts, security docs, or support scripts.
   Fix by running a consistency review across DPA, MSA, subprocessor disclosures, and customer-facing FAQs.

Enforcement context and risk implications

SOC 2 is an attestation framework, not a regulator, and this page does not list public enforcement cases because none were provided in the source catalog for this requirement. The practical risk remains: inadequate notice can trigger audit findings, customer trust issues during security reviews, and contractual disputes if customers rely on your stated practices and your operations differ.

Practical 30/60/90-day execution plan

30 days: establish baseline and stop the bleeding

• Identify in-scope data subjects and collection points; draft the Notice Coverage Map.
• Inventory current privacy notice locations and owners (website, app, docs).
• Perform a gap check: compare notice statements to current data collection, disclosures, retention, and subprocessors.
• Put temporary change control in place: “privacy review required” for new tracking tools, new forms, and new data-sharing partners.

60 days: operationalize delivery and governance

• Update privacy notice content to align with actual processing.
• Implement notice delivery fixes: footer links, form disclosures, in-product links, support portal notices.
• Establish versioning and archiving (repo/CMS history + periodic PDF snapshots).
• Define and socialize review triggers; add to launch checklists and third-party onboarding.

90 days: harden evidence and audit readiness

• Run a formal control test: sample multiple collection points and capture evidence.
• Execute one end-to-end walkthrough (user journey) and record proof of notice delivery.
• Validate mapping between the notice and your third-party inventory/subprocessor list.
• Prepare an audit packet: notice versions, change tickets, screenshots, and the Coverage Map.

Frequently Asked Questions

Do we need a privacy notice if we only process customer data as a B2B SaaS provider?

Yes, if you include SOC 2 Privacy, you still need to address notice for the data subjects whose data you process, even if your customer is the direct collector. Coordinate with customers on how notice is provided and ensure your disclosures about processing roles align with your contracts.

What counts as “provides notice” for in-product data collection?

A visible link to the current privacy notice at signup or within the workflow where data is first collected is the usual pattern. Keep evidence (screenshots, release records) showing the notice was present during the audit period.

How do we handle notice for support tickets where users paste sensitive information?

Add a short disclosure in the support portal and/or ticket submission UI that links to the privacy notice and discourages sharing sensitive data unless required. Train support staff on handling and deletion/escalation when sensitive data is received.

How often do we need to review the privacy notice?

Review on change triggers rather than relying only on a calendar. Add a periodic review cadence as a backstop, but treat new data collection, new disclosures, and new third parties as mandatory review events.

What evidence is most persuasive to a SOC 2 auditor?

Versioned privacy notice artifacts (with effective dates), screenshots from collection points, and change control records tied to real releases. A Coverage Map that connects each data subject touchpoint to the notice location reduces sampling friction.

Where does Daydream fit into this requirement?

Daydream helps you keep notice statements aligned to operations by tracking third parties, subprocessors, and disclosure purposes, and by keeping control design and operating evidence organized for audit requests. The value shows up when you need to prove traceability from your published notice to real data flows.

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