TSC-P3.1 Guidance

TSC-P3.1 guidance requirement means you must collect personal information only for the specific purposes you disclosed in your privacy notice, then prove it in a SOC 2 audit with traceable mappings from notice → data collected → systems → controls. Operationalize it by inventorying collection points, tying each data element to a stated purpose, and blocking “purpose creep” through change control and monitoring. ¹

Key takeaways:

• Your privacy notice becomes a control boundary: every collection event must map to a disclosed purpose. ¹
• Auditors will test both design (policy, mappings) and operating effectiveness (logs, tickets, approvals). ¹
• The fastest path is a “purpose-to-data-to-system” matrix with enforcement via intake reviews, tagging, and periodic testing. ¹

TSC-P3.1 sits in the SOC 2 Privacy criteria and is easy to misunderstand: it is not a generic “minimize data” principle. It is a scoped requirement that ties your actual personal information collection to what you told people in your privacy notice. If you collect personal information for reasons that are not in the notice, you have a control gap even if your security controls are strong. ¹

For a CCO, Compliance Officer, or GRC lead, the practical challenge is that collection happens everywhere: web forms, mobile SDKs, support tools, sales pipelines, product telemetry, HR systems, and third-party integrations. The notice is often maintained by Legal or Marketing, while collection is owned by Engineering, Product, RevOps, and Customer Support. SOC 2 auditors will expect you to bridge that gap with concrete artifacts: an inventory of collection points, documented purposes, and evidence that new collection is reviewed against the notice before it goes live. ¹

This page gives requirement-level implementation guidance you can execute quickly, including what to build, who owns it, what evidence to retain, and how to survive audit testing for the tsc-p3.1 guidance requirement.

Regulatory text

Requirement (TSC-P3.1): “The entity collects personal information only for the purposes identified in the notice.” ¹

What the operator must do:

1. Maintain a current privacy notice that identifies the purposes for collecting personal information.
2. Ensure each collection of personal information (by data element and collection point) is tied to one or more stated purposes in that notice.
3. Prevent or detect collection for undisclosed purposes through governance, technical controls where feasible, and monitoring with retained evidence. ¹

Plain-English interpretation (what auditors mean by this)

• If the notice says you collect an email address for “account creation and authentication,” collecting that email for “ad targeting” becomes a problem unless the notice also discloses that purpose (and you follow your notice change process).
• “Only for the purposes identified” applies to collection, not just later use. If you capture extra fields “just in case,” you are collecting outside disclosed purposes unless the notice covers it. ¹

Who it applies to (entity and operational context)

Applies to: Organizations undergoing a SOC 2 audit that includes the Privacy criteria. ¹

Operationally, it touches:

• Product & Engineering: registration flows, in-product profile fields, telemetry/analytics SDKs, error reporting tools.
• Marketing & Growth: web tracking, lead forms, ad pixels, marketing automation.
• Sales & RevOps: CRM collection fields, enrichment tools, call recording.
• Support & Success: ticketing systems, chat transcripts, screen recordings.
• HR/People Ops (if in scope): candidate or employee data collection through ATS/HRIS.
• Third parties: any service that collects personal information on your behalf (e.g., form providers, analytics, support chat). You still need purpose alignment because the collection is attributable to your service commitments in scope. ¹

Scope note for SOC 2: Your auditor will test against the system description and audit scope. If certain products, regions, or business units are out of scope, document that boundary clearly so testing focuses on the intended environment. ¹

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

Step 1: Define the “purpose catalog” from the notice

Create a controlled list of collection purposes that exactly matches your notice language (or is a clean, traceable decomposition of it). Examples:

• Account provisioning/authentication
• Service delivery and customer support
• Billing and tax compliance
• Security and fraud prevention
• Product analytics and improvement
• Marketing communications (opt-in/opt-out as applicable)

Control objective: every collection must map to one of these purposes; anything else triggers notice update and approvals. ¹

Step 2: Build a “Purpose-to-Data-to-System” matrix (your core SOC 2 artifact)

For each in-scope product/service:

