P3.2 Explicit consent for collection: SOC 2 requirements

What P3.2 requires before a privacy team collects consent-based data

If your SOC 2 includes the privacy category and your product collects information that needs explicit consent, P3.2 asks you to do two things before any of that information is gathered: explain why consent is needed and what happens if a person says no, and then obtain that consent. The consent has to come first, not after the data is already in your systems. The criterion sits in the privacy category, so it only applies when privacy is in scope, and the 2017 Trust Services Criteria define it through the same points of focus that the AICPA revised in 2022. The risk it addresses is straightforward: sensitive data gets collected on the basis of a choice the person never really made, either because the reason for asking was hidden, the refusal consequences were unclear, or the consent was never recorded. An assessor will look for the consent step at the point of collection, not in a policy document that says consent is generally sought.

What makes P3.2 hard in practice is that consent is rarely handled in one place. Sign-up forms, mobile app prompts, onboarding wizards, support chat, data imports from partners and API integrations may each ask for information in their own way, and each may use different wording for the reason and the consequences. Your engineering team owns the flows, while legal or privacy staff own the wording, so gaps appear wherever those two groups do not meet. Start by listing every place your system collects information that needs explicit consent, then confirm which screen or interface shows the explanation, what it says about refusal, and what record is written when the person agrees. Ask your auditor early which evidence they expect to see for each flow.

P3.2 sits alongside P2.1, which covers the choices people have across collection, use, retention, disclosure and disposal. This page does not repeat that broader scope. The question P3.2 adds is narrower: at the moment collection begins, has the organization told the person why explicit consent is needed and what refusal means, and has it stored proof of the agreement? Before you prepare evidence, review the AICPA 2017 Trust Services Criteria with revised points of focus to confirm the exact points of focus your auditor will use, and check with your assessor how they plan to sample collection events across the audit period.

Which systems, forms and teams fall under P3.2 scope

P3.2 scope is set by the organization's own privacy objectives, not by a fixed list. The cards below cover the decisions that determine which data needs consent, which collection points must show it, who writes the wording, and which third-party code collects data on the organization's behalf. Each one is a point an assessor will ask you to explain and evidence.

Data that needs explicit consent

Start by listing the personal information your service collects and marking which items your privacy objectives say require explicit consent before collection. The organization defines what counts as explicit consent for its service, so the list should match the commitments in your privacy notice. Check for sensitive fields, marketing preferences, optional profile data and any data used for a purpose beyond delivering the service. Record the reason each item is or is not in scope so the boundary can be tested.

Sign-up and onboarding flows

Account creation and onboarding are usually the first place explicit consent is requested, so they carry most of the P3.2 work. Each screen that asks for consent-dependent information should state why the information is needed and what happens if the person declines. Confirm that the system blocks collection until consent is recorded, rather than collecting first and asking later. Walk through the flow as a new user on every client you support.

APIs, mobile apps and support intake

Consent prompts are easy to miss outside the main web interface. Mobile SDK screens, public API endpoints that accept personal data, and support tickets, chat transcripts and email forms can all collect information without showing the same consent text. Inventory each channel, confirm it presents the required explanation and consequence, and check that consent status is passed to the back end. Support agents who ask for extra details by phone also need a script that matches the written notice.

Teams that own consent wording

Consent language usually sits across product, legal, privacy and customer support, and no single team tends to review all of it. Name one owner for the consent text and an approver who checks it against the privacy notice and the organization's objectives. Keep a version history so you can show which wording applied on a given date. Changes to a form that alter what is collected should trigger a fresh review before release.

Third-party tools and SDKs

Analytics scripts, session recorders, payment widgets, chat plugins and mobile SDKs often collect personal information on your behalf. Their collection is still within your P3.2 scope if they gather data that needs explicit consent. List each tool, what it collects, and whether consent is required before it loads. Confirm that the tool respects the consent choice recorded in your system, and keep the vendor's commitments with your evidence file.

Consent records and their retention

Explicit consent is only useful as evidence if it is documented. Each record should show who consented, the version of the wording shown, the time and the channel. P3.2 also covers documenting explicit consent to retain information, so keep these records for as long as the data they support is held. Confirm with your auditor how they expect records from self-hosted systems to be exported and protected.

How an SOC 2 assessor tests consent before collection

