P3.1 Collection of personal information: SOC 2 evidence

What SOC 2 P3.1 asks for when you collect personal information

P3.1 asks that personal information be collected consistently with your organization's privacy objectives. If you are preparing a privacy-category SOC 2, the practical test is whether you can show that every category of personal data you gather has a stated purpose, that you collect no more than that purpose needs, and that data subjects are told when you acquire more. P3.1 is the first of two criteria in the P3 collection group, and it sits inside the privacy category, which is included in a SOC 2 only when you scope it in. Its three points of focus describe how to design and evaluate the control: limiting the collection of personal information, collecting it by fair and lawful means and from reliable sources, and informing data subjects when additional information is acquired. These are characteristics that help you design and assess controls, not separate requirements, so you do not need to address every one of them word for word, but your design should be able to explain how each is handled.

The difficulty is that collection rarely happens in one place. Personal information enters through sign-up forms, onboarding flows, support tickets, product telemetry, webhooks, CRM and marketing integrations, payment and identity providers, and data imported from customers' own systems. Each entry point can add fields that nobody revisited after launch. Start by building an inventory of collection points that maps each field to its stated purpose, its source and the notice that describes it. Then ask for each field whether it is necessary for that purpose, whether it came from a reliable source, and whether the person was told when it was added later, for example through an enrichment vendor. Confirm with your auditor how they expect to see this evidence, including whether they will sample collection points or rely on a documented review, because the answer shapes how much of this inventory you must keep current between audit periods.

Which systems, data and teams fall under P3.1 scope

P3.1 applies wherever your service gathers personal information, whether a person types it in or a system captures it automatically. The cards below cover the collection paths, teams and tools that auditors and assessors usually trace first, and the scoping question that decides whether the privacy category applies at all.

Whether the privacy category is in scope

P3.1 is part of the privacy category, which applies only when management includes it in the system description and the engagement. Confirm the decision with your CPA firm before fieldwork starts, and document why privacy is in or out. If you collect personal information but leave privacy out, customers will still ask how that data is collected, so the answer needs to be consistent across your contracts, trust page and report.

Sign-up forms and account creation

Registration, onboarding and profile forms are the most visible collection points. For each field, record why it is needed for the stated service, whether it is optional, and whether the data subject is told what it is used for at the point of entry. Fields added for marketing or analytics convenience often outlast the feature that needed them, so review the form against current purpose statements at least once a year.

APIs, integrations and third-party data feeds

Inbound APIs, webhooks and data feeds from partners, enrichment vendors or customer systems can bring in personal information you never asked for directly. Inventory each endpoint and feed, document the data elements it carries, and confirm the source is reliable and the transfer is lawful under the agreement. Unexpected fields in a payload are a common finding, so validation rules and rejection logs should be part of the evidence.

Event tracking, logs and support tickets

Product analytics, session recording, application logs and support ticket systems often capture personal information through free text, identifiers or IP addresses. Map which events and log fields contain personal data, decide what is minimized or masked before storage, and tell data subjects when additional information is acquired through these channels. Support teams frequently request sensitive details to resolve a case, so agree on what staff may ask for and document it.

Product, marketing and sales tools

Marketing automation, CRM, advertising pixels and sales prospecting tools collect data on behalf of different teams, often under separate accounts that IT does not administer. List every tool that receives personal information, the team that owns it, and the lawful basis or stated purpose for each collection. Tools added by a single team without review are the usual gap between the documented collection practices and what the system actually gathers.

Application logs and infrastructure telemetry

Access logs, error traces and infrastructure telemetry can carry usernames, email addresses or IP addresses that were never intended as data collection. Review log schemas and sampling rules with the platform team, and confirm retention and access settings match the collection purpose. Treat logging pipelines as part of scope, not as internal plumbing, because assessors will ask what was collected and how it reached those stores.

How an SOC 2 assessor tests P3.1

This table compares the assessor's test steps for P3.1 with the evidence each step asks for and the findings that usually come out of it. Read it as a preparation checklist: each row shows what the assessor will try to see, so you can check whether your collection points leave a record. The main takeaway is that P3.1 is tested against documented objectives and against what the systems actually collect, so gaps between the two are the most common problem.

