SOC 2 P3.2: Privacy - Explicit Consent Before Collection
Some personal information cannot be collected on the strength of a privacy notice alone. Health details, biometric data, precise location, information about children, or anything your commitments or the applicable law treat as sensitive usually needs the person's explicit, affirmative consent before you collect it.
Work through the SOC 2 assessment, record supporting evidence and review the gaps in your answers.
Requirement summary
For personal information that requires explicit consent, the entity tells the data subject that consent is needed and what happens if it is refused, and obtains that consent before collecting the information. The points of focus apply this to sensitive personal information and to keeping documentation of the consent.
Check the source wording and scope in AICPA SOC resources and Trust Services Criteria. The guidance below explains how to approach a review.
In Plain Language
P3.2 asks two things of that moment. The person must understand that consent is required and what happens if they say no, for example that a feature will not work or that an application cannot proceed. And the consent must exist before the data reaches your systems, not after a form has already been submitted.
Auditors check that you know which fields and flows require explicit consent, that the consent step appears before collection, that declining has the consequence you described and nothing worse, and that you can produce a record of each consent: who agreed, to what wording, and when.
How to Implement
Start with an inventory. List the forms, integrations and data imports that collect personal information, and mark the fields that need explicit consent under your privacy commitments and the laws that apply to your customers. Sensitive categories are the usual starting point, but contracts can add others.
Put the consent step in front of the collection. For each flagged flow, the person should see what is being collected, why it is needed and what happens if they decline, and should take a clear affirmative action such as ticking an unticked box or confirming a separate prompt. A pre-ticked box or a sentence buried in general terms is not explicit consent.
Make declining workable. If the information is optional, the service should continue without it. If it is genuinely required, say so plainly and explain the consequence, rather than blocking the person without an explanation.
Record the consent. Store who consented, the exact wording and version they saw, the time and the channel. Link the record to the data it covers so you can show it for any individual, and keep it for as long as you keep the data it authorises.
Enforce it technically. Check on the server that a consent record exists before storing flagged fields, and stop imports of those fields from sources that cannot show consent. Review the consent wording whenever the collection changes.
Using information you already hold for a new purpose is a separate question, covered by the notice and choice criteria (P1.1 and P2.1) and by use limitation (P4.1). Keep that review, but do not present it as evidence for P3.2.
Evidence to review
- Inventory of collection points and fields that require explicit consent, with the basis for each
- Screenshots or recordings of consent steps shown before sensitive information is collected
- Consent records showing the individual, the wording version, the time and the channel
- Server-side checks or configuration that reject flagged fields without a recorded consent
- Reviews of consent wording carried out when collection flows change
Common Mistakes
- Sensitive fields are collected through a general form covered only by the privacy notice
- Consent is implied by a pre-ticked box or by continuing to use the service
- People are not told what happens if they decline, or declining blocks the service without explanation
- Consent is captured after submission, or not recorded at all
- Imports or integrations bring in sensitive information without any record of consent
Related Controls Across Frameworks
| Framework | Control ID | Relationship |
|---|---|---|
| ISO 27001 | ISO 27001 A.5.34: Privacy and protection of personal identifiable information (PII) | Partial overlap |
| nist-csf | nist-csf GV.PO-01 | Partial overlap |
Frequently Asked Questions
Which information needs explicit consent?
Is this the same as consent for a new use of data we already hold?
Can accepting the privacy notice count as explicit consent?
Related Articles
Compliance Costs: Budgeting for DIY, Consulting and Software
Compare staff time, audit fees, consulting, software and remediation without treating different services as interchangeable.
Read article →SOC 2 for Startups: When You Need It and How to Get Started
A practical guide for startup founders and CTOs on SOC 2 compliance - when it's actually required, Type 1 vs Type 2, realistic costs, and a readiness checklist.
Read article →GDPR Compliance Checklist for SaaS Companies
A practical GDPR checklist for SaaS companies - covering key requirements, common gaps, and actionable steps to achieve and maintain compliance.
Read article →Track SOC 2 compliance in one place
Work through the SOC 2 assessment, record supporting evidence and review the gaps in your answers.
Start Free AssessmentStart without an account · Sign up only to save