What are the SOC 2 privacy criteria, and what do they actually require?
SOC 2 examinations assess controls against the AICPA's Trust Services Criteria; every report includes the security category (the common criteria, CC-series), and organizations optionally add availability, processing integrity, confidentiality, and privacy. The privacy category (P-series criteria) is the most extensive add-on, organized around the personal-information lifecycle: notice and communication of objectives (P1: providing notice about collection, use, retention, disclosure, and disposal); choice and consent (P2: communicating choices and obtaining consent consistent with commitments); collection (P3: collecting consistent with objectives, and by fair and lawful means); use, retention, and disposal (P4: limiting use to identified purposes, retaining per commitments, disposing when no longer needed); access (P5: providing data subjects access and correction); disclosure and notification (P6: disclosing to third parties only per commitments, with breach notification processes); quality (P7: maintaining accurate, complete, relevant personal information); and monitoring and enforcement (P8: processes to address privacy inquiries, complaints, and disputes). The load-bearing concept is 'commitments and system requirements': the examination does not test you against the GDPR or any statute, it tests whether your controls achieve the privacy commitments you have made, in your privacy notice, your DPAs, your contracts, plus applicable system requirements, which produces the under-appreciated dynamic that your own privacy policy is the audit standard: a notice promising 'we never share your data' while your architecture ships events to twelve subprocessors is not a legal-drafting foot-fault in this context, it is a controls failure with your auditor's name on it. Points of focus under each criterion (revised 2022) guide the evidence: data inventories, consent records, retention schedules with disposal evidence, DSAR workflows, subprocessor management, incident response, the same operational machinery every privacy regime converges on.
How is privacy different from confidentiality in SOC 2, since teams routinely confuse them?
The distinction is subject-matter and framework. Confidentiality (C-series) protects information designated as confidential, whatever it is: customer business data, trade secrets, financial records, source code, under commitments to limit access, use, and retention, ending in defined disposal; its paradigm case is the B2B promise 'we protect your proprietary data,' and its data subject is a counterparty organization. Privacy (P-series) governs personal information, data about identifiable natural persons, against a lifecycle framework (notice, choice, collection, use, access, disclosure, quality, monitoring) whose beneficiary is the individual, not the customer who signed the contract; it imports the fair-information-practices tradition into the attestation. The practical tests for which you need: if your service processes personal information as a meaningful part of its function (an HR platform, a marketing tool, a health app backend, anything with consumer end-users), the privacy category speaks to that processing in a way confidentiality cannot, because confidentiality has nothing to say about consent, individual access rights, collection limits, or notice accuracy; conversely, a pure infrastructure product handling encrypted customer blobs may genuinely have little personal-information lifecycle of its own to attest, and confidentiality covers its real promises. The common configurations: security alone (the minimum viable SOC 2, most startups' first report); security + availability + confidentiality (the standard B2B SaaS stack); privacy added where the product's data is people (HR tech, martech, health tech, fintech consumer products) or where enterprise customers' vendor-risk teams demand it for GDPR Article 28 diligence. One more confusion to retire: SOC 2 privacy is unrelated to SOC 1 (financial-reporting controls) and to the discontinued-in-practice SOC 3 seal, and 'SOC 2 certified' is a misnomer throughout, SOC 2 is an attestation examination producing a CPA's opinion, not a certification, a distinction that matters when marketing writes the trust page.
What does adding the privacy category to a SOC 2 examination actually involve?
The delta on top of an existing security-scope SOC 2, staged. Commitments inventory first: collect every privacy promise you have made, the public privacy notice, DPA terms across your customer base (the negotiated ones too, which nobody remembers), in-product consent language, marketing claims, because the criteria measure you against these; this inventory routinely surfaces the first findings by itself, stale notices, contradictory DPA clauses, promises the product cannot keep. Gap assessment against the P-criteria: walk P1 through P8 asking what control satisfies each and what evidence proves it operates: a current data inventory and RoPA-equivalent (P1, P3, P4 lean on it), consent capture and records where consent is the model (P2), purpose-limitation enforcement (P4, the hard one technically, purpose-bound access rather than policy prose), DSAR intake and fulfillment with logs (P5), subprocessor register with flow-downs and breach-notification clocks (P6), data-quality processes (P7, usually the thinnest existing muscle), and complaint handling (P8). Remediate with the Type II window in mind: a Type I opines on design at a point in time, a Type II on operating effectiveness across a period (commonly 6-12 months), so controls must run, generating evidence, through the window, meaning the DSAR you fulfill in month two and the disposal job that executes in month five are audit evidence, and gaps fixed mid-window show as exceptions for the pre-fix months. Auditor selection and fieldwork: privacy-scope examinations remain a minority of SOC 2 practice, so ask candidate firms specifically about P-series experience; fieldwork adds interviews and sampling across the privacy workflows (they will pull actual DSAR tickets, actual consent records, actual disposal logs). Cost and effort honestly: adding privacy typically extends an existing SOC 2 engagement by a meaningful fraction (auditor fees scale with criteria count and sampling scope), and the internal lift concentrates in whatever lifecycle machinery you lacked, organizations with a real privacy program find it a documentation exercise, organizations without one discover they are building the program under audit deadline, which is the wrong sequence.
How does SOC 2 privacy map to GDPR, and does it satisfy European customers?
The mapping is substantial at the controls layer and incomplete at the legal layer. Where they align: the P-criteria's lifecycle mirrors the GDPR's principles, notice (Articles 12-14), consent and choice (6, 7), collection limits (5(1)(b)-(c)), retention and disposal (5(1)(e)), access and correction (15, 16), third-party disclosure governance (28, the subprocessor machinery), quality (5(1)(d)), and complaint handling (12(3)-ish), so the operational controls a good GDPR program runs are largely the evidence a P-scope examination samples; building one control set feeding both is straightforwardly possible and is the sane architecture. Where SOC 2 falls short of the GDPR: no legal-basis analysis (the criteria accept your commitments as given rather than asking whether processing is lawful), no transfer mechanisms (Chapter V is invisible to it), no DPIA regime, no data protection officer, no 72-hour-clock specificity, and its jurisdictional frame is your promises rather than a data subject's statutory rights, meaning a SOC 2 privacy report can be clean while the underlying processing violates the GDPR (if your commitments were simply modest). What European counterparties do with it: as Article 28(3)(h) audit-and-inspection evidence and general vendor diligence, a SOC 2 Type II (security, plus privacy where relevant) is widely accepted and often contractually specified in DPAs as the audit-rights satisfier; it does not substitute for the GDPR compliance itself, and sophisticated EU customers know the difference, so position it as controls evidence within a GDPR posture, not as GDPR compliance. Against ISO 27701, the other credential in this slot: 27701 certifies a privacy information management system (organizational, role-aware, GDPR-mappable, certificate-shaped, three-year cycles), SOC 2 privacy attests period-of-time operating effectiveness with a detailed report a security reviewer can read; European procurement tends to recognize ISO paper faster, US enterprise vendor-risk tends to demand SOC 2, and mature processors serving both markets increasingly carry both on one control set, ISO 27701's PIMS as the spine, SOC 2's examination as the periodic deep evidence.
What are the common findings and failure patterns in privacy-scope examinations?
The recurring exceptions, from practitioner experience. Commitment-practice divergence, the category champion: privacy notices promising deletion timelines the systems cannot execute, 'we do not sell data' claims sitting atop adtech integrations that regulators would characterize otherwise, DPA clauses (the 30-day breach notification, the subprocessor-approval right) that operations never implemented; the fix is bidirectional, engineer the missing control or renegotiate the promise, and the audit's real gift is forcing that reconciliation. Retention and disposal theater: schedules exist, disposal does not, no TTLs, no deletion jobs, backups retained indefinitely, so P4 sampling asks for disposal evidence and finds none; auditors have become notably harder on this as regulators have. DSAR process gaps: intake exists but completeness does not (systems outside the fulfillment workflow's reach), verification is ad hoc, or the process was never exercised in the window (no requests arrived, and no synthetic test was run, leaving the auditor nothing to sample, a planning miss with an easy fix: test your own process). Consent-record fragility: consent collected but not recorded queryably (which version of which notice, when, for what), failing P2's evidence expectations exactly where GDPR audits fail it too. Subprocessor drift: the register says twelve, production says nineteen, the marketing team's new tool never entered the process, P6 findings that are really change-management findings. Inventory staleness undermining everything: since P1/P3/P4 sampling starts from your data inventory, an inventory the fieldwork disproves (the auditor finds stores it omits) contaminates confidence across the scope. Scope-gaming backfires worth naming: carving the privacy category down to a trivial system boundary produces a clean report your customers' vendor-risk teams read straight through, the report describes its own boundary, and a privacy scope excluding the product's actual personal-data processing signals more than it conceals. The meta-lesson across all of them: the examination samples reality against promises, so programs run for the evidence they generate, not the binder they fill, pass; programs run for the report, fail by degrees visible in the exceptions table.