An assessor tests P3.2 by asking whether the organization's controls capture explicit consent before personal information is collected, and whether the consent was given with the explanation the criterion calls for. The assessor starts from the organization's own description of the points where explicit consent is needed, then selects collection points such as sign-up forms, onboarding flows, API enrollment and support intake. For each point, the assessor looks at the consent wording shown to data subjects and compares it with the privacy commitments in the organization's notice and system description. Where the wording says why consent is needed and what happens if someone declines, the assessor checks that the statement matches what the product actually does when consent is withheld. A mismatch, such as a form that says a feature is optional while the record is still created, is the kind of finding that drives an exception.

The assessor then tests timing and records. For selected individuals, the assessor compares the timestamp of the consent record with the timestamp of the first collection event, and confirms that the collection did not happen first. Evidence usually includes consent logs, configuration screenshots of the consent step, and database or event exports that show the order of events. In a Type 1 examination, the assessor looks at design only: whether the consent step exists, is documented, and is positioned before collection, as of a single date. In a Type 2 examination, the assessor samples throughout the observation period and checks that the control operated consistently, so a consent step that was changed or bypassed mid-period, for example during a release, becomes a testing matter. The organization should confirm with its auditor how many samples and which populations will be drawn, and whether consent logs for the period can be produced in full.

The assessor reports on what the organization's controls did, not on whether the consent is legally sufficient under any privacy law. Whether consent meets a standard such as GDPR's conditions is a question for counsel and the relevant regulator, not for the SOC 2 opinion. Before fieldwork, the organization should ask its legal advisers to confirm the consent wording, and separately confirm with its auditor that the controls and evidence described above will be tested as designed. Keeping the consent text under version control and tying each version to its effective date makes both the Type 1 and Type 2 tests far easier to run.

What an assessor requests and where findings usually come from

This table compares what the service auditor typically tests for P3.2, the evidence it asks for, and the findings that appear most often in practice. Read each row as a question the assessor will ask about your consent process, then check whether your records answer it before fieldwork starts.

Test area	What the assessor requests	Common findings
Consent wording review	Current consent notices, screens and scripts for each collection point, plus the version history and approval record	Consent text that explains what is collected but never says what happens if the person refuses
Sampling of collection events	A sample of individuals whose information required explicit consent, with the consent record for each	Samples where the collection flow lacks a consent step, or where some users skipped it through a default or an alternate path
Timing of consent relative to collection	System logs or timestamps showing consent was captured before the sensitive data was stored or processed	Consent captured after data ingestion, or consent requested only after an import or sync had already run
Consequence-of-refusal disclosures	Evidence that each notice states why consent is needed and the effect of refusing, such as loss of a feature or service	Notices that name the purpose but omit the consequence, or describe consequences that the product does not actually apply
Retained consent records	Stored records showing who consented, when, to what wording and through which channel, with retention rules for those records	Consent withdrawn or refused in the application but still treated as valid in downstream systems, or records that cannot be matched to a person

How to implement P3.2 in a self-hosted product in sequence

This sequence turns the P3.2 requirement into a set of consent wording, a working consent gate, and consent records that an auditor can trace from the wording a data subject saw to the moment information was collected. Each step ends with a deliverable the organization can show the examiner.