Test step	Evidence the assessor requests	Common finding
Inquiry with privacy and product owners	Walkthrough notes on why each personal data field is collected and who approves new fields	Staff describe collection from memory and cannot point to a documented purpose
Inspection of privacy objectives	Current privacy objectives or notice text, with version and approval dates	Objectives exist but do not name the categories of personal information collected
Inspection of collection documentation	Data inventory or record of processing that lists each collected field, its source and its purpose	Fields collected by application code or analytics tags are missing from the inventory
Inspection of collection points	Screenshots or exports of sign-up forms, checkout flows, APIs and mobile SDK settings	Optional fields are presented as required, or collection occurs before the user is told
Review of third-party and indirect sources	Contracts, data feeds and enrichment vendor lists showing where additional information comes from	Data bought or pulled from external sources has no recorded legal basis or source
Sampling of collected records	A sample of records with their collection date, source and form version, compared against the objectives	Sampled records contain fields the objectives do not justify, such as legacy attributes
Check of notice when additional information is acquired	Change logs, notice versions and messages sent when new collection began	New collection started with no notice update or record of when data subjects were informed

How to implement P3.1 in six steps

This sequence takes P3.1 from a stated privacy objective to a collection practice that an assessor can trace, with each step producing a record the auditor can sample. It keeps the organization in charge of its decisions while the implementation partner and engineers prepare the systems and evidence.

Document the privacy objectives
Leadership, with the privacy or compliance lead, writes down the purposes for which the organization collects personal information and the categories of people it collects it from, such as customers, employees and job applicants. Engineering and product review the list so it matches how the product actually works. The step is done when the objectives are approved, versioned and linked from the control matrix, because every later decision about collection is measured against them.
Inventory every collection point
Engineering and product owners list each place personal information enters the system: web and mobile forms, APIs, SDKs, file uploads, support channels, vendor feeds, analytics tags and internal admin tools. A practical method is to start from the data flow diagrams and the application code, then confirm the list with the people who own each surface. The output is a collection register with one row per entry point, an owner and a short description of what it captures.
Map each data element to a stated purpose
For every field in the collection register, the data owner records the specific purpose it serves and the objective it supports. A field that cannot be tied to a documented purpose becomes a candidate for removal. The privacy lead reviews the mapping and signs off on any field whose purpose is broad or shared across products. The output is a data element map that an assessor can use to test whether collection follows the stated objectives.
Remove or justify unnecessary fields
Using the data element map, the team removes fields that collect more than the purpose needs, makes optional fields truly optional, and replaces full identifiers with less identifying values where the function allows it. Each field that remains gets a short written justification. Engineering records the change in the ticketing system and, where the change touches production forms or APIs, follows the change management process. The output is a reduced collection schema and a change log showing what was removed and why.
Document source and lawful basis for each source
For each remaining data element, the owner records where it comes from: the individual directly, a third party, a public source, or a system that derives it. The privacy or legal lead then records the lawful or contractual basis for collecting it from that source, and checks that third-party sources are covered by contract terms. Where a source is unreliable or unverifiable, the record notes the safeguard applied. The output is a source register that the organization can show to an assessor and to its own legal reviewers.
Set up notices and prompts for additional information
Product and engineering configure the points where the organization acquires information beyond what the individual provided, such as enrichment from a data provider or a new data source added to an existing profile. Each of these triggers a notice or in-product prompt that explains what is being added and why, and the event is written to an audit log. The privacy lead tests a sample of triggers before release. The output is a list of notification triggers, the notice text for each, and test records showing the notices appear as designed.

How collection controls connect to engineering and privacy teams

The control that matters most for P3.1 is a trust boundary between product, data engineering and the privacy owner: product decides which fields a feature needs, data engineering builds and stores them, and the privacy owner decides whether the purpose justifies the collection. Each side must be able to see the others' decisions, or personal information gets collected by default and nobody can explain why. For a SOC 2, the auditor will want to see that this boundary is written down, that named roles hold each decision, and that the handoffs leave records an examiner can sample.

The preventive side of the boundary sits in three places. Schema reviews check that new tables, columns and event payloads map to a documented purpose before they reach production, so a field like date of birth cannot appear in an analytics pipeline without someone signing off on it. Form change control applies the same logic to user-facing collection: any new or altered field on a sign-up, checkout or support form goes through a ticket that records the purpose, the data category and the privacy owner's approval. Third-party data onboarding covers data arriving from brokers, enrichment vendors or partner feeds, where the review should confirm the source is reliable and that the collection still fits the stated objectives. Ask your engineering leads which of these gates are enforced in tooling, such as a required approval in the repository or a pipeline check, and which rely on people remembering to ask.

