TSC-P1.1 Guidance

To meet the tsc-p1.1 guidance requirement, you must provide clear, accessible notice to data subjects about your privacy practices, and be able to prove that notice is accurate, current, and consistently delivered across your products and data collection points ¹. Operationalize it by inventorying where you collect personal information, mapping each touchpoint to the correct notice, and instituting a review-and-approval workflow with retained evidence.

Key takeaways:

• Publish privacy notices where data subjects will actually see them before or at collection, not buried after the fact ¹.
• Treat privacy notice content as a controlled compliance artifact with owners, versioning, approvals, and periodic review evidence ¹.
• Auditors will test both design and operation: “Is the notice adequate?” and “Can you prove it was in place during the audit period?” ¹.

TSC-P1.1 sits in the SOC 2 Privacy criteria and is simple to state but easy to fail in execution: your organization must provide notice to data subjects about privacy practices ¹. For a CCO or GRC lead, the fastest path is to treat “notice” like a production control, not a legal webpage. It has scope (which products, regions, and populations), distribution (where and when users see it), content governance (who approves changes), and evidence (what you can hand an auditor).

This requirement tends to break in three places. First, the organization cannot enumerate all the places personal information is collected (web forms, mobile SDKs, support tickets, HR portals, marketing events). Second, notices drift out of sync with real data practices as engineering or marketing changes flows. Third, teams cannot prove what notice was presented during the audit period, especially when notices are updated without version control.

The guidance below is written to help you implement a defensible, auditable “privacy notice” control quickly, with artifacts that stand up in a SOC 2 examination mapped to TSC-P1.1 ¹.

Regulatory text

TSC-P1.1 (excerpt): “The entity provides notice to data subjects about privacy practices” ¹.

What the operator must do

You must (1) define your privacy notice obligations for the personal information within SOC 2 scope, (2) publish notices in the right places and at the right times, and (3) maintain evidence that the notice existed, was accurate, and was reviewed under a controlled process during the audit period ¹.

Plain-English interpretation (what “notice” means in practice)

A privacy notice is your plain-language explanation to people whose personal information you process. It should answer: what you collect, why, how you use it, who you share it with, and what choices or rights the person has. TSC-P1.1 is not asking for perfection in legal drafting; it is asking for consistent, accessible disclosure of your privacy practices to data subjects, backed by governance and proof ¹.

A SOC 2 examiner typically expects the notice to be:

• Available: easy to find where collection happens (web, app, onboarding, support intake).
• Consistent: aligned with actual processing and internal policies.
• Controlled: changes are reviewed, approved, and tracked.
• Provable: you can demonstrate what notice was in effect during the period ¹.

Who it applies to (entity + operational context)

Applies to: Organizations undergoing a SOC 2 audit that include the Privacy category in scope ¹.

Operational contexts where TSC-P1.1 commonly applies:

• Customer-facing SaaS products collecting account, billing, usage, or support data
• Mobile apps collecting identifiers, telemetry, location, or contacts
• Marketing sites collecting leads through forms, chat, or cookies (as applicable to your scope)
• B2B services that collect end-user data on behalf of customers (processor/service provider context)
• Internal portals that collect employee or applicant data, if included in audit scope

Key scoping decision: Define “data subjects” for your SOC 2 boundary. For many B2B services, data subjects include both (a) your direct customers’ users and (b) your own prospects and website visitors, depending on what’s in scope and what personal information you collect ¹.

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

Use this as an implementation runbook that yields both control performance and audit-ready evidence.

Step 1: Establish ownership and a controlled notice process

1. Assign a Privacy Notice Owner (often Legal/Privacy, supported by Security/GRC).
2. Define an approval workflow: draft → privacy review → security review (as needed) → final approver.
3. Put notices under version control (document management system, ticketing system, or a controlled policy portal).
4. Define trigger events that require review: new data collection, new third party sharing, new feature, new region, material incident affecting disclosures ¹.

Deliverable: “Privacy Notice Management Procedure” (a short SOP) mapping to TSC-P1.1 ¹.

Step 2: Inventory data collection touchpoints (where notice must appear)