Inventory explicit-consent data categories
Start with the data inventory the organization already maintains for its SOC 2 program, and mark each personal information category that needs explicit consent before collection. Include the systems that receive it, such as the self-hosted application, its databases, logs and any integrated services. Ask the product owner and privacy lead to confirm each category and the reason it falls under explicit consent, since that decision depends on the organization's own commitments and applicable law. The output is a signed-off register of consent-dependent categories, mapped to the collection points in the product. The step is done when every collection point in the product appears in the register with a yes or no answer.
Draft reason and refusal-consequence wording
For each category in the register, write the text a data subject sees before giving consent. The text must explain why the information is needed and what happens if the person refuses, such as a feature that will not work or an account that cannot be created. Legal or privacy reviewers should approve the wording, and the product team should confirm that the described consequence matches the code. The output is a versioned consent text library with an owner, an approval record and a link from each category to its approved wording. The step is done when every explicit-consent category has approved text that the reviewer has checked against actual behavior.
Build the consent gate before collection
Implement the consent screen or API check so that the product cannot collect a consent-dependent category until the data subject has actively agreed to the approved text. This means the collection code path reads the consent state first and refuses to proceed without it, rather than relying on a banner shown afterwards. Engineers should configure the gate in the self-hosted deployment and version it with the rest of the infrastructure code. The output is a tested gate in the build, with a change record showing when it was introduced. The step is done when a test shows collection blocked in the absence of consent.
Record consent events with version and timestamp
Store a consent record each time a data subject grants or withdraws consent. Each record should hold the subject identifier, the category, the wording version shown, the action taken and a timestamp from a trusted time source. Keep the records in a store protected under the organization's retention and access controls, and make sure logging of consent events is covered by the monitoring program. The output is a sample set of consent records that an auditor can select and trace to the wording version and the collection event. The step is done when a sampled record can be matched to the exact text that was displayed.
Test refusal paths end to end
Test what happens when a data subject declines consent. Confirm that no consent-dependent information is collected, that the stated consequence occurs, and that the refusal is recorded. Also test the path where a subject withdraws consent after granting it, and confirm collection stops for future events. Keep the test scripts, the test data used and the results in the evidence folder. The output is a dated test report with pass results and any defects logged and fixed. The step is done when the refusal and withdrawal tests pass on the current release.
Set a review cadence for wording changes
Define who reviews consent wording, how often the review occurs, and what triggers an earlier review, such as a new collection purpose, a new integration or a change in applicable law. Every change to the wording should create a new version, pass through the same approval as the original, and trigger a check that the gate and records still work. The output is a documented review procedure and a change log of wording versions with approval evidence. The step is done when the change log shows each wording version, its approver and the release in which it went live. Confirm with the auditor how often they expect to see these reviews in the examination period.

Which evidence satisfies P3.2 and how to keep it current

P3.2 is tested by showing that consent was explained and obtained before collection, and that the explanation is the one the organization actually uses. The cards below cover the artifacts an assessor is likely to ask for, and the routine checks that keep them current between audits rather than assembled at fieldwork.

Versioned consent wording

Keep each version of the consent text that explains why explicit consent is needed and what happens if a person declines, with an effective date and an owner. The wording should match what the product shows, word for word, at each point the information is requested. Check that every live collection point references a current version and that retired versions remain on file for the period the organization needs to evidence.

Consent event logs

Record each consent decision with a timestamp, the identifier of the data subject or account, the decision made, and the wording version the person saw. Logs of this kind are the strongest evidence that consent was obtained before collection began, so confirm that the collection event itself is logged after the consent event and that the two can be joined during sampling.

Configuration exports of the consent gate

Export the settings that control whether collection can start without a recorded consent, such as feature flags, form rules or API validation. Dated exports show the gate was in place throughout the period under review. Ask the engineering team to confirm that the export reflects production, not a staging copy, and to keep exports from each release that changed the gate.

Test records for refusal paths

Keep test cases and results showing that a person who declines consent does not have their information collected, and that the consequence described in the wording actually applies. Run these tests on each release that touches a collection point. Retain the test plan, the run date, the build tested and the defect tickets raised when a refusal path failed.

Change records for wording updates

Record who proposed each wording change, the reason, the legal or privacy review, the approval and the date the new text went live. Link the record to the consent event log so an assessor can see which people consented to which version. Review wording at least when collection purposes or consequences change, and log reviews that conclude no change is needed.

Keeping evidence current between audits

Assign an owner for each artifact and set a recurring check, such as a monthly export and a quarterly review of wording and test results. Store evidence in a system with access logs and retention rules, so records are complete when the observation period is sampled. Ask any implementation partner to build these exports into the platform so routine operation produces the evidence without a manual collection effort.

What meeting P3.2 costs in money and effort

This table lists the cost components of meeting P3.2 for explicit consent, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to see where spending goes and which questions to put to a quote. No figures are given because none are supplied for this criterion.