The detective side is the periodic inventory review. The privacy owner and data engineering compare the live data map, including warehouse tables, SaaS integrations and logs, against the approved register, and log every field that has no recorded purpose. Findings should create tickets with owners and due dates, and the review record itself becomes evidence that controls are operating across the observation period of a Type 2 report. Confirm with your auditor how often they expect the review and what sample of changes they will select, since those choices determine how much evidence the team must keep.

Evidence that passes a P3.1 test

An assessor testing P3.1 wants to see that personal information collection is limited by documented objectives and that the systems doing the collecting follow those objectives. The six artifacts below connect the stated purpose to what the platform actually asks users for, and to the records that show the two stayed aligned between audit dates.

Documented privacy objectives

The written privacy objectives are the baseline every collection decision is tested against. They should name the categories of personal information the service collects, the purposes for each, and the fair and lawful basis the organization relies on. Check that the objectives are approved by a named owner, version-controlled, and reviewed when the product adds a feature that asks for new data. An assessor will compare later collection points against this document, so a vague objective gives no test to pass.

Data inventory with purpose and source

A data inventory lists each personal information element, the system where it is stored, the purpose it serves, and where it came from, such as the data subject, a partner or a public register. The purpose and source fields carry most of the P3.1 weight. Keep the inventory tied to the self-hosted deployment so it reflects the actual databases and object stores in the client's environment, and confirm each entry during every quarterly review.

Collection form and API schema records

Forms, mobile screens and API schemas are where collection actually happens. Keep the schema files and form definitions in version control, with the change history showing who added each field and why. A reviewer testing P3.1 will look for fields that have no matching purpose in the inventory. Pull the schema from the running system periodically and diff it against the repository to catch fields added outside the review process.

Third-party data source agreements

When personal information comes from a data broker, enrichment vendor or partner system, the contract should state what data is supplied, the lawful means used to collect it, and the sources the supplier relies on. These agreements show the reliable-source expectation in practice. Store them alongside the inventory, record the renewal date, and flag any source that cannot document how the data was obtained.

Notice records for additional collection

When the organization acquires personal information beyond what a data subject first provided, the notice record shows that the person was told. Keep a log of notices sent, the trigger event, the channel used and the date. Test the notice path at least once a year by running a sample flow in a staging environment and saving the screenshots or message logs as evidence.

Periodic review sign-offs

Sign-offs prove that someone checked collection against objectives on a schedule, not only when the auditor asked. Record each review with the date, the reviewer, the scope, the findings and the remediation tickets opened. Set the cadence in the privacy policy and keep the sign-offs in the same evidence repository as the objectives, so an auditor can trace a finding from the review to the corrected field.

What meeting P3.1 costs in money and effort

This table breaks down the cost components of meeting P3.1 Collection of personal information, who is paid for each, whether it is one-time or recurring, and what moves it up or down. No figures are supplied for these components, so use the table to structure your quote requests and internal budget conversations.

Cost component	Who is paid or who does the work	One-time or recurring	What drives it up or down
Data inventory of personal information collected	Internal privacy and engineering staff, sometimes supported by a consultant	One-time to build, recurring to refresh	Number of systems, forms, SDKs and third-party feeds that collect personal data; ask whether the quote covers discovery across all products
Engineering time to remove or justify fields	Internal engineers or an implementation partner preparing the change	One-time for most fields, recurring when new features add collection	Number of legacy fields with no stated purpose; a field-by-field justification step adds effort but usually reduces later disputes
Privacy counsel or consultant review	Outside privacy counsel or consultant, billed by time or fixed scope	One-time for the collection statement, recurring on material product change	Jurisdictions in scope, sensitivity of the data and how many notices must be reviewed; ask for the review scope in writing
Tooling for collection controls and evidence	Open-source self-hosted tools (for example form logging or data catalog software) run in your own infrastructure, with internal or partner setup time	Mostly one-time setup, recurring hosting and upkeep	Self-hosting can reduce license spend, but hosting, patching and staff time remain; confirm which features each tool supports before adopting it
Evidence upkeep	Internal control owners who collect records of collection decisions and changes	Recurring across the observation period	Frequency of product changes that touch forms, APIs or data sources; automated change logs reduce manual collection effort
Auditor sampling and walkthroughs	The CPA firm, billed under the engagement letter	Recurring at each examination	Number of collection points and changes sampled, and how well evidence is organized before fieldwork; ask the firm how it plans to sample
Ongoing monitoring between audits	Internal staff, or a retainer with an outside partner	Recurring	Rate of new data sources, acquisitions and third-party integrations that bring new collection paths

Who does what for P3.1: your team, a partner and the auditor