• List collection points (web forms, API endpoints, mobile screens, cookies/SDK events, support intake forms).
• For each point, list data elements collected (name, email, IP address, device ID, chat content, etc.).
• For each element, map:
  • Purpose(s) (from Step 1)
  • System of record (CRM, data warehouse, support tool)
  • Owner (team and control owner)
  • Retention/collection rule reference (policy or configuration)

Keep it auditable: version controlled, dated, and owned. Auditors often accept a spreadsheet if it is complete and controlled; many teams move this into a GRC system once stable.

Step 3: Enforce purpose alignment at intake and change control

Add a required checkpoint for any new or changed personal information collection:

• New form field
• New event/property in analytics
• New SDK
• New integration that collects on your behalf
• New use case that requires a new category of personal information

Practical gate: route changes through a lightweight “Privacy Collection Review” that checks:

1. What personal information will be collected?
2. From whom (customers, end users, prospects)?
3. For what purpose (must match the notice catalog)?
4. Where does it flow (systems/third parties)?
5. If the purpose is not in the notice, who owns updating the notice and communicating the change?

Evidence this with tickets (Jira/ServiceNow), pull request templates, or release checklists tied to approval. ¹

Step 4: Configure systems to avoid “extra collection”

Where feasible, implement guardrails:

• Remove optional fields that are not tied to a disclosed purpose.
• Disable default “collect everything” settings in analytics or session replay.
• Limit support intake forms to necessary fields; avoid free-text prompts that invite sensitive data unless you disclose and control it.
• For third-party scripts, use tag management approvals and disable unapproved tags by default.

You do not need perfect technical prevention for every case, but you do need a credible control story and evidence of operation. ¹

Step 5: Monitoring, periodic review, and testing

Set a recurring control activity to confirm ongoing alignment:

• Review website forms, privacy notice, and tag manager changes.
• Review analytics event schemas for new personal data fields.
• Review a sample of product releases or tickets for collection changes and confirm approvals occurred.
• Reconcile the matrix against actual configurations (fields in CRM, properties in event tracking, support form fields).

Tie results to remediation tickets and track closure. ¹

Step 6: Retain an audit trail

Auditors will ask for proof across the audit period (Type 2). Keep:

• The notice versions
• Approval evidence for notice changes
• Evidence that collection changes were reviewed and approved
• Evidence that monitoring occurred and exceptions were handled ¹

Required evidence and artifacts to retain (audit-ready list)

Use this as your document request checklist:

• Privacy notice (current and historical versions during the audit period) and change log/approvals. ¹
• Purpose catalog mapped to notice language, with owner and effective date. ¹
• Purpose-to-Data-to-System matrix covering in-scope services and collection points. ¹
• Policies/procedures describing how new collection is reviewed (privacy-by-design, SDLC, change management). ¹
• Operational evidence (samples):
  • Approved tickets for new fields/events/tags/SDKs
  • Pull request templates showing privacy prompts and approvals
  • Tag manager change approvals and publishing logs
  • Analytics governance logs (schema registry approvals)
• Monitoring & review records and testing results (internal audit/GRC testing, findings, remediation). ¹
• Third-party oversight artifacts where third parties collect on your behalf (DPAs, implementation configs, tag inventories), limited to what is in scope and relevant to collection purposes. ¹

Common exam/audit questions and hangups

Auditors frequently probe these areas for the tsc-p3.1 guidance requirement:

1. “Show me where the notice states the purposes for collection.”
   Hangup: notice language is broad or ambiguous. Fix: create a purpose catalog that traces to the notice and is approved.

2. “Prove your product only collects what’s tied to those purposes.”
   Hangup: no inventory of collection points. Fix: matrix + evidence samples.

3. “How do you prevent new collection from bypassing Legal/Privacy review?”
   Hangup: review is informal (“we Slack Legal”). Fix: ticketed approvals tied to releases.

4. “What about marketing tags and third-party scripts?”
   Hangup: tag sprawl and shadow marketing tools. Fix: tag manager governance plus periodic tag audits.