Cost component	Who is paid or who does the work	One-time or recurring	What drives it up or down
Engineering time to build the consent gate and logging	Internal engineers or an implementation partner building the flow and consent record store	One-time build, then recurring change work	Number of collection points and whether consent is captured in one shared service or repeated in each product screen
Legal or privacy review of consent wording	Internal counsel, privacy staff or outside privacy counsel	One-time for first wording, recurring at each change	Number of languages, jurisdictions and data types that need explicit wording
External review of wording or flows	Outside privacy specialist or UX reviewer, if the organization buys one	Usually one-time, repeated after major redesigns	Complexity of the consent journey and whether the organization lacks in-house privacy expertise
Evidence upkeep	Internal compliance or security staff, sometimes supported by a GRC tool	Recurring across the observation period	Frequency of product releases that touch consent screens and how consent records are exported
Auditor sampling and testing	Independent CPA firm, which tests operating effectiveness in a Type 2 examination	Recurring each examination period	Number of consent-based collection flows in scope and the number of samples the auditor selects
Refusal handling and consequence notices	Engineering and product teams, with legal sign-off on wording	One-time design, recurring review	How many consequences of refusal exist and how often product behavior for refusal changes
Change management for consent flows	Engineering and release owners following the organization's change process	Recurring with each release	Product release frequency and how many releases alter consent prompts or stored choices

Who owns consent, who prepares the evidence and who assesses it

Your organization owns the consent decisions. Before any engineering work starts, the people accountable for privacy and the business owners of each product need to decide which personal information requires explicit consent, which information can be collected under other grounds, and what the consent request will say. P3.2 expects the organization to explain why consent is needed and what happens to a data subject who refuses, so those statements must reflect real product behavior and the organization's own legal position. Counsel should review the wording and the legal basis for each category.

Data category decisions: Maintain a list of the personal information types that need explicit consent, with the reason each one does.
Consent wording: Approve the explanation of purpose and the stated consequences of refusal, and keep versions of every text presented to users.
Refusal outcomes: Decide what service a user keeps, loses or can limit if they decline, and make sure the product matches that decision.
Policy and ownership: Assign an accountable owner for the consent process and for updating it when products or purposes change.
Legal review: Retain counsel to confirm the consent language, since an implementation partner should not write these terms as a substitute for legal advice.

Confirm that the list of consent-dependent data categories and the approved wording exist in writing before the auditor's fieldwork begins.

Where P3.2 programs usually fall short

Most P3.2 weaknesses are not missing policies. They are gaps between what the organization tells people, what the systems actually do, and what records exist afterward. The cards below cover the places where consent breaks down before the auditor's sampling even begins.

Consent collected after ingestion

Some products capture a form, an upload or a sign-up payload first and show the consent screen afterward, or let consent be assumed from later clicks. For P3.2, the explanation and the consent must come before the information is collected. Check the event sequence in your application logs and confirm that no personal field reaches storage until the consent step has been recorded for that user.

Refusal consequences left unstated

Consent screens often explain why data is wanted but say nothing about what happens if the person declines. P3.2 expects the organization to tell data subjects the consequences of not giving consent. Review each consent prompt and confirm it states whether declining blocks the feature, limits it, or changes nothing, using wording that matches what the product actually does.

Wording changed without versioning

Product and legal teams revise consent language during releases, but the old text may be overwritten in place. When an auditor samples a consent from months earlier, the organization cannot show what the person actually read. Keep each version of the consent text with an effective date and map every consent record to the version displayed.

Consent stored without the wording shown

A consent table that holds only a timestamp and a yes flag proves that something was clicked, not that the explanation was given. Documenting explicit consent to retain information means keeping enough to reconstruct the screen. Store the version identifier, the user or account reference, the channel and the time, and confirm that a support engineer can retrieve the record quickly.

Third-party SDKs collecting before the gate

Analytics, session replay, chat and advertising scripts often start collecting identifiers as soon as a page loads, which can happen before the consent prompt appears. The consent gate covers only the data your code requests, not what embedded components send. Inventory every third-party script, load them only after the recorded consent, and test a fresh session with network inspection to confirm nothing leaves early.

Questions buyers ask about P3.2 cost, effort and scope

Can a self-hosted team meet P3.2 without outside help?

Often yes, if the team owns the consent decisions and has someone who can write them down clearly. P3.2 asks the organization to decide which information needs explicit consent, explain why consent is needed and what happens if a person refuses, and obtain consent before collecting that information. Those steps depend on product knowledge and legal review, which usually sit with the organization, not an implementation partner. Outside help is most useful for building the consent flow in self-hosted systems, capturing and storing consent records, and preparing the evidence an auditor will sample. The organization still owns the controls. Only an independent CPA firm issues the SOC 2 report.

What drives the effort to implement P3.2?

