A SOC 2 privacy criterion is the set of controls and operating practices an organisation uses to handle personal information responsibly. It focuses on collection, use, retention, disclosure, access, quality, and monitoring so that personal information is processed in line with stated objectives and public commitments.
Expanded Definition
SOC 2 Privacy Criterion sits within the broader Trust Services Criteria and defines how an organisation should govern personal information across its lifecycle. It is not a standalone privacy law or a generic security label. Instead, it describes an assurance boundary: the organisation states how it collects, uses, retains, discloses, accesses, and monitors personal information, then demonstrates that its operating practices match those commitments.
The practical boundary is important. A privacy criterion can cover policies, notices, internal handling rules, vendor oversight, and evidence of control operation, but it does not itself replace legal obligations such as data protection law. In practice, teams often confuse “privacy” with “security”; the criterion is related to both, yet it is specifically about whether personal information is processed consistently with stated objectives and public commitments. For the canonical source, the SOC 2 Trust Services Criteria (AICPA) is the primary reference point.
Examples and Use Cases
Organisations typically encounter the privacy criterion when they need to show auditors, customers, or procurement teams that their handling of personal information is controlled and consistent. Common examples include:
- A SaaS provider maps customer support workflows to stated notice language so personal data is only used for documented service purposes.
- A finance or healthcare vendor defines retention rules for account records and proves that deletion or archival follows policy.
- A platform restricts employee access to customer records and reviews those permissions periodically to confirm that access remains justified.
- A business documents how it shares personal information with subprocessors and verifies that disclosures match contractual and public commitments.
- A data team checks whether collected fields are necessary for the intended purpose, reducing overcollection and downstream handling burden.
There is often a tradeoff between operational convenience and privacy discipline. Broader collection and longer retention can make analytics or support easier, but they also enlarge the set of records that must be governed, reviewed, and defended during an assurance assessment.
Security Implications
When the privacy criterion is treated as a paperwork exercise, the failure is usually not a single technical flaw but a mismatch between declared practice and real processing. That mismatch can create audit findings, customer trust issues, contractual disputes, and regulatory exposure if statements about use, disclosure, or retention are inaccurate.
Common failure modes include excessive internal access, undocumented secondary use of personal information, weak retention enforcement, and poor monitoring of third-party disclosures. These are not just compliance gaps; they can expand the blast radius of an incident because more records exist, more parties receive them, and fewer controls exist to prove what happened.
For NIST-aligned privacy control thinking, the privacy theme is closely reflected in the security and privacy control family described in NIST SP 800-53 Rev 5 Security and Privacy Controls, which helps clarify how privacy expectations are operationalised alongside protection measures.
Domain and Governance Relevance
SOC 2 Privacy Criterion matters because it turns privacy from a general promise into an examinable operating model. Governance teams must be able to explain who approves data use, who owns retention decisions, how access is reviewed, and how exceptions are tracked. If those answers are inconsistent, the organisation may still have controls, but it will struggle to prove that the controls support its stated commitments.
The criterion also has a material identity and access dimension, but that is secondary to the privacy objective itself. Access governance matters here because personal information should not be broadly exposed simply because it exists in a business system. Where personal data sits inside SaaS platforms, support tooling, or analytics pipelines, the key governance question is whether access, disclosure, and retention stay aligned to purpose.
For teams building a privacy assurance narrative, the most useful comparison is between documented commitment and observable operation. If those two drift apart, the criterion becomes difficult to defend in audit evidence, vendor reviews, and customer due diligence.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST CSF 2.0 set the technical controls, while PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 14 — Security Awareness and Skills Training | Supports staff handling of personal information with privacy-aware practices. |
| Recommendation — Train personnel to recognise and follow privacy handling requirements. | ||
| NIST CSF 2.0 | PR.DS — Data Security | Directly covers protection of data throughout handling and retention. |
| GV.PO — Policy | Maps to documented privacy commitments and operating policies. | |
| PR.AA — Identity Management, Authentication, and Access Control | Relevant where access to personal information must be restricted and reviewed. | |
| Recommendation — Apply data-security controls to protect personal information in transit and at rest. Document privacy policies that match actual processing and disclosure practices. Restrict access to personal information to authorised roles and review it regularly. | ||
| PCI DSS v4.0 | 12.8 — Risk Management for Third-Party Service Providers | Applies where personal data handling is delegated to providers and subprocessors. |
| Recommendation — Assess third-party handling of personal information before and during engagement. | ||
Related resources from NHI Mgmt Group
- Why do organisations add Confidentiality or Privacy criteria on top of Security in a SOC 2 audit?
- How do identity signals fit into SOC stress testing during privacy campaigns?
- How should security teams govern non-human identities for SOC 2 compliance?
- How can SOC teams use identity context to improve response to agent activity?
