P3.1 SOC 2

SOC 2 P3.1: Privacy - Collection Limited to Identified Purpose

What This Control Requires

Personal information is collected consistent with the entity's objectives related to privacy. The entity collects personal information only for the purposes identified in the notice and with the implicit or explicit consent of the data subject.

In Plain Language

Every field on every form needs a reason to exist. If you cannot explain why you are collecting a particular piece of data - tied to a specific purpose in your privacy notice - you should not be collecting it.

This is the data minimisation principle in action. It directly challenges the "collect everything, figure it out later" mentality that many engineering teams default to. Your sign-up form asks for a phone number? There had better be a documented reason. Your SDK captures device identifiers? That needs a stated purpose too.

Auditors will compare what you actually collect against what your privacy notice says you collect and why. They look for fields without a clear purpose, collection that exceeds what is needed, and data being used for purposes users were never told about. Mismatches here are common findings, especially in organisations that have grown quickly without revisiting legacy data practices.

How to Implement

Start with a data mapping exercise. Document every piece of personal information you collect, where it comes from, and the specific purpose for each element. Cover all channels: web forms, mobile apps, APIs, customer support interactions, and third-party data sources.

Review every collection point for necessity. For each field or data element, ask: is there a documented, legitimate purpose? If the answer is "it might be useful someday," remove it. Challenge long-standing collection practices that nobody has questioned in years.

Put technical controls in place. Configure forms and APIs to collect only what is needed. Mark optional fields clearly. Remove hidden collection mechanisms that capture more than users expect - fingerprinting scripts, excessive cookie data, metadata you never actually use.

Align what you collect with what your privacy notice says. If you collect something not mentioned in the notice, either add it to the notice (if justified) or stop collecting it. Check this alignment regularly, not just once.

Build privacy review into your development process. Before any new feature or product that collects personal data goes live, run a privacy review. Is the collection necessary? Is it proportionate? Does the privacy notice cover it? Document the review and its outcome.

Train your product and engineering teams on data minimisation. Help them understand that every unnecessary data element increases your attack surface, your compliance burden, and your liability. The default should be to collect less, not more.

Evidence Your Auditor Will Request

Data mapping documentation showing all personal information collected with purposes for each element
Evidence of data minimization reviews for collection points (forms, APIs, integrations)
Privacy review records for new data collection activities and feature launches
Alignment documentation comparing privacy notice collection statements to actual practices
Training records for product and engineering teams on data minimization principles

Common Mistakes

Data collection forms include fields that are not necessary for the stated purpose
Personal information is collected from third-party sources without a documented purpose
Data minimization reviews are not conducted for new features or collection activities
Privacy notice states purposes that do not align with the actual reasons data is collected
Legacy collection practices continue without review, collecting data for purposes that no longer exist

Related Controls Across Frameworks

Framework	Control ID	Relationship
ISO 27001	A.5.34	Partial overlap
nist-csf	GV.PO-01	Partial overlap

Frequently Asked Questions

Can we collect data for analytics and product improvement?

Yes, but you have to be upfront about it. Disclose it in your privacy notice and, depending on jurisdiction, get consent. Be specific about what analytics you run and what data feeds them. Also consider whether aggregated or anonymised data would serve the same purpose - if it would, use that instead of personal information. Under GDPR, analytics may fall under legitimate interest, but you will need a documented legitimate interest assessment to back that up.

How do we handle data collected before we had a minimization program?

Go through your historical data and ask one question per data element: do we have a current, legitimate purpose for this? If yes, keep it and document the purpose. If no, delete it, anonymise it, or at minimum archive it with restricted access. Update your data inventory to reflect only what is justified. It is a one-time cleanup effort, but auditors will want to see you have done it.

What about data collected automatically (cookies, device information)?

Same rules apply. Review every piece of automatically collected data and make sure each element has a stated purpose. Implement cookie consent that gives users real control over tracking. Minimise passive collection techniques like fingerprinting. And disclose all automatic collection in your privacy notice - users tend to be surprised by how much is gathered without their active input, and auditors know this.

Track SOC 2 compliance in one place

AuditFront helps you manage every SOC 2 control, collect evidence, and stay audit-ready.

Start Free Assessment