Your organization owns the criterion. P3.1 asks that personal information be collected consistently with your privacy objectives, so the people who write those objectives must decide what is collected, why, from whom and by what lawful or fair means. A partner cannot make those choices for you, and an auditor will look for evidence that management made them. Internal owners typically include the privacy lead or DPO, product owners who decide which fields forms and integrations capture, and legal or compliance staff who confirm the lawful basis.

Privacy objectives: Written statements of purpose that name the categories of personal information you collect and the reasons for each.
Collection decisions: Approvals for new data fields, forms, tracking or third-party sources, with the reason recorded before go-live.
Source reliability: Rules on which sources (the individual, partners, public records, data brokers) are acceptable and how their accuracy is judged.
Notice triggers: A defined process to tell data subjects when you acquire additional information about them, tied to your privacy notice.
Ongoing review: A recurring check that collection still matches the stated objectives after product or vendor changes.

Confirm that a named owner signs off on these decisions and that the approvals are retained as evidence.

Where organizations fail P3.1 and how to close the gap

P3.1 is tested by asking whether personal information is collected in line with stated privacy objectives. Most failures are not deliberate: collection happens in places the privacy owner never saw, through tags, forms and feeds that were added for other reasons. The gaps below are the ones assessors most often find when they trace data from the point of collection back to the documented purpose.

Collection points nobody inventoried

Personal information enters through web forms, mobile SDKs, support tools, sales CRMs and partner APIs, and many of these were added by product or marketing teams without a privacy review. An assessor will ask for a complete list of collection points and compare it with the privacy objectives. Fix: build a data flow inventory from code, API gateway logs and vendor contracts, assign each collection point an owner, and review the list at every release.

Shadow analytics and tracking tags

Marketing and product teams often load analytics, session replay or advertising tags through a tag manager without a ticket, and those tags can capture form inputs, IP addresses or identifiers. This is collection the privacy owner never approved. Fix: restrict who can publish tags, require a recorded purpose for each tag, and scan production pages on a schedule to compare loaded scripts with the approved list.

Fields collected without a recorded purpose

Forms often ask for more than the service needs, such as a date of birth on a newsletter signup or a full address for a free trial. Without a documented purpose for each field, the organization cannot show that collection is limited to what its objectives require. Fix: map every field to a stated purpose in a data dictionary, remove fields with no purpose, and require a privacy sign-off for new fields.

Third-party sources without documented origin

Data bought from brokers, enriched from public records or received from integration partners frequently arrives with no record of how the provider obtained it. P3.1 expects collection from reliable sources by fair and lawful means, so an unknown origin is a finding. Fix: require each provider to state its collection method and lawful basis in writing, store that statement with the dataset, and reject sources that cannot document it.

New fields added without notice

When a product team adds a field or changes a data source, existing notices may no longer describe what is collected. P3.1 includes telling data subjects when additional information is acquired, so a silent schema change creates a gap. Fix: tie schema changes to the release process, have the privacy owner check whether the privacy notice needs an update, and keep a dated change log that an assessor can sample.

Collection by integrations and self-hosted services

In self-hosted platforms, collection can happen through logging pipelines, error trackers and backup agents that capture personal information incidentally. Teams often treat these as infrastructure and leave them out of the privacy review. Fix: include logging, monitoring and support tooling in the data flow inventory, configure them to drop or mask fields that the purpose does not require, and document the decision.

Questions buyers ask about P3.1 cost, effort and audit

Does P3.1 still apply if privacy is not in scope for our SOC 2?

No. P3.1 belongs to the privacy category, so it is only tested when privacy is included in the examination scope. Security is covered by the common criteria CC1 to CC9, which apply to every SOC 2 report, and the other categories add criteria only when they are in scope. Many software companies start with security alone and add privacy later, usually when a customer asks how personal information is collected. If privacy is out of scope, the work on P3.1 is still useful, because a documented collection inventory supports the privacy notice and the access and retention controls. Confirm the category selection with your CPA firm before fieldwork begins, since changing scope later can change the system description.

How long does a collection inventory take, and what makes it take longer?

The duration depends on how many systems hold personal information and how well the owners of those systems know their own data. The work usually covers the product forms and APIs that collect data, the internal tools that receive it, third-party tools and analytics, and the data sources that feed the product, such as purchased lists or partner feeds. The main drivers are the number of data flows, whether data is collected by product teams without central review, and whether a data map already exists. We do not have a supplied figure for typical effort, so ask any partner to state the assumed number of systems and interviews in the written scope and to show how the inventory will be updated after the audit. The inventory is a one-time build with recurring upkeep whenever a new collection point is added.