Build a touchpoint inventory that lists each place personal information is collected or meaningfully used. Minimum fields:

• Product/system
• Data subject type (customer admin, end user, prospect, employee, etc.)
• Collection point (signup form, in-app screen, API, support portal, cookies banner if in scope)
• Link or UX pattern for notice (footer link, inline disclosure, just-in-time notice)
• Owner (product/marketing/HR)
• Evidence method (screenshot, release tag, archived HTML)

Practical tip: Start from your data map/ROPA, then reconcile to actual UX entry points. Most gaps appear in “secondary” flows like support intake, event registrations, and referral programs.

Step 3: Map notices to actual privacy practices

For each touchpoint, confirm the published notice aligns to:

• Categories of personal information collected
• Primary purposes of processing
• Sharing with third parties (categories of recipients)
• Retention approach at a high level
• Data subject choices/rights and how to exercise them
• Contact method for privacy inquiries ¹

You are not required by SOC 2 text alone to include every jurisdiction-specific disclosure, but you are required to provide notice of your privacy practices and demonstrate the control operates as designed ¹. If you operate in regulated regions, align your notice content and presentation to your applicable legal obligations separately; document that linkage in your compliance matrix.

Step 4: Implement “delivery” controls (make sure people can see it)

Common, auditable delivery patterns:

• Website footer link to Privacy Notice plus contextual links near lead forms
• In-product link during account creation and inside settings/help
• Just-in-time notice for sensitive collections (location, biometrics, recording), if applicable to your services and scope
• Support portal notice at ticket submission
• Contractual notice language where you collect data indirectly (e.g., via customers), paired with publicly accessible notice ¹

Auditor mindset: If a data subject could reasonably miss the notice, expect questions. Your control should be designed for real-world visibility, not theoretical availability.

Step 5: Set monitoring, review, and testing

SOC 2 expects you to show operation over time, not a one-time publication ¹.

• Schedule periodic review of notices and touchpoints.
• Add a release/checklist item for engineering and marketing: “Does this change affect personal information collection, use, or sharing? If yes, update notice.”
• Test effectiveness: sample a set of touchpoints and verify the correct notice is present and current; log results and remediation ¹.

Where Daydream fits naturally: Daydream can track the control as an owned requirement, route reviews via workflows, and retain a clean evidence trail (approvals, screenshots, release references) mapped to TSC-P1.1 so you are not reconstructing history during the exam.

Required evidence and artifacts to retain

SOC 2 exams are evidence-driven. Retain artifacts that prove both design and ongoing operation.

Core artifacts (expected in most SOC 2 Privacy examinations)

• Published privacy notice(s) as of the audit period (PDF export or archived pages)
• Version history / changelog for each notice, with dates and approver(s)
• Privacy Notice Management Procedure (SOP) mapped to TSC-P1.1 ¹
• Touchpoint inventory and mapping to notice placement
• Review records: meeting notes, tickets, approvals, sign-offs
• Monitoring/testing records: sampling results, findings, remediation tickets ¹
• Audit trail evidence: system logs from your doc tool or ticketing system showing who changed what and when ¹

Evidence quality checklist (what makes evidence “exam-ready”)

• Dated, attributable, and tamper-evident where possible
• Shows what was true during the period, not just today
• Ties to scope: product names and environments match the SOC 2 boundary

Common exam/audit questions and hangups

Auditors tend to probe predictable weak spots for TSC-P1.1 ¹:

1. “Show me where users see the privacy notice at collection.”
   Hangup: you provide a website footer link, but the key collection occurs inside the app or via support intake.

2. “How do you know the notice matches your current practices?”
   Hangup: no link between product change management and privacy notice updates.

3. “Prove what notice was in effect during the period.”
   Hangup: notice was edited directly in CMS with no approvals or archived versions.

4. “Who approves privacy notice changes?”
   Hangup: approvals are informal (Slack) and not retained.

5. “How do you test the control?”
   Hangup: you rely on “we would notice” instead of a recorded sampling/testing activity ¹.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails in a SOC 2 exam	Fix that works
