Learn · SOC 2 Scoping
SOC 2 Confidentiality
vs Privacy
Confidentiality covers information you have designated as confidential — how it is identified, protected through its retention period, and destroyed at the end of it. Privacy covers personal information across a full lifecycle, from the notice you publish to the complaints you resolve. Two criteria against eighteen, and the trigger for each is a promise you made, not a judgement about how sensitive the data feels.
The error that costs a quarter: assuming that because you handle personal data, you need the Privacy category. Most B2B service organisations holding customer personal data need Confidentiality. Privacy is triggered by commitments made to data subjects — not by the presence of personal information in your database.
TSP section 100 · 2017 Trust Services Criteria with revised points of focus (2022) · Last reviewed August 2026
Choose Confidentiality when a contract, agreement or regulation obliges you to restrict and eventually destroy information someone else entrusted to you. Choose Privacy when you have made commitments to the individuals the information is about. Confidentiality adds two criteria — C1.1, identifying and maintaining confidential information, and C1.2, disposing of it. Privacy adds eighteen, from the notice you give data subjects (P1.1) to the way you resolve their complaints (P8.1). In our readiness engagements these two are the most frequently over-selected categories, and they are over-selected for opposite reasons. Confidentiality gets waved through because it is only two criteria and “we obviously keep customer data confidential” — then the evidence request for a retention clock arrives. Privacy gets selected because the company processes personal data and somebody assumed that was the trigger. It is not. Both categories sit on top of the 33 common criteria that every SOC 2 already carries; neither replaces them. If you are still choosing across all five categories, start with choosing your trust services criteria, then come back here for the two that generate the arguments.
The definitional split
Two categories, two subject matters
The trust services criteria draw the line themselves, and the sentence is worth quoting because it settles most arguments before they start: confidentiality is distinguished from privacy in that privacy applies only to personal information, whereas confidentiality applies to various types of sensitive information. Confidential information may include personal information, along with trade secrets and intellectual property. That is an overlap in subject matter, not a merger of obligations.
| Dimension | Confidentiality (C series) | Privacy (P series) |
|---|---|---|
| Subject matter | Information designated as confidential, of any kind — source code, pricing, deal terms, algorithms, customer records, and personal information all qualify once designated. | Personal information only. The trust services criteria define it as information that is about, or can be related to, an identifiable individual. |
| The AICPA definition | “Information designated as confidential is protected to meet the entity’s objectives.” | “Personal information is collected, used, retained, disclosed, and disposed of to meet the entity’s objectives.” |
| Criteria added on top of the 33 common criteria | Two. C1.1 (identifies and maintains confidential information) and C1.2 (disposes of confidential information). | Eighteen, across eight series: P1.1 notice; P2.1 choice and consent; P3.1–P3.2 collection; P4.1–P4.3 use, retention and disposal; P5.1–P5.2 access; P6.1–P6.7 disclosure and notification; P7.1 quality; P8.1 monitoring and enforcement. |
| Where the objective comes from | Contracts and agreements — and sometimes laws or regulations — that require a custodian to limit access, use and retention and restrict disclosure to defined parties. | The commitments you make to data subjects: principally the privacy notice you publish and the choices you offer, alongside applicable law. |
| Who the promise runs to | The counterparty that gave you the information — a customer, partner or licensor with a signed agreement. | The individual the information is about, who usually has no contract with you and may not know you exist. |
| What the auditor tests | That confidential information is identified and designated when received or created, that a retention period is set, that it is protected for that period, and that it is destroyed once the period ends. | The whole lifecycle plus the relationship: notice versions, consent and its scope, collection limits, purpose limitation, retention and disposal, access and correction, disclosure records, breach notification, data quality, complaints and monitoring. |
| Populations that have to exist before you can be tested | Records reaching end of retention; contracts terminated with return-or-destroy obligations; designation decisions; media and asset disposals. | Notice versions; consents captured and withdrawn; access, correction and deletion requests; authorised and unauthorised disclosures; vendors with access to personal information; complaints. |
| Readiness effort from a standing start | Weeks, where a retention schedule and a working deletion mechanism already exist. The effort is documentation and proof rather than new machinery. | A quarter or more, because most of the evidence is a records layer that must run for the whole observation period before anything can be sampled from it. |
One word in C1.1 carries most of the weight: designated. The criterion is that the entity identifies and maintains confidential information, and its points of focus describe procedures that designate confidential information when it is received or created and determine the period over which it is retained. Sensitivity is not the test. Information you consider sensitive but never designated, with no retention period attached, is not confidential information for the purposes of this category — and conversely, dull operational data covered by a confidentiality clause is. The retention period is the second half, and it is the half most teams have not written down: C1.2 asks you to dispose of confidential information, which is unanswerable until something defines when a record has reached the end of its life.
The most common scoping error
Processing personal data does not require Privacy
The trust services criteria are explicit that a service organisation may function as a data processor for its business-to-business customers, who in turn function as data controllers — and the 2022 revision went to the trouble of tagging each privacy point of focus as likely relevant to a processor, a controller, or both. Read those tags and the shape of the problem becomes obvious. Every point of focus under notice (P1.1) and under choice and consent (P2.1) carries the controller marker and nothing else. The processor marker appears on its own in only three places in the whole P-series — the same point of focus, responding to data controller requests, sitting under access (P5.1), correction (P5.2) and accounting (P6.7). That is the shape of a processor’s privacy obligations under these criteria: three points of focus of your own, and fifteen criteria answered by pointing at someone else.
You act only at a customer’s direction
You hold personal information because a business customer sends it to you and tells you what to do with it. The glossary calls this a data processor. You have no privacy notice for those individuals, you take no consent from them, and you do not decide the purpose. The information is confidential information you hold under contract — Confidentiality is normally the correct category, and Privacy adds eighteen criteria you can only answer with “we act on the controller’s instruction”.
You decide purposes for your own data subjects
You run a consumer product, you publish your own privacy notice, you capture consent and preferences, and you decide what the data is used for. That makes you a data controller in the glossary’s terms, and the privacy criteria describe your actual operations rather than someone else’s. This is where the Privacy category earns its cost.
You are both, on different data
Most B2B companies are: processor for the customer data inside the product, controller for the applicant tracking system, the CRM, the marketing automation platform and corporate website analytics. That is a boundary question before it is a category question, and a system description settles it in one sentence — “The system described is the [Product] production environment. Corporate IT systems, including the applicant tracking system, CRM and marketing automation platform, are not part of the system described.” The exclusion fails in exactly two situations: where those systems hold information about individuals whose data also sits inside the described service, and where a control in the described system depends on one of them — an offboarding workflow driven out of the HR system pulls the HR system across the line with it. Draw the boundary first and write that sentence; the category question usually answers itself once you have.
There is a further release valve, and it is in the standard rather than in anyone’s interpretation of it. The criteria state that for each category addressed, all criteria for that category are usually addressed, but that in limited circumstances a particular criterion may not be relevant to the services provided and is therefore not applicable to the engagement — and the illustration they give is a privacy one: criterion P3.1, on collection, is unlikely to be applicable for a service organisation that does not directly collect personal information from data subjects. That single sentence tells you how a pure processor sits inside this category: awkwardly. Scoping Privacy in order to answer a processor’s obligations means buying eighteen criteria to use a handful, while the obligations you genuinely carry — designation, protection, retention, destruction — are the two criteria in the other category.
Triggers
Which category the situation actually calls for
Scope is management’s decision, not the auditor’s — a CPA firm that chose your categories would be reporting on its own work. Use the table as a starting position for that decision, then test it against your actual agreements. “Not triggered” means the situation alone does not call for the category; a contract can always add one.
| Situation | Confidentiality | Privacy | What actually drives it |
|---|---|---|---|
| Customer data held under an MSA with a confidentiality clause and a return-or-destroy term | In scope | Not triggered | A designation plus a disposal obligation is precisely what C1.1 and C1.2 test. The data type is irrelevant to the trigger. |
| You process employee or customer records for business customers under a data processing agreement | In scope | Not by itself | The DPA designates the information and restricts its use — a confidentiality commitment. You made no promise to the individuals. |
| An enterprise security exhibit names “SOC 2 Type 2 covering Security and Confidentiality” | In scope | Not triggered | The contract names the category. This is the single most common legitimate reason Confidentiality appears in a scope. |
| You publish a privacy notice to individuals who use your product directly | Often also in scope | In scope | A published notice is a commitment to data subjects, and P1.1 tests whether you kept it and versioned it. |
| You capture consent, marketing preferences or opt-outs from individuals | Depends on contracts | In scope | Choice and consent (P2.1) and explicit consent (P3.2) only exist where you are the one asking. |
| You acquire personal information from third-party sources and decide its use — enrichment, scoring, advertising | In scope | In scope | You determine purposes without a direct relationship, which is where P3.1, P4.1 and the P6 disclosure series bite hardest. |
| The buyer’s questionnaire asks whether you encrypt personal data in transit and at rest | Not triggered | Not triggered | Neither. Encryption and access restriction sit in the common criteria — the CC6 series, including CC6.1 and CC6.7 — which every SOC 2 already carries. |
| You hold customer source code, pricing models or unreleased roadmaps | In scope | Not triggered | No personal information is involved, which is the clearest demonstration that Confidentiality is not a privacy control set. |
| Health information held under a business associate agreement | In scope | Only if you commit directly to individuals | The BAA designates the information and imposes disposal terms. HIPAA obligations run alongside the examination and are not what the criteria measure. |
| Contract termination triggers a customer request for certified deletion | In scope | Not triggered | This is C1.2 in one sentence: identify what has reached end of retention, destroy it, and hold the record. |
| You hold only your own employee data, CRM records and website analytics | Not triggered | Not triggered | That is your corporate privacy programme. Unless those systems sit inside the described system boundary, they are outside the examination entirely. |
Where the obligation comes from
The contract is the trigger, not the data
Scoping conversations improve enormously the moment someone opens the agreements. Three sentences decide the Confidentiality question, and they are usually all in the master services agreement rather than the security exhibit. First, the designation clause — what the agreement calls confidential information, and whether the definition is broad enough to sweep in everything you actually hold. Second, the retention term — how long you may keep it after the purpose ends, which is the clock C1.1 asks you to set and C1.2 asks you to act on. Third, the return-or-destroy clause, including whether the customer must elect, how long they have, and whether you owe a certification. If those three exist, you have a confidentiality commitment that a reader can test, and the category belongs in scope whether or not a buyer has asked for it.
“Supplier shall provide a SOC 2 Type 2 report covering the Security and Confidentiality trust services categories, and shall certify destruction of Customer Data within thirty (30) days of termination.”
— the clause that settles the Confidentiality question, and sets the deadline the auditor will later test against
The Privacy triggers are different in kind, because they are things you did rather than things you signed. A published privacy notice is a commitment to individuals. A consent flow, a preference centre, an unsubscribe mechanism, a rights request form, a stated retention period on a marketing database — each is a promise made to a data subject, and each maps to a criterion that can be tested. Where the commitments run to individuals who deal with you directly, Privacy is doing real work. Where they run only to business customers who then face their own data subjects, you are describing someone else’s privacy programme.
One caution on regulatory triggers. The trust services criteria acknowledge that confidentiality requirements may sit in laws or regulations as well as in contracts, so a statutory duty of confidence can put the category in scope on its own. That is not the same as a privacy statute obliging you to scope the Privacy category — no data protection law requires a SOC 2 at all, let alone a particular category within one. The obligation you are scoping against is always the commitment, and the law matters here because it creates commitments, not because it names the report. Where you also need to demonstrate the boundary of all this, scope and system boundary is the companion decision.
Worked example
One company, two scopes, twelve months
An illustrative scenario rather than a client: a 60-person B2B analytics platform, 340 enterprise customers, all data supplied by those customers under a master services agreement and a data processing agreement. The observation period ran 1 October 2024 to 30 September 2025. No consumer relationship exists; the only individuals in the system are the customers’ own employees and end users.
Scope as set
Security + Confidentiality
The common criteria plus C1.1 and C1.2. Four controls carry the C series: designation on onboarding, the retention schedule mapped to contract clauses, the monthly deletion run, and the termination workflow with its 30-day certification.
Populations
3 that matter
41 terminations in the period carrying return-or-destroy obligations; 12 monthly deletion runs; 6 physical media disposals. Each is small, each is enumerable from a system, and each existed before the period opened.
Fieldwork
24 items tested
15 of the 41 terminations inspected against the 30-day deadline, 3 of the 12 monthly deletion runs, and all 6 disposal certificates — 24 items in total, because a population of 6 is taken whole rather than sampled. One termination was actioned on day 34: an exception, disclosed in Section 4 with management’s response in Section 5.
Readiness effort
≈ 4 weeks
Almost all of it documentation: writing the retention schedule against the clauses, wiring the deletion job to emit a record, and adding the certification step to the offboarding template.
Now change one thing. In April 2025 — month seven — a prospect’s procurement team demands the Privacy category, and the company agrees before anyone checks what it means. The examination immediately has eighteen new criteria whose evidence must cover the same period that began the previous October. The privacy notice was rewritten twice and prior versions were not retained, so nobody can show which notice was in force when a given consent was taken. Consent is a boolean column with no scope and no version. Fourteen access requests were handled in the period, all forwarded by customers, all tracked in a shared inbox with no received or completed timestamps. Three vendors have access to personal information and none has executed privacy commitments. There is no disclosure register and no privacy complaints log distinguishable from general support.
None of that is fixable inside the period. Months one to six are closed and the evidence for them was never generated. A Type 2 opinion covers a single stated period for every category in scope, which leaves three options rather than the two most teams are offered.
Option A
Slide the period
Move the observation period so that it starts late enough for privacy evidence to exist. Technically clean and commercially expensive: the report the sales team was waiting for moves with it, and the deal that triggered the request is the first casualty.
Option B
Defer Privacy
Issue Security and Confidentiality for the stated period and elect Privacy from day one of the next one. The cheapest answer and the most common. The prospect gets a named start date instead of an assurance.
Option C
Privacy-scope Type 1
Issue a Privacy-scope Type 1 as of 30 September 2025 alongside the Security and Confidentiality Type 2 for the period ending the same day. A Type 1 reports on suitability of design as of a specified date, so the retroactive-evidence problem does not arise.
Option C is the one most teams have never been offered, so it is worth stating exactly. A Type 1 examination reports on the suitability of the design of controls as of a specified date; a Type 2 reports on operating effectiveness throughout a period. Both are examinations under AT-C section 205, and nothing prevents a service organisation from obtaining one of each. A Privacy-scope Type 1 dated 30 September 2025 can therefore be issued alongside the Security and Confidentiality Type 2 for the period ending that day, with the Type 2 running from 1 October 2025 picking up Privacy operating effectiveness. Three limits, stated plainly. It reports on design only, so it says nothing about whether anything operated. Most enterprise reviewers treat a Type 1 as a waypoint rather than an answer, and some security exhibits name Type 2 explicitly — read the clause before promising anything. And the whole P-series machinery still has to exist and be inspectable as of that date: versioned notices, scoped consent records, a request log, a disclosure register and executed vendor privacy commitments. A Type 1 removes the period requirement, not the build.
What Option B looks like in practice: issue Security and Confidentiality for the period ending 30 September 2025; spend that quarter building the records layer — versioned notices with a change history, consent scoped and tied to a version, a request case log with timestamps, privacy commitments obtained from the three vendors, a disclosure register and a complaints log; then run the second observation period from 1 October 2025 with Privacy in scope from day one. The prospect gets a named start date rather than an assurance, and the second report covers a full year rather than a partial period. Sequencing is not a delay tactic here — it is the only order in which the evidence can exist.
Evidence
What the CPA firm actually requests
That example was cheap for one reason: its populations were small, enumerable and already running before the period opened. Generalise it and the pattern holds — counting criteria understates the gap between these two categories. The measure that predicts cost is how many complete populations you can produce on request — every occurrence, in the period, of the thing a control acts on. Confidentiality asks for three or four. Privacy asks for closer to a dozen, and most of them are records rather than system logs. Criterion by criterion, this is what lands in the request list.
| Criterion | Population the auditor defines | Artefacts requested | What gets rejected |
|---|---|---|---|
| C1.1 | Categories of confidential information in the described system, and designation decisions made during the period — new customers onboarded, new data types ingested. | The classification or data-handling standard that names what is confidential; a retention schedule mapped to the clauses that impose it; onboarding records showing designation was applied; the register of agreements carrying confidentiality terms. | A classification policy with no register behind it. A retention schedule with no clause reference. “All customer data is treated as confidential” with nothing showing anyone applied it. |
| C1.2 | Every record, dataset, contract or asset that reached the end of its retention period during the observation period. | Deletion job output with record counts and timestamps; offboarding tickets showing deletion against the contractual deadline; certificates of destruction for physical media; a documented exception list for anything not deleted, with reasons. | A deletion policy with no execution. Deletion in the primary store with nothing said about backups, log archives, the warehouse or downstream SaaS. A destruction certificate dated after the contractual deadline. |
| P1.1 | Every version of the privacy notice in force during the period, and every change made to it. | Dated notice versions with a change history; evidence of how changes were communicated and when; evidence that prior versions were retained — a point of focus the 2022 revision states explicitly. | A live privacy page with no version history — the notice in force on the date of any given consent then becomes unprovable, which takes P2.1 down with it. |
| P2.1, P3.2 | Consents captured, refused and withdrawn during the period, plus the documented basis for any implicit consent. | Consent records tied to a notice version and a purpose scope; the withdrawal path and records of withdrawals honoured downstream; documentation of the basis for determining implicit consent. | A boolean consent flag with no scope and no version. Consent recorded after collection. A withdrawal that stops the emails but leaves the data in the analytics warehouse. |
| P4.2, P4.3 | Personal information reaching end of retention; deletion requests actioned during the period. | Retention rules per data category; deletion job output; evidence that disposal reached secondary stores; redaction records where full deletion was not possible. | Retention promised in the notice but not implemented in the system. Disposal evidenced only for the primary database. A retention period expressed as “as long as necessary” with no operative rule. |
| P5.1, P5.2 | Access and correction requests received in the period — including, for a processor, requests forwarded by the controller, which the criteria address through a dedicated point of focus. | A case log with received and completed timestamps, the identity-verification step, what was provided, and the recorded reason for any denial together with how the denial was communicated. | A request log with outcomes but no dates. Verification asserted but not evidenced. Denials with no recorded reason. Cases tracked in a shared inbox that cannot produce a complete population. |
| P6.2, P6.3 | Authorised disclosures of personal information to third parties; detected or reported unauthorised disclosures, including breaches. | A disclosure register that is complete, accurate and timely, carrying recipient, purpose, date and authority; incident records for unauthorised disclosure showing detection and reporting dates. | A disclosure register assembled during fieldwork. Incidents that live in a chat thread. A register that omits routine disclosures on the basis that “those ones are normal”. |
| P6.4, P6.5 | Vendors and other third parties with access to personal information during the period. | Executed privacy commitments per vendor; the periodic and as-needed assessment of their compliance, with dates and results; commitments obtained to notify you of actual or suspected unauthorised disclosure; corrective action where it was needed. | A vendor inventory with no privacy commitments obtained. An assessment performed once, after the period ended. Terms signed with a parent entity but not the sub-processor actually holding the data. |
| P6.6, P6.7 | Breaches and incidents requiring notification; requests for an accounting of personal information held and disclosed. | The determination of reporting requirements for each incident; notifications sent, with dates and recipients; accountings provided on request. | Nothing, if the population is genuinely nil — but expect the auditor to confirm that it is nil and then test the design of the determination step. A playbook that has never been exercised, in either a live incident or a documented tabletop, is a weak answer. |
| P8.1 | Inquiries, complaints and disputes from data subjects and others received during the period; the compliance monitoring performed. | A complaints log carrying receipt, resolution and communication dates; monitoring output showing instances of non-compliance and the corrective action taken, with timeliness visible. | A support inbox offered as a complaints log with no way to isolate privacy complaints. Monitoring described as ongoing with no output. Corrections made with no record of when the issue was identified. |
Sample sizes
What each control costs you in items
No published rule sets these numbers. They reflect the service auditor’s professional judgement in an examination performed under AT-C sections 105 and 205, and they differ between firms, so treat them as a planning shape rather than a quotation. What the shape shows is where each category’s effort actually sits.
| Control frequency | Population over a 12-month period | Sample commonly drawn | Instance from these two categories |
|---|---|---|---|
| Annual | 1 | 1 | The periodic review of the privacy notice under P1.1; the annual review of confidential-information categories under C1.1. One deviation is a 100 per cent deviation rate. |
| Quarterly | 4 | 2 | The vendor privacy-commitment assessment under P6.4. Some firms take all four where the control is the only one addressing the criterion. |
| Monthly | 12 | 2–4 | The scheduled deletion run that clears records past retention under C1.2 and P4.3. |
| Weekly | 52 | 5–9 | The retention-queue review that flags records approaching end of life under C1.1. Selections are spread across the period rather than clustered in one quarter. |
| Small population — under roughly 25 | Every occurrence — 14 access requests in the worked example above | Tested in full, or close to it | Data-subject access and correction requests under P5.1 and P5.2 where request volume is low. Below about 25 items, sampling stops saving anyone effort and firms commonly take the whole population. |
| Event-driven, moderate volume | 25–60 — 41 terminations in the worked example above | 12–15 | Return-or-destroy actions performed on contract termination under C1.2. This draws a heavier proportion than population size alone would suggest, because the control carries a contractual deadline and produces a deliverable the customer sees. |
| Event-driven, high volume | 60 to several hundred requests | 25–40 | Data-subject access, correction and deletion requests under P5.1, P5.2 and P4.3 in a consumer product with a live preference centre. |
| Nil population | 0 | Design only | Breach notifications under P6.6 in a period with no reportable incident — the auditor confirms the population is nil, then tests the design of the determination step. |
Two patterns are worth carrying into the scoping workshop. The Confidentiality populations are small and event-driven — terminations, disposals, records ageing out — which makes them cheap to enumerate but unforgiving, because a population of 41 with one missed deletion is an exception rate a reader can compute. Small is not the same as cheap, either: below roughly 25 items most firms stop sampling and take the whole population, so six media disposals means six certificates inspected, not two. The Privacy populations are wide and continuous, and their failure mode is not a missed item but a population nobody can produce at all. An auditor who cannot satisfy themselves that a population is complete does not reduce the sample; they raise the question of whether the control can be tested. How those numbers are actually derived — completeness of the population export, deviation rates, and what happens when a selection fails — is covered in sampling and sample sizes.
The artifact
How the category appears in the report itself
A category selection is not a badge, and no cover page settles it. It surfaces in three places inside the report, and a reviewer verifying a vendor’s claim reads those three rather than the marketing page that sent them looking.
One. The scope paragraph of the opinion. Section 1 is the independent service auditor’s report, and its scope paragraph names the trust services categories the examination covered, alongside the period it covered them for. That sentence is where a category claim is either true or not.
“… whether the controls stated in the description were suitably designed and operated effectively throughout the period 1 October 2024 to 30 September 2025 to provide reasonable assurance that the Company’s service commitments and system requirements were achieved based on the applicable trust services criteria for security and confidentiality set forth in TSP section 100 …”
— illustrative wording; firms phrase it differently. What does not vary is that the categories are named here, in the same sentence as the period.
Two. Management’s assertion, and what the description has to disclose. Section 2 is management’s written assertion, and it has to cover the same categories the opinion covers — assertion, description and opinion move together, so you cannot assert Security and Confidentiality and receive an opinion that includes Privacy. Electing Privacy also changes Section 3. The description criteria in DC section 200 require the system description to disclose the principal service commitments and system requirements, and with Privacy in scope your published privacy notice becomes one of them. It stops being marketing copy the moment it is named there: it is a commitment inside a document the service auditor reads against your evidence, and a promise in the notice that your retention rule cannot deliver is an exception waiting to be written up.
Three. The test rows in Section 4. This is where categories become countable. Every row carries the criterion addressed, the control activity, the test the service auditor performed, and the result. Two specimen rows built from the worked example above show why it is the part to read: the first is a control that was tested, the second is a control that would not have been testable had Privacy been in scope.
| Criterion | Control activity | Test performed by the service auditor | Result |
|---|---|---|---|
| C1.2 | Customer Data is deleted within 30 days of contract termination and a certificate of destruction is issued to the customer. | Selected 15 of 41 terminations occurring in the period; inspected deletion job output and the destruction certificate, and compared the completion date to the contractual deadline. | Exception noted. For one selection, deletion was completed on day 34. |
| P5.1 — not in scope | Data subject access requests forwarded by a customer are logged on receipt, the requester’s identity is verified with the customer, and a response is provided within the contractual window. | Would have required the complete population of access requests for the period, then inspection of the received and completed timestamps, the verification step and the response provided for each selection. | Not tested — Privacy was not in scope for this period. Had it been, the 14 requests lived in a shared inbox with no received or completed timestamps, so the population could not be evidenced and the control could not have been tested. |
With those three places in mind, verifying a vendor takes about ninety seconds. The opinion paragraph names the categories; the assertion names the same ones; Section 4 carries criterion references you can count. A report whose Section 4 contains no P-series rows does not have Privacy in scope whatever the sales deck says — and C-series rows describing a policy rather than a tested population tell you something as well. The full walk-through is in how to read a SOC 2 report and the anatomy of the report.
Law
Neither category is GDPR or DPDP compliance
Read the privacy criteria in sequence and the same reference anchors every one of them: the entity’s objectives related to privacy. Most are phrased as doing the thing to meet those objectives; P3.1 has personal information collected consistent with them; P4.1 limits use to the purposes identified in them. The wording moves, the anchor does not. That is a deliberate design choice — it lets one criteria set work across jurisdictions — and it means the opinion is silent on whether those commitments were legally sufficient in the first place. A SOC 2 with Privacy in scope confirms you did what you said. It cannot confirm that what you said satisfies a statute.
“Are you a safe processor of the personal data we send you?”
A SOC 2 covering Security and Confidentiality answers this well: access restriction, transmission controls, designation of the data as confidential, a retention period and evidenced disposal. Pair it with a signed data processing agreement carrying the contractual terms your counsel requires.
“Are you GDPR compliant?” / “Are you DPDP compliant?”
No attestation answers this, and neither does a certification. Legal compliance turns on lawful basis, transfer mechanisms, records of processing, impact assessments and statutory notification deadlines — none of which the trust services criteria evaluate. An ISO 27701 privacy information management system, certified alongside ISO 27001 rather than on its own, gives you a structured privacy management system and a documented route from its controls to GDPR obligations, which shortens the legal assessment. It is not itself a finding of compliance — no ISO scheme is an approved certification mechanism under GDPR Article 42 — and there is no equivalent recognised mapping for the DPDP Act. The compliance conclusion comes from a privacy programme assessed against the statute, with counsel behind it.
“Do you actually keep the promises in your privacy notice?”
This is the question the Privacy category was built for, and it is the only one it answers directly. A clean Type 2 opinion with Privacy in scope says an independent CPA firm tested whether your stated privacy commitments operated as described throughout the period. A Type 1 with Privacy in scope says something narrower — that the controls were suitably designed as of a date.
“Does your SOC 2 cover the obligations in our data processing agreement?”
Partly, and the split is worth stating precisely rather than hedging. What a Security and Confidentiality report does evidence for a DPA: restriction of access to the data (the CC6 series), transmission and removal controls (CC6.7), designation of the data as confidential (C1.1), a retention period tied to the agreement, evidenced deletion on termination (C1.2), and management of risks arising from vendors and business partners (CC9.2). What it does not evidence: lawful basis, a cross-border transfer mechanism, records of processing, impact assessments, and statutory notification clocks. Send the report for the first list, and the executed DPA plus your privacy programme for the second.
The P-series against the instruments people confuse it with
This is the table every vendor-risk reviewer wants and almost nobody publishes honestly. It is directional orientation for a scoping conversation, not a certified mapping: read the fourth column before you read anything else.
| Privacy criterion series | What the SOC 2 criterion tests | Nearest ISO 27701 / statutory concept | Does the opinion cover the legal obligation |
|---|---|---|---|
| P1 — Notice | That notice is provided to data subjects about your privacy practices, updated and communicated in a timely way when those practices change, and that prior versions of the notice are retained. | ISO 27701 handles this under obligations to PII principals — determining what information they are given and providing it. Statutory analogue: the transparency and notice duties, GDPR Articles 13 and 14, and the notice a data fiduciary must give before seeking consent under the DPDP Act. | No — commitment only |
| P2 — Choice and consent | That available choices and their consequences are communicated, that explicit consent is obtained where required and only for the intended purpose, and that your basis for determining implicit consent is documented. | ISO 27701 conditions for collection and processing — identifying the lawful basis, determining when and how consent is obtained, and recording it. Statutory analogue: consent as a lawful basis, GDPR Articles 6 and 7, and the consent architecture of the DPDP Act. | No — commitment only |
| P3 — Collection | That personal information is collected consistent with your privacy objectives (P3.1), and that where explicit consent is required, the need and the consequences of refusing are communicated and consent obtained before collection (P3.2). | ISO 27701 privacy by design and privacy by default — limiting collection to what the purpose needs. Statutory analogue: collection limitation and purpose specification, GDPR Article 5(1)(b) and 5(1)(c). | No — commitment only |
| P4 — Use, retention and disposal | That use is limited to the purposes identified in your objectives (P4.1), that retention is consistent with them (P4.2), and that disposal is secure (P4.3). | ISO 27701 privacy by design and privacy by default — limiting processing, retention periods, de-identification and disposal. Statutory analogue: purpose limitation and storage limitation, GDPR Article 5(1)(b) and 5(1)(e), and the erasure duty on a data fiduciary once the purpose is served. | No — commitment only |
| P5 — Access | That identified and authenticated data subjects can access their stored personal information and obtain copies, that corrections are made and passed to third parties, and that denials are communicated with reasons. Processor-side, that requests forwarded by a data controller are handled. | ISO 27701 obligations to PII principals — access, correction and erasure, providing a copy, and handling requests. Statutory analogue: data subject rights, GDPR Articles 15 to 22, and the DPDP rights of access and of correction and erasure. | No — commitment only |
| P6 — Disclosure and notification | Explicit consent before disclosure; complete, accurate and timely records of authorised and of unauthorised disclosures; privacy commitments obtained from vendors and third parties with an assessment of their compliance; commitments from them to notify you of actual or suspected unauthorised disclosure; notification of breaches to affected data subjects, regulators and others; and an accounting of personal information held and disclosed, on request. | ISO 27701 PII sharing, transfer and disclosure, together with its processor and sub-processor provisions. Statutory analogue: processor and sub-processor obligations, GDPR Article 28; breach notification, GDPR Articles 33 and 34; and the breach-intimation duty under the DPDP Act. | No — commitment only |
| P7 — Quality | That the personal information you collect and maintain is accurate, up to date, complete and relevant for the purposes it is used for. | ISO 27701 privacy by design and privacy by default — accuracy and quality. Statutory analogue: the accuracy principle, GDPR Article 5(1)(d), and the data fiduciary duty to ensure completeness, accuracy and consistency where the data is used for a decision or disclosed. | No — commitment only |
| P8 — Monitoring and enforcement | That a process exists for receiving, addressing, resolving and communicating the resolution of inquiries, complaints and disputes; that compliance is periodically monitored; and that identified deficiencies are corrected in a timely manner. | The management-system spine ISO 27701 inherits from ISO 27001 — internal audit, management review, nonconformity and corrective action. Statutory analogue: accountability, GDPR Articles 5(2) and 24, and the grievance-redressal right under the DPDP Act. | No — commitment only |
Two cautions about that table, and they matter more than the rows. It is orientation, not a legal mapping: no ISO scheme is an approved certification mechanism under GDPR Article 42, and there is no recognised mapping from either ISO 27701 or the trust services criteria to the DPDP Act — the DPDP references above name the nearest concept, nothing more. And the fourth column reads identically in all eight rows for a structural reason rather than a cautious one. Every privacy criterion is met against your objectives related to privacy, so the strongest thing the opinion can ever say is that you kept the commitment you made. Whether that commitment was legally sufficient is a question for counsel, working from the statute rather than from a report.
The practical consequence for a vendor-risk conversation is that the report is strong evidence inside a compliance story and weak evidence as a substitute for one. It supports a controller’s due diligence on its processors, and it demonstrates that security and disposal obligations operate. It does not establish a lawful basis, produce a record of processing, satisfy a transfer mechanism, or replace an impact assessment. If those are the gaps, the instruments are an ISO 27701 privacy information management system — certified alongside ISO 27001 rather than standalone — on the management-system side, and a privacy programme assessed against the statute, with counsel behind it, on the legal side. For Indian obligations specifically, see data privacy laws in India and what a data fiduciary is.
Failure modes
What happens when Privacy goes in too early
Adding a category is the one-way door: the evidence has to have existed from day one of the period, and no amount of effort in month ten reaches back. Removing one is possible — it costs you the scope you promised, and a conversation with the prospect who asked for it. These are the six ways an early Privacy election turns into a problem, in roughly the order they surface.
01The evidence cannot be created after the fact
Retained prior notice versions, consent tied to the version in force, request timestamps, a disclosure register kept contemporaneously — every one of these is dated by nature. Nothing you build in month ten produces evidence for month two, and reconstructed evidence is not accepted as a substitute for contemporaneous records.
02Exceptions cluster in the disclosure series
P6.1 through P6.7 is seven of the eighteen criteria and covers consent for disclosure, the register of authorised disclosures, the register of unauthorised ones, vendor privacy commitments, vendor notification commitments, breach notification, and accountings on request. Programmes that fail on Privacy usually fail here, because this is the part nobody was keeping records for.
03Vendors have to be re-papered on the auditor’s timetable
P6.4 and P6.5 require commitments obtained from third parties with access to personal information, and an assessment of their compliance. Renegotiating terms with a payment processor or an offshore support vendor mid-period is not a compliance task, it is a commercial one, and it moves at the vendor’s speed rather than yours.
04The description becomes testable text
The description criteria in DC section 200 require the system description to disclose the principal service commitments and system requirements. Scope Privacy and your privacy notice is no longer marketing copy — it is a commitment inside a document the auditor reads against the evidence.
05Scope creeps past the product
Confidentiality is bounded by the agreements covering the described system. Privacy follows personal information, and personal information is in your applicant tracking system, your CRM and your marketing platform. If those data subjects fall inside the described boundary, those systems come with them.
06The qualification does not stay in its lane
A modified opinion caused by the P-series appears in Section 1, which is the first page every reviewer reads. Commercially, buyers do not parse which category caused it — they see a report that is not clean. Deferring Privacy by one period is almost always cheaper than a qualified opinion you then have to explain in every deal for a year.
The remedy in every case is sequencing rather than heroics. Scope Security and Confidentiality now, build the privacy records layer while that report is being produced, and elect Privacy for the next period with a start date you can put in writing. A vendor that says “Privacy is in scope from 1 October, here is the notice-versioning and request-logging we stood up in September” reads as a mature programme. A vendor with privacy exceptions scattered through Section 4 does not.
Contested ground
Where the line between the two actually blurs
Information that is confidential and personal at the same time
This is the normal case, not an anomaly — the AICPA states plainly that confidential information may include personal information as well as trade secrets and intellectual property. Nothing forces you to scope both categories because a record falls in both. Scope on the obligation you actually carry: a contract restricting use and requiring destruction points to Confidentiality; commitments made to the individuals point to Privacy.
Deletion that reaches the primary store and nothing else
The most frequent exception under C1.2 and P4.3 by a wide margin. Records are removed from the application database and remain in nightly backups, log archives, the analytics warehouse, a support tool and two downstream SaaS products. Decide the position before the period opens — a documented, defensible backup-expiry position is testable; silence is an exception.
Return-or-destroy where the customer never responds
The contract usually says return the data or destroy it at the customer’s election. Where the customer goes quiet, an unmanaged account sits past its retention deadline and lands in the C1.2 population as a failure. The fix is procedural: a defined election window, a documented reminder, and a default action on expiry — evidenced each time.
Training models on customer data
Two different questions, and teams routinely answer only one. Under Confidentiality, does your agreement permit that use of designated information at all? Under Privacy, P4.1 limits use of personal information to the purposes identified in your objectives, which for most organisations means the purposes in the published notice. A use that the contract permits and the notice never mentioned is a privacy exception, not a legal one.
Sub-processors, carve-outs and CUECs
Where a subservice organisation is carved out, its controls sit outside the opinion and the description must say so — but P6.4 still asks whether you obtained privacy commitments from parties with access to personal information, and that obligation is yours regardless of method. Confidentiality behaves the same way: carving out the hosting provider does not carve out your obligation to designate and dispose.
A criterion that genuinely does not apply
The trust services criteria allow it in limited circumstances — where a particular criterion is not relevant to the services provided by a service organisation — and the illustration they give is a privacy one: criterion P3.1, on collection, is unlikely to be applicable for a service organisation that does not directly collect personal information from data subjects. It is not a loophole. The reasoning has to be documented, the service auditor has to agree with it, and it appears in the report where readers can see which criteria were covered.
“We do not do that point of focus”
Points of focus are not criteria. The trust services criteria state that using them does not require an assessment of whether each point of focus is addressed, and that some may not be suitable or relevant. The 2022 revision went further for privacy, tagging points of focus as likely relevant to a data processor, a data controller, or both. Arguing about a point of focus you do not meet is usually the wrong argument; the criterion is what must be met.
Is the marketing website inside the boundary?
For a B2B platform the described system is normally the production service, not the corporate site. Cookie banners, form fills and visitor analytics then sit outside the examination — which is why a Privacy scope justified entirely by website tracking is usually a boundary error wearing a category costume.
Handling the pushback
When your category choice surprises the reviewer
Most of these are answerable in one exchange if you know what the reviewer is actually asking. The pattern that works is to convert a category demand into a commitment question: which promise do you need assured, and to whom was it made?
| What they say | What it usually means | What answers it |
|---|---|---|
| “Your report doesn’t include Privacy, so we can’t approve you.” | Their questionnaire has a Privacy checkbox and nobody has asked what it is for. | Ask which privacy commitment they need assured. If the answer concerns data they send you, Confidentiality plus the common criteria is the correct assurance and the DPA carries the legal terms. If they genuinely need assurance over commitments you made to individuals, that is a real Privacy requirement and belongs in the next period with a named start date. |
| “You process personal data, so you need the Privacy category.” | They are equating a data type with a category. | The category follows the promise, not the data. As a processor acting on their instruction you have no notice, no consent and no purpose determination of your own — the P-series would be answered largely by pointing back at them. The obligations you actually carry are designation, protection and disposal, which is C1.1 and C1.2. |
| “Your competitor’s report has Privacy in scope.” | A comparison is being made without reading either report. | Offer the comparison they actually want: which criteria each report covers, what the opinion says, and which exceptions appear. A vendor that scoped Privacy and collected exceptions across the P6 series is not in a stronger position than one that scoped Confidentiality cleanly and can evidence deletion on demand. |
| “Confidentiality is only two criteria — that is not real coverage.” | Criteria are being counted instead of read. | Those two sit on top of all 33 common criteria, which is where access restriction, transmission controls and asset disposal already live. What C1.1 and C1.2 add is the thing buyers care about and rarely get: a designation procedure, a retention period tied to the contract, and evidenced destruction at the end of it. |
| “Prove you delete our data when we leave.” | The most reasonable request on this list. | This is C1.2, and it is testable. Show the retention schedule mapped to the clause in their agreement, the deletion mechanism, and the fact that the auditor sampled terminations in the period and inspected the deletion record for each one. |
| “So this means you are GDPR compliant?” | An attestation is being read as a legal conclusion. | No, and saying so plainly builds more trust than hedging. The criteria measure performance against your own stated commitments. Legal compliance is a separate assessment against a statute, and no attestation or certification substitutes for it. An ISO 27701 PIMS certified alongside ISO 27001 organises the privacy programme and shortens that assessment; the conclusion still comes from counsel reading the statute against what you actually do. |
Where TCSA fits: we run readiness, control implementation and the evidence layer, and we coordinate the examination — a fixed fee from $4,000 for early-stage startups, quoted after scoping, with the CPA firm’s attestation fee billed separately. The licensed CPA firm performs the examination and issues the report. TCSA never certifies, attests, audits or signs, and does not choose your categories for you — that decision is management’s, and it is the one this page exists to inform.
Frequently Asked Questions
What is the difference between Confidentiality and Privacy in SOC 2?
Confidentiality applies to information designated as confidential, of any kind — the AICPA definition is that information designated as confidential is protected to meet the entity’s objectives, and those objectives come from contracts, agreements or regulations. Privacy applies only to personal information, defined as information that is about, or can be related to, an identifiable individual, and it covers a full lifecycle: notice, choice and consent, collection, use, retention and disposal, access, disclosure and notification, quality, and monitoring and enforcement. Confidentiality is two criteria. Privacy is eighteen.
Do I need the Privacy category if my product processes personal data?
Usually not. The trigger is the commitments you made to data subjects, not the data type. If you hold personal information at a business customer’s direction, you are acting as a data processor: you publish no notice to those individuals, you take no consent from them and you do not determine the purpose. The trust services criteria even give the example of a criterion that is inapplicable in that position — criterion P3.1, on collection, is unlikely to be applicable for a service organisation that does not directly collect personal information from data subjects. The obligations you do carry are designation, protection and disposal, which is Confidentiality.
How many criteria does each category add?
Confidentiality adds two: C1.1, under which the entity identifies and maintains confidential information, and C1.2, under which it disposes of confidential information. Privacy adds eighteen across eight series — P1.1 notice; P2.1 choice and consent; P3.1 and P3.2 collection; P4.1 to P4.3 use, retention and disposal; P5.1 and P5.2 access; P6.1 to P6.7 disclosure and notification; P7.1 quality; and P8.1 monitoring and enforcement. Both sit on top of the 33 common criteria, CC1.1 through CC9.2, which every SOC 2 carries regardless of category selection.
Is Confidentiality worth adding if Security already covers encryption and access?
Yes, when a contract imposes retention and disposal duties, because that is exactly what the common criteria do not test. The CC6 series covers logical access, transmission restrictions and the discontinuation of protections over assets, so encryption and access control are already in every SOC 2. What C1.1 and C1.2 add is a designation procedure that classifies information on receipt or creation, a retention period attached to it, and evidenced destruction when that period ends. If your agreements contain return-or-destroy clauses, this is the category that proves you honour them.
Does a SOC 2 with the Privacy category mean we are GDPR compliant?
No. Every privacy criterion is written to be met against the entity’s own objectives related to privacy, so the opinion says you kept your stated commitments — not that those commitments satisfy a statute. Nothing in the examination establishes a lawful basis, produces a record of processing, validates a transfer mechanism or replaces an impact assessment. The report is strong supporting evidence for a controller performing due diligence on you, and it is not a legal conclusion. An ISO 27701 privacy information management system — certified alongside ISO 27001 rather than standalone — gives you a structured privacy management system and a documented route from its controls to GDPR obligations, which shortens the legal assessment without being a finding of compliance; no ISO scheme is an approved certification mechanism under GDPR Article 42, and there is no equivalent recognised mapping for the DPDP Act. The compliance conclusion comes from a privacy programme assessed against the statute, with counsel behind it.
What evidence does the auditor request for C1.1 and C1.2?
For C1.1: the classification or data-handling standard naming what is confidential, a retention schedule mapped to the clauses that impose it, and records showing designation was applied to new customers and new data types during the period. For C1.2: a population of everything that reached end of retention in the period, with deletion job output carrying record counts and timestamps, offboarding tickets evidencing deletion against the contractual deadline, and destruction certificates for physical media. The most common rejection is deletion evidenced in the primary store with nothing said about backups, log archives, the warehouse or downstream SaaS.
Can we add the Privacy category to an examination that has already started?
Rarely without cost. The opinion covers a single stated period for the categories in scope, and most privacy evidence is dated by nature — retained prior notice versions, consent tied to the version in force, request timestamps, a contemporaneous disclosure register. Adding Privacy in month seven means the first six months have no evidence and cannot acquire any. Three choices remain: move the period and delay the whole report; issue the current scope and elect Privacy from the start of the next period; or issue a Privacy-scope Type 1 as of the period end date alongside the Type 2, since a Type 1 reports on design as of a date and has no retroactive-evidence problem. The second is usually the better commercial outcome, and the third is the one most teams are never offered.
We are a processor and never speak to data subjects. What would the P-series even test?
Comparatively little, which is the point. The 2022 revision to the points of focus tags each one as likely relevant to a data processor, a data controller, or both, and every point of focus under notice and under choice and consent carries the controller marker alone. The processor marker appears unaccompanied in only three places across the whole P-series — the same point of focus on responding to data controller requests, sitting under access, under correction, and under accounting. You would be buying eighteen criteria to exercise a handful, while answering most of them by pointing back at your customer.
Can a criterion be marked not applicable?
In limited circumstances, yes. The trust services criteria state that all criteria for a category are usually addressed, but that where a particular criterion is not relevant to the services provided, it may not be applicable — with criterion P3.1, on collection, given as the illustration of one that is unlikely to be applicable for a service organisation that does not directly collect personal information from data subjects. It is not a way to trim a category you were not ready for. The reasoning has to be documented, the service auditor has to agree with it, and it is visible in the report to anyone reading the criteria coverage.
Which should a typical B2B SaaS company choose?
For most B2B platforms holding customer-supplied data under an MSA and a DPA: Security plus Confidentiality, with Privacy deferred until either a contract genuinely requires it or the company starts making commitments to individuals directly. That combination answers the questions enterprise reviewers actually ask — how is our data restricted, how long do you keep it, and can you prove you destroyed it — without buying eighteen criteria whose evidence layer does not exist yet. Where a real Privacy requirement appears, elect it for the next full period rather than mid-flight.
Can we get Privacy assurance faster than waiting a full period?
Sometimes, through a Type 1. A Type 1 examination reports on the suitability of the design of controls as of a specified date; a Type 2 reports on operating effectiveness throughout a period. Both sit under AT-C section 205, and a Privacy-scope Type 1 can be issued alongside a Security and Confidentiality Type 2 covering the same year, with Privacy operating effectiveness picked up in the following Type 2. Because design is assessed as of a date, the retroactive-evidence problem does not arise. The limits are real: it reports on design only; many enterprise reviewers treat a Type 1 as a waypoint rather than an answer, and some security exhibits name Type 2 explicitly; and the privacy machinery — versioned notices, scoped consent, a request log, a disclosure register, vendor privacy commitments — must exist and be inspectable on that date. A Type 1 removes the period requirement, not the build.
How do I verify which categories a vendor’s report actually covers?
Read three places, not the cover page. First, the scope paragraph of the independent service auditor’s report in Section 1: it names the trust services categories the examination covered and the period it covered them for. Second, management’s assertion in Section 2, which has to cover the same categories — the assertion, the description and the opinion move together. Third, Section 4, where every test row carries the criterion it addresses; count the references. A report whose Section 4 contains no P-series rows does not have Privacy in scope whatever the sales deck says, and C-series rows that describe a policy rather than a tested population tell you something too.
Related reading: choosing your trust services criteria, the five trust services categories, scope and system boundary, the SOC 2 controls list, sampling and sample sizes, subservice organizations, how to read a SOC 2 report, and the SOC 2 hub.
Written By Expert Auditors
Keep Exploring
Related Reading
Choosing Your Trust Services Criteria
Security is mandatory; the other four are driven by commitments you actually made — and Privacy costs more than teams expect.
Read moreTrust Services Criteria
Security, Availability, Confidentiality, Processing Integrity, Privacy.
Read moreDoes SOC 2 Make You GDPR or DPDP Compliant?
What SOC 2 genuinely supports in each regime, and the obligations it never touches.
Read morePIMS Framework Explained
How the Privacy Information Management System extends an ISMS.
Read moreSOC 2 Knowledge Hub
Type 1 vs Type 2, criteria, timelines and audit prep — all guides.
Read moreSOC 2 Scope & System Boundary
What may legitimately be excluded, and the DC 200 test that stops a boundary flattering the vendor.
Read moreGet in touch
Book a free consultation or send us your requirements. We respond within 24 hours.
Quick Call
Pick a time slot
Send Requirements
Get a custom quote in 24 hours