The main driver is how much personal information the service collects that needs explicit consent. Each category of information needs its own explanation, its own refusal consequence and its own consent record. Other drivers include how many collection points exist (sign-up forms, APIs, imports, support channels), whether consent is captured in one identity system or several, and how many self-hosted deployments must behave the same way. Effort also rises when consent wording has to be reviewed by legal counsel in several jurisdictions. Ask any provider to break the work into mapping information types, designing the consent screens and records, testing refusal paths and collecting evidence.

How long does it take to get P3.2 evidence in place?

No duration is supplied for this criterion, so treat any timeline as unconfirmed until it is written into a scope. The time depends on how many collection points need consent changes, how quickly the legal team approves wording, and whether consent records already exist. Ask your implementation partner for a timeline tied to specific deliverables, such as a list of explicit consent categories, approved consent language, a working capture flow and a sample of retained consent records. Also confirm with your SOC 2 auditor when the observation period begins, because a Type 2 report needs the controls to operate across that period.

How does P3.2 differ from P2.1?

P2.1 covers choice and consent across the whole life of personal information, including collection, use, retention, disclosure and disposal. P3.2 is narrower. It applies to the specific information that needs explicit consent before collection, and it requires telling people why consent is needed and what happens if they refuse. In practice, P2.1 sets the broad choice framework and P3.2 adds the collection-stage detail. Both criteria point to documented consent, so one consent record design can often serve both, but the explanation at the point of collection is what P3.2 adds. Confirm the exact criteria wording in the AICPA Trust Services Criteria before relying on this summary.

Can an auditor write the consent wording for us?

No. An independent CPA firm examines and tests the controls, and it cannot design them or write the consent text for the organization without compromising its independence. The organization owns the wording, and its legal or privacy counsel should review it against the laws that apply to its customers. An implementation partner can help build the consent screens, store the records and document the process, but it does not issue the report. Ask your auditor which preparation work it can perform and which it must leave to you, and get that split in writing before fieldwork starts.

What must the organization supply to start P3.2 work?

Start with a clear inventory of personal information and the collection points where it enters your systems. Then provide the current consent flows, screenshots or copies of existing notices, a list of the people who approve privacy wording, and access to the self-hosted environments where consent is captured and stored. You will also need your existing privacy policy, data flow diagrams and any customer contract terms that restrict collection. A fixed-scope written agreement should list which of these you supply and which the partner delivers, so both sides know who is responsible for each deliverable.

What do the costs of P3.2 include beyond the initial build?

Costs fall into one-time work and recurring work. One-time work includes mapping information types, drafting and approving consent language, building the capture flow and setting up record storage. Recurring work includes reviewing consent wording when collection changes, keeping consent records retrievable for the auditor, and sampling evidence each period. Internal staff time for legal review and product decisions often costs more than the technical build. No price is supplied here. When you request a quote, ask for each deliverable, the assumptions behind it, who performs legal review and what ongoing support is included.

How DeployOpen prepares consent evidence for P3.2

DeployOpen plans, implements and documents the consent gate for P3.2 inside your own infrastructure, under a fixed scope agreed in writing before work starts. In practice that means building the mechanism that stops collection of explicit-consent information until a data subject has agreed, recording that agreement, and assembling the records an auditor will sample. The work runs in your cloud accounts, data centers or air-gapped network, so the consent records, logs and configuration stay under your control. DeployOpen does not issue a SOC 2 report, attestation or opinion. Only the independent CPA firm that performs the examination can do that.

Your organization owns the consent decisions. Your privacy and legal teams decide which information needs explicit consent, what the request says about why consent is needed and what happens if someone refuses, and which purposes the consent covers. Those decisions should be written down and approved before any engineering starts, because the evidence must show that the consent wording a user saw matches the version the system actually stored. Ask the implementation partner to confirm in the statement of work which artifacts will be delivered, such as the consent text versions, the configuration that enforces the gate and a sample of stored consent records, and who keeps each one after handover.

The CPA firm tests the design and, in a Type 2 examination, the operation of the gate over the observation period. Confirm early with your auditor which populations and samples they will draw, how they want consent records exported, and whether they expect the refusal path to be tested separately from the acceptance path. Your team should also plan how to handle users who change their minds, since withdrawal and re-consent events generate evidence that must be kept as well. These questions are easier to settle before the fixed-scope build than after the auditor has requested records from a system nobody designed to produce them.

P3.2 Explicit consent for collection