Privacy notice exists, but you can’t tie it to all collection points	The criterion is about providing notice to data subjects, not publishing a document 1	Build and maintain a touchpoint-to-notice mapping; include non-obvious channels (support, events)
No periodic review	Control operation can’t be demonstrated over time 1	Add a scheduled review cycle and retain review logs and approvals
CMS edits with no audit trail	You can’t prove what was live during the audit period	Use versioning, ticket approvals, and page archives for every change
Notice content is generic and disconnected from actual data practices	Auditors compare notice statements to system reality	Tie notice content to your data map and third-party sharing register
Teams treat “privacy notice” as Legal-only	Product and marketing changes bypass compliance	Add change triggers to product release checklists and marketing campaign intake

Enforcement context and risk implications

SOC 2 is an audit framework, not a regulatory enforcement regime, so there are no enforcement cases to cite from the provided sources ¹. The real risk is commercial and contractual: failure to meet TSC-P1.1 can produce SOC 2 findings, delay report issuance, or drive exceptions that customers interpret as privacy governance weakness. Operationally, weak notice governance also increases the chance that your public disclosures drift from actual practices, which can create broader regulatory exposure outside the SOC 2 context.

Practical 30/60/90-day execution plan

This plan is designed to get you from “we have a privacy policy” to “we can pass an exam with evidence.”

Day 0–30: Get to a controlled baseline

• Define audit scope for Privacy and identify in-scope products and data subjects ¹.
• Assign a Privacy Notice Owner and approver(s).
• Create the Privacy Notice Management Procedure (SOP) and store it in your controlled repository.
• Export/archive current privacy notices (create a baseline record).
• Build the first version of your touchpoint inventory and identify gaps.

Exit criteria: You can show a current notice, an owner, and a documented process aligned to TSC-P1.1 ¹.

Day 31–60: Close delivery and alignment gaps

• Remediate missing notice placements (in-app, support, forms).
• Reconcile notice content to actual data practices using your data map and third-party sharing list.
• Implement change triggers in engineering release and marketing campaign workflows.
• Stand up version control and a documented approval trail for any notice changes.

Exit criteria: Every in-scope collection point has a mapped notice placement, and the notice content has been reviewed against current practices ¹.

Day 61–90: Prove operation and test effectiveness

• Run a documented test: sample touchpoints and verify notice presence and correctness; open remediation tickets for exceptions ¹.
• Conduct a formal notice review meeting and retain minutes/approvals.
• Assemble an “audit packet” for TSC-P1.1 (procedure, versions, screenshots, test results).
• If you use Daydream, configure the control record, evidence requests, and review cadence so evidence is captured continuously.

Exit criteria: You have dated evidence that the control operated, not just documentation that it exists ¹.

Frequently Asked Questions

Does a single privacy policy on our website satisfy TSC-P1.1?

Sometimes, but only if it reasonably provides notice to the data subjects in scope at or before collection. If most collection happens in-product or via support, you typically need in-product and workflow-specific notice placements to show the control operates ¹.

What will an auditor ask for to prove notice was provided during the period?

Expect requests for dated versions of the notice, approval records, and evidence of where the notice was displayed (screenshots, archived pages, or release artifacts). They may also ask for testing records showing periodic verification ¹.

We update the privacy notice frequently. How do we avoid evidence gaps?

Put the notice under version control with a formal approval workflow and keep an archive of each published version. Your goal is to reconstruct exactly what was live at any point in the audit window ¹.

How detailed does the notice need to be for SOC 2?

TSC-P1.1 requires notice about privacy practices, so the notice must reflect what you collect, how you use it, and how you share it in a way that matches reality. The exact level of detail depends on your services and scope; document your rationale and keep it consistent with your internal data map ¹.

Does this apply to employee or applicant data?

It applies to any in-scope data subjects for the SOC 2 Privacy criteria boundary. If your SOC 2 scope includes HR systems or employee data processing, include appropriate notices and evidence for those collection points ¹.

What’s the minimum “testing” that satisfies TSC-P1.1?

Record a periodic check that verifies the notice is present and correct across a sample of collection points, and track remediation. The key is written results and follow-through, not the sophistication of the method ¹.

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