5. “Show operating effectiveness during the period.”
   Hangup: good documentation, weak evidence. Fix: retain dated logs, screenshots, exports, and completed review checklists. ¹

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails TSC-P3.1	How to avoid
Privacy notice maintained separately from engineering reality	Collection changes drift from disclosed purposes	Require notice traceability in change control; keep a purpose catalog owned jointly by Legal + GRC
Treating “purpose” as implied by having a product	Auditors want explicit notice-based purposes	Map each purpose to specific notice language and keep it versioned 1
Only documenting policies, no proof	SOC 2 testing requires evidence of operation	Store tickets, approvals, exports, and review results per period 1
Ignoring telemetry/analytics	SDKs can collect identifiers by default	Govern event schemas, disable defaults, and review tag/SDK changes routinely
No periodic reassessment	New features add fields silently	Add scheduled reviews and sampling-based tests; track remediation to closure 1

Enforcement context and risk implications

SOC 2 is an audit framework, not a regulatory enforcement regime, so you should not expect “enforcement cases” tied to TSC-P3.1 itself. The risk is commercial and contractual: audit exceptions can lead to a qualified SOC 2 report, customer trust issues, delayed sales cycles, and increased scrutiny in security/privacy questionnaires. The operational risk is purpose creep: teams add collection “for analytics” or “for future features” that the notice does not cover, creating a control gap against TSC-P3.1. ¹

Practical 30/60/90-day execution plan

First 30 days: get to a defensible baseline

• Assign owners: Privacy Notice Owner (Legal/Privacy), Data Collection Control Owner (GRC), Technical Owner (Eng/Analytics).
• Freeze the purpose catalog: extract purposes from the notice and get approval. ¹
• Inventory top collection points: registration/login, checkout/billing, contact-us/lead forms, support intake, primary analytics SDKs.
• Draft the first version of the purpose-to-data-to-system matrix for those areas.
• Add a “Privacy Collection Review” checklist to the change process (ticket template + required approvers).

Days 31–60: extend coverage and start testing

• Expand the matrix to remaining in-scope products and workflows (including marketing tags and third-party scripts).
• Implement tag governance: documented approval workflow for adding/modifying tags; export tag inventory for evidence.
• Stand up monitoring: a recurring review task with a clear scope, sample method, and evidence retention location.
• Run your first internal test: sample recent releases/tickets and confirm purpose mapping and approvals occurred. Document results and remediation. ¹

Days 61–90: harden operating effectiveness and audit packaging

• Close gaps found in testing: remove unused fields, adjust SDK settings, update notice if you legitimately need a new purpose.
• Package evidence by period: create an audit folder structure aligned to each control activity (notice versions, approvals, reviews, exceptions).
• Perform a mock auditor walkthrough: pick one collection point (e.g., signup) and trace it end-to-end from notice → form → backend → data store → monitoring record.
• If you need automation, configure Daydream to track control tasks, store evidence, and keep a clean audit trail across systems without chasing screenshots at the end of the period. ¹

Frequently Asked Questions

What counts as “personal information” for TSC-P3.1 purposes?

Treat any information that identifies or can reasonably be linked to an individual as in scope for your mapping and collection review, consistent with your notice definitions. Align your internal definitions to the terms used in the notice so your traceability is clean. ¹

Do we need to stop collecting optional fields that are “nice to have”?

If an optional field is personal information, you need a disclosed purpose for collecting it and a documented rationale tied to that purpose. If you cannot map it, remove it or update the notice through your controlled process before collecting it. ¹

How do we handle product analytics tools that collect identifiers by default?

Document what the tool collects, map it to a disclosed purpose (often “service improvement” or “analytics” if your notice says so), and change configuration to reduce collection where feasible. Keep evidence of settings and approvals so you can show intentional control, not accidental collection. ¹

What if we want a new purpose that is not in the notice?

Treat it as a controlled change: draft updated notice language, obtain required internal approvals, then roll out the collection change after the notice update is effective under your process. Keep the approvals and effective dates so auditors can confirm timing. ¹

How much evidence is “enough” for a SOC 2 Type 2 period?

Plan to show repeated operation: completed review checklists, dated exports/logs, and a consistent approval trail for changes across the period. Auditors commonly test samples, so your goal is consistent records rather than one perfect screenshot. ¹

Can third parties collect personal information on our behalf under TSC-P3.1?

Yes, but you still need purpose alignment to your notice because the collection supports your service and disclosures. Make sure your inventory includes third-party collection points (forms, chat widgets, analytics) and that your change control covers adding or reconfiguring them. ¹

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