Can our own team complete the P3.1 work without an outside partner?

Often yes, if someone on the team owns the data map and can get answers from each product and operations owner. The work is mostly documentation, interviews and review, so the main cost is staff time rather than tooling. An outside partner is useful when the team lacks time to interview owners, when the data flows are spread across many cloud accounts, or when the team needs a second reviewer before the auditor sees the evidence. Any partner can prepare systems, records and evidence, but only the organization owns the control and only the independent CPA firm issues the report. Keep the policy, the approval record and the review cadence in-house so the control keeps working after the engagement ends.

What will the auditor sample when testing P3.1?

The auditor selects samples from the period covered by the report and checks whether collection matched the documented privacy objectives. For a Type 2 examination, expect requests for the collection inventory or data map, the approved privacy objectives, the procedure for reviewing new collection points, and records of changes to forms, APIs and third-party data sources during the period. The auditor will typically test whether personal information collected through the sampled channels was limited to what the objectives describe, and whether the source was recorded as fair, lawful and reliable. The sample sizes are set by the auditor, not by the organization, so ask the CPA firm to confirm its sampling approach in writing. Keep dated versions of the inventory, because the auditor cannot test a control against a document that was edited after the fact.

How does P3.1 differ from P3.2 on explicit consent?

P3.1 covers how personal information is collected in general: limited to the stated purposes, gathered by fair and lawful means, drawn from reliable sources, and disclosed to the data subject when more information is acquired. P3.2 applies only to information that requires explicit consent, and asks that the organization explain why consent is needed and what happens if someone refuses, then obtain that consent before collection. Put simply, P3.1 governs the scope and source of collection, while P3.2 governs consent for a subset of that collection. Both criteria rely on the same inventory, so one data map can serve both controls. Confirm with your CPA firm how it will map evidence to each criterion, since the auditor decides how the criteria are tested.

What should we ask a partner to put in a written scope for P3.1 work?

A written scope should name the systems and data flows covered, the interviews and reviews the partner will perform, the documents it will produce, and the evidence it will prepare for the auditor. Ask which personal information categories are in scope, who approves the privacy objectives, and how the inventory will be kept current after the report. Ask the partner to state what it does not do: it does not issue reports, attest to controls, or decide on the auditor's sample. Also ask for the schedule, the client responsibilities such as access to staff and systems, and the process for changes to scope. Most DeployOpen engagements are fixed-scope, so the written scope fixes deliverables and timelines before work starts. Request a quote that follows from that scope rather than a fixed price for the whole examination.

Which tools help maintain the collection inventory and its evidence?

Tools matter less than ownership, but they make the inventory easier to keep current. Teams often start with a spreadsheet or a data catalog, then move to a self-hosted GRC or data-mapping tool once there are many owners. Source control is useful for keeping dated versions, and form and API definitions stored as code can show what was collected at each point in time. Confirm that any self-hosted tool can export its records in a form the auditor can read, and that access to the inventory is restricted and logged. DeployOpen implements and hardens self-hosted open-source platforms inside the client's own infrastructure, so the tool choice can follow the client's existing environment. Verify each product's capabilities with its vendor before you rely on them for evidence.

How DeployOpen prepares P3.1 evidence for your audit

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so the collection controls behind P3.1 Collection of personal information can be built and evidenced there. We prepare systems and evidence for your examination, while your CPA firm independently performs the examination and issues the report.

How we scope

Agree in writing which systems, forms and data flows that collect personal information fall within the P3.1 scope.
Document the privacy objectives that collection must follow, so each collection point can be traced back to a stated purpose.
Confirm with your CPA firm which points of focus they will test and which evidence they expect for each one.

How we build

Configure self-hosted platforms to collect only fields that the documented purpose requires, and record the justification for each field.
Set up notices and collection prompts that tell data subjects when additional information is acquired from another source.
Test collection paths for fair and lawful collection and confirm that data arrives only from sources your organization has approved.

How we hand over

Deliver a control description, configuration records and a collection inventory that your team owns and can maintain.
Provide a dated evidence set mapped to P3.1 so your auditor can select samples and trace them to source records.
Walk your team through the evidence and the known gaps before fieldwork begins, in writing and in agreed formats.

How we support

Offer ongoing support and continuous testing as a retainer, so collection controls keep producing evidence between audits.
Review changes to forms, integrations and data sources for their effect on the collection controls before they go live.
Support your team through auditor questions and sampling requests during the observation period, within the agreed scope.