Learn · SOC 2 Scoping
Choosing Your
Trust Services Criteria
Security is in every SOC 2 examination. Availability, Confidentiality, Processing Integrity and Privacy are elective — and the only sound reason to add one is that you have made a commitment its criteria would evidence. Scoping is a contract question before it is a security question.
The test we apply: show me the clause. A category is earned by a sentence in an MSA, an SLA, a data processing agreement or a published notice — not by a feeling that the data is sensitive, and not by a competitor’s report listing five categories.
TSP section 100 · 2017 TSC with revised points of focus (2022) · DC section 200 · Last reviewed August 2026
Security — the common criteria — is present in every SOC 2 examination. Availability, Confidentiality, Processing Integrity and Privacy are elective, and each should be selected because a commitment exists that its criteria would evidence, not because the data feels sensitive or because a buyer used the word once on a call. The AICPA’s 2017 Trust Services Criteria (TSP section 100, reissued with revised points of focus in 2022) divides the criteria into criteria common to all five categories and additional criteria specific to availability, processing integrity, confidentiality and privacy. The common criteria are the complete set of control-activity criteria for Security; for the other four, a complete set is the common criteria plus that category’s additional criteria. Security is the floor, and the rest stack on top of it. Crucially, in a SOC 2 examination the “objectives” every criterion refers back to are the organisation’s commitments to its customers and its system requirements. That definition is what turns scoping from an opinion into a document review.
The shape of the standard
What you are actually choosing between
Five categories, but not five equal choices. Security is 33 criteria you take whether you want them or not. The other four add between two and eighteen criteria each, and that spread is the whole reason scoping conversations get expensive. All five together come to 61 criteria.
| Category | What the criteria address | What selecting it obliges you to evidence |
|---|---|---|
| SecurityThe common criteriaCC1.1–CC9.2 — 33 criteria | Information and systems are protected against unauthorised access, unauthorised disclosure of information, and damage to systems. | Nine series: control environment (CC1), communication and information (CC2), risk assessment (CC3), monitoring (CC4), control activities (CC5), logical and physical access (CC6), system operations (CC7), change management (CC8), and risk mitigation including vendor and business-partner risk (CC9). In every SOC 2; it has no additional category-specific criteria. |
| AvailabilityElectiveA1.1–A1.3 — 3 criteria | Information and systems are available for operation and use. The standard is explicit that this objective does not, in itself, set a minimum acceptable performance level, and does not address functionality or usability. | Monitoring and evaluation of processing capacity; environmental protections, backup processes and recovery infrastructure; and testing of recovery procedures. Backup configuration does not satisfy A1.3 — the test has to have happened inside the period. |
| ConfidentialityElectiveC1.1, C1.2 — 2 criteria | Information designated as confidential is protected from collection or creation through to final disposition. Information is confidential when the custodian is required to limit its access, use and retention and restrict disclosure to defined parties. | Identification and maintenance of confidential information (C1.1) and its disposal (C1.2). The criterion says only that; its point of focus — and what auditors ask for in practice — is a procedure that designates confidential information when it is received or created and sets the period over which it is retained. Two criteria; a disproportionate share of the evidence pain. |
| Processing IntegrityElectivePI1.1–PI1.5 — 5 criteria | System processing is complete, valid, accurate, timely and authorised. Usually addressed at the system or functional level rather than entity-wide. | Documented definitions of the data processed and the product or service specifications (PI1.1), then controls over inputs, processing, outputs and storage tested against them (PI1.2–PI1.5). Without a written specification there is nothing to test accuracy against. |
| PrivacyElective — and the largestP1.1–P8.1 — 18 criteria | Personal information is collected, used, retained, disclosed and disposed of to meet the entity’s objectives. Privacy applies only to personal information; confidentiality applies to sensitive information of every kind. | Notice (P1), choice and consent (P2), collection (P3), use, retention and disposal (P4), access and correction (P5), disclosure and breach notification (P6 — seven criteria alone), quality (P7), monitoring and enforcement (P8). More than three times the additional criteria of the next largest category: eighteen against five. |
A practitioner may report on any category individually or in combination, and for each category addressed, all of that category’s criteria are usually addressed — the standard allows a narrow exception where a particular criterion is genuinely not relevant to the services provided, covered below. There is no partial Privacy and no Confidentiality-lite. You take a category whole, or you leave it out and say why. One vocabulary note before the selection: SOC 2 is an attestation performed by a licensed CPA firm under the AICPA’s attestation standards — AT-C sections 105 and 205 — not a certification. There is no certificate with categories printed on it; the categories appear in the opinion, the assertion and the description.
The elective criteria
All twenty-eight, one by one
Scoping arguments usually happen at the level of category names, which is why they go in circles. Below the names, each category is a short list of specific obligations, and each obligation produces a population somebody has to be able to hand over. The middle column paraphrases what the criterion requires; the third is the kind of control organisations typically describe against it — market practice, not text from the standard; the fourth is what the service auditor will ask you to produce.
Availability — A series
| Criterion | What it requires | Typical described control | Population it creates |
|---|---|---|---|
| A1.1 | Maintain, monitor and evaluate current processing capacity and use of system components — infrastructure, data and software — to manage capacity demand and enable additional capacity. | Capacity and utilisation are reviewed against defined thresholds on a stated frequency, and threshold alerts are triaged to resolution. | Capacity reviews performed; capacity or utilisation alerts raised and closed. |
| A1.2 | Authorise, design, implement, operate, approve, maintain and monitor environmental protections, software, data backup processes and recovery infrastructure. | Backups run to a defined schedule with failure alerting and remediation; environmental protections at the hosting facility are monitored, usually through a subservice organisation. | Backup job executions across the period; backup failures and their remediation; changes to recovery infrastructure. |
| A1.3 | Test recovery plan procedures supporting system recovery. | A restore or failover test is performed at least annually against a documented scenario, and the result is recorded with date, scope, elapsed time and defects raised. | Recovery tests performed inside the period — frequently a population of one. |
Confidentiality — C series
| Criterion | What it requires | Typical described control | Population it creates |
|---|---|---|---|
| C1.1 | Identify and maintain confidential information to meet the entity’s objectives related to confidentiality. | Confidential information is designated when it is received or created and its retention period recorded — the criterion’s point of focus, and the control auditors ask for in practice. | Classification decisions made; data stores and flows brought into scope during the period. |
| C1.2 | Dispose of confidential information to meet the entity’s objectives related to confidentiality. | Records reaching end of retention are identified and deleted on a defined cycle; customer data is returned or destroyed inside the contractual window on termination. | Records reaching end of retention; terminations carrying return-or-destroy obligations; media and asset disposals. |
Processing Integrity — PI series
| Criterion | What it requires | Typical described control | Population it creates |
|---|---|---|---|
| PI1.1 | Obtain or generate, use and communicate relevant, quality information about processing objectives — including definitions of data processed and product and service specifications. | A versioned processing specification defines inputs, calculations, rounding, timing and outputs, and is approved before it changes. | Specification versions issued and approved during the period. |
| PI1.2 | Implement policies and procedures over system inputs, including controls over completeness and accuracy. | Inbound files and API payloads are validated against schema and business rules; rejects route to an exception queue with a named owner and a due date. | Input batches or files received; records rejected by validation. |
| PI1.3 | Implement policies and procedures over system processing so that products, services and reporting meet the entity’s objectives. | Processing runs are monitored to completion, failures alert, and reprocessing requires documented approval. | Processing runs executed; failed runs; reprocessing events. |
| PI1.4 | Implement policies and procedures to make available or deliver output completely, accurately and timely in accordance with specifications. | Output is reconciled to source before release and signed by a reviewer independent of the preparer; delivery timing is logged against the committed window. | Outputs delivered; reconciliations performed; late or amended deliveries. |
| PI1.5 | Implement policies and procedures to store inputs, items in processing and outputs completely, accurately and timely in accordance with system specifications. | Stored records are integrity-checked — row counts or checksums — and retained per specification, with storage exceptions alerting. | Integrity check runs; storage exceptions raised and cleared. |
Privacy — P series
| Criterion | What it requires | Typical described control | Population it creates |
|---|---|---|---|
| P1.1 | Provide notice to data subjects about privacy practices, and update and communicate that notice in a timely manner when practices change, including changes in the use of personal information. | The privacy notice is version-controlled; changes are approved, published with an effective date, and communicated to data subjects. | Notice versions published; change communications issued. |
| P2.1 | Communicate the choices available over collection, use, retention, disclosure and disposal and the consequences of each; obtain explicit consent where required; document the basis for determining implicit consent. | Consent is captured at the point of collection with the notice version, timestamp and scope recorded; withdrawal is honoured and recorded. | Consents captured; consents withdrawn. |
| P3.1 | Personal information is collected consistent with the entity’s privacy objectives. | Collection points are inventoried and reviewed against the notice; a new collection point requires privacy review before release. | Collection points added or changed. This is the criterion the standard itself names as potentially not applicable where the organisation does not collect directly from data subjects. |
| P3.2 | Where explicit consent is required, communicate the need for it and the consequences of refusal, and obtain the consent before collection. | A consent gate precedes collection in the flow, and the gate is tested at each release. | Collection events requiring explicit consent; releases affecting the consent gate. |
| P4.1 | Limit the use of personal information to the purposes identified in the entity’s privacy objectives. | Access to personal information is granted by purpose-based role; any secondary use requires documented approval. | Access grants to personal information; secondary-use approvals. |
| P4.2 | Retain personal information consistent with the entity’s privacy objectives. | Retention periods are configured per data category and enforced by a scheduled job rather than by intention. | Retention rules in force and changed; records reaching their retention limit. |
| P4.3 | Securely dispose of personal information. | Records past retention are deleted on a scheduled cycle and the deletion recorded with counts and dates. | Deletion runs executed; records deleted. |
| P5.1 | Grant identified and authenticated data subjects access to their stored personal information and provide copies on request; inform them of any denial and its reason. | Requests are logged on receipt, identity is verified, and a response is issued inside the committed window; denials record the reason. | Access requests received during the period. |
| P5.2 | Correct, amend or append personal information based on information provided by data subjects, communicate it to third parties as committed or required, and inform data subjects of any denial. | Correction requests run through the same case workflow, with downstream propagation recorded. | Correction requests received; downstream propagations performed. |
| P6.1 | Disclose personal information to third parties with the explicit consent of data subjects, obtained before the disclosure. | A third-party disclosure requires a recorded consent reference or other documented basis before release. | Disclosures to third parties during the period — frequently nil. |
| P6.2 | Create and retain a complete, accurate and timely record of authorised disclosures. | A disclosure register records recipient, data, date and basis for every disclosure. | Disclosure register entries. |
| P6.3 | Create and retain a complete, accurate and timely record of detected or reported unauthorised disclosures, including breaches. | Privacy incidents are logged in the incident system with a privacy flag and a documented disclosure assessment. | Privacy incidents raised and assessed. |
| P6.4 | Obtain privacy commitments from vendors and other third parties with access to personal information, assess their compliance on a periodic and as-needed basis, and take corrective action where necessary. | Vendors with access execute a data processing agreement before access is granted; compliance is reassessed at a defined frequency. | Vendors onboarded with access; periodic vendor reassessments performed. |
| P6.5 | Obtain commitments from those vendors to notify the entity of actual or suspected unauthorised disclosures, and act on such notifications through incident response. | Breach-notification obligations are standard terms in the DPA; vendor notifications route into the incident-response process. | Vendor agreements executed; vendor notifications received. |
| P6.6 | Provide notification of breaches and incidents to affected data subjects, regulators and others. | The breach procedure names decision-makers, timeframes and channels, and every notification issued is recorded. | Notifiable incidents — frequently nil, which the report then says. |
| P6.7 | Provide data subjects, on request, with an accounting of the personal information held and of disclosures of it. | The request workflow includes an accounting response assembled from the inventory and the disclosure register. | Accounting requests received — frequently nil. |
| P7.1 | Collect and maintain accurate, up-to-date, complete and relevant personal information. | Data-quality validations run against personal-information stores and defects are tracked to closure. | Quality checks run; data-quality defects raised and closed. |
| P8.1 | Implement a process for receiving, addressing, resolving and communicating the resolution of inquiries, complaints and disputes from data subjects and others, periodically monitor compliance, and make corrections in a timely manner. | A published complaints channel feeds a triage-and-resolution workflow, and a periodic privacy compliance review is performed with findings tracked to closure. | Complaints and inquiries received; periodic compliance reviews performed. |
Read the fourth column down the Privacy block and the cost of that category becomes concrete: notice versions, consent records, request cases, disclosure register entries, vendor agreements, complaints. Eighteen criteria is not eighteen policies. It is roughly a dozen record-keeping streams that have to exist, be dated, and be complete for the whole period. The same read across Availability shows the opposite — three criteria drawing on job logs and one test you can put in the calendar.
The scoping test
Commitments, not instincts
Every trust services criterion ends with some version of the phrase to meet the entity’s objectives. In a SOC 2 those objectives have a specific meaning: meeting the organisation’s commitments to customers and its system requirements. The standard defines commitments as declarations made by management to customers regarding the performance of one or more systems, communicated through individualised agreements, standardised contracts, service level agreements or published statements such as a privacy notice. It also separates baseline commitments — the ones every customer gets — from customer-specific commitments that result in additional processes or controls.
The description criteria close the loop. DC2 requires the system description to disclose the principal service commitments and system requirements — those that support the understanding of a broad range of report users; DC5 requires it to set out the applicable trust services criteria and the related controls. So the chain runs in one direction, and every link is inspectable. Clause, commitment, category, criteria, control, evidence — here is one instance carried through all six links, from the billing platform used in the worked example further down:
Clause
MSA section 7.2, in the standard paper every customer signs: “Provider shall maintain a Monthly Uptime Percentage of at least 99.9%. Customer’s sole and exclusive remedy for any failure is the service credit calculated under Exhibit B.” Illustrative wording, not a template.
Commitment
The same figure is promised to the broad range of customers, so it is a principal service commitment and belongs in the description under DC2 — with the number stated, not paraphrased.
Category
Availability. Nothing else in the standard evidences a promise about uptime, recovery and capacity.
Criteria
The complete set: the 33 common criteria plus A1.1, A1.2 and A1.3. You take the category whole.
Control
“Capacity utilisation is reviewed weekly against defined thresholds and threshold alerts are triaged to resolution” (A1.1); “Backups run daily with failure alerting and remediation” (A1.2); “A full restore of production data is performed at least annually and the result documented” (A1.3).
Evidence
52 weekly capacity reviews, of which perhaps eight are sampled; 365 backup job records, of which perhaps 25 are sampled; one restore test report, sampled in full. Management produces the complete populations; the service auditor sets every sample.
The clause hunt — six documents
The standard MSA. The security addendum. The data processing agreement. The signed riders of your ten largest customers. Anything published to individuals — privacy notice, trust page, status page commitments. Order-form exhibits, where the numbers usually hide.
Search them for these words
uptime, service credit, RTO, RPO, destroy, return, retention, accurate, reconcile, notice, consent, sub-processor. Every hit is a candidate commitment; every candidate resolves to a category or to nothing.
Work the chain backwards and the failure mode is obvious. If you cannot name the clause, you are proposing to design controls, describe them, have them tested and pay for the testing, in order to evidence an obligation you never took on. That is not conservatism. It is buying exception risk in an area where you had no exposure, in a document read by people who count exceptions.
Selection
Which categories your contracts have already chosen
Read the paper before the architecture diagram. Pull the six documents above and mark every sentence that promises something about how the system behaves. This is the table those sentences map onto.
| What is in the paper | Category it makes necessary | The proof that follows |
|---|---|---|
| An uptime or availability SLA with service credits; a stated RTO or RPO; a DR or business-continuity commitment. | AvailabilityA1.1–A1.3 | Capacity monitoring across the period, backup job outcomes, and at least one recovery test performed inside the period with a dated result. |
| A confidentiality clause covering customer data beyond personal data; a defined retention period; an obligation to return or destroy data on termination. | ConfidentialityC1.1, C1.2 | A designation scheme applied at receipt or creation, a retention schedule tied to the clause, and deletion evidence for records that reached end of retention. |
| A commitment that outputs are accurate — invoice or fee calculation, payment or trade processing, settlement files, usage or regulatory reporting, payroll, claims adjudication. | Processing IntegrityPI1.1–PI1.5 | The written processing specification, input validation and rejection handling, reconciliations with an independent reviewer, exception-queue ageing, and delivery of output against specification. |
| You publish your own privacy notice to individuals and make promises to them: consent, access-request turnaround, retention limits, breach notification, correction rights. | PrivacyP1.1–P8.1 | Versioned notices, consent records tied to the notice in force, a dated request case log, a disclosure register, privacy commitments obtained from vendors, breach notification records, a complaints log. |
| Only a general security addendum: “reasonable and appropriate technical and organisational measures”, MFA, encryption in transit and at rest, annual penetration testing. | Security onlyCC1.1–CC9.2 | The common criteria already cover all of it. Adding a category here buys nothing and adds populations the auditor must sample. |
| You process personal data strictly on the customer’s documented instructions as a processor, under a DPA, with no notice of your own to the individuals concerned. | Security + ConfidentialityCC series, C1.1, C1.2 | The DPA, the sub-processor list, and the confidentiality evidence above. Notice, consent and access obligations sit with the controller — normally your customer. |
| A named requirement in a customer’s vendor-risk policy: “SOC 2 Type 2 covering Security and Availability, issued within the last 12 months.” | AvailabilityA1.1–A1.3 | A demand signal rather than a contractual trigger, as the wording itself concedes — and still a legitimate reason to scope. Act on it before the observation period opens; it cannot be honoured retrospectively. |
| An enterprise rider imposes what the standard MSA does not: “Provider shall furnish evidence of a successful data restoration test upon request, no less than quarterly.” | AvailabilityA1.2, A1.3 | Four dated restore-test reports across the period rather than one. A single customer can put a category in scope for the whole system, because the description covers the system rather than a customer. Price the rider at negotiation, not at audit. |
The two expensive mistakes
Categories chosen on a feeling
Selecting Confidentiality because the data feels sensitive
The standard is unusually precise here. Information is confidential if the custodian is required to limit its access, use and retention and to restrict its disclosure to defined parties — and those requirements may be contained in laws or regulations, or in contracts and agreements containing commitments made to customers. Confidentiality is a duty someone imposed on you. It is not a description of how important the data looks on a schema diagram.
The category is only two criteria, which is exactly why it gets waved through. C1.1 requires the entity to identify and maintain confidential information; the familiar designate-on-receipt-and-set-a-retention-period procedure is that criterion’s point of focus rather than its text, and the standard is clear that using the criteria does not require an assessment of whether each point of focus is addressed — though in practice it is the procedure auditors ask to see. C1.2 is one sentence: the entity disposes of confidential information to meet the entity’s objectives related to confidentiality. That sentence is where programmes come apart, because disposal has to be demonstrated everywhere the data actually landed: the primary datastore, replicas, backup sets and their expiry, log archives, the analytics warehouse, support tooling and any downstream SaaS it was pushed into.
The failure is predictable. The organisation has a retention policy and no deletion evidence. The auditor asks for the population of records that reached end of retention during the period, and it cannot be produced, because nothing records when retention started. Meanwhile its access, encryption and disclosure controls already sat inside the common criteria it was taking anyway.
Selecting Privacy because you process personal data
Privacy does apply only to personal information — but the converse does not hold. Handling personal data is a precondition, not a trigger. The trigger is making privacy commitments: declarations about a system processing personal information, communicated in agreements, contracts, service level agreements or published statements such as a privacy practices statement. Most B2B software companies act as processors on their customers’ documented instructions, publish no notice of their own to the individuals concerned, and make those individuals no promises at all.
Getting this wrong is the most expensive selection in the standard. Privacy adds 18 criteria across eight series: notice (P1.1); choice and consent (P2.1); collection (P3.1, P3.2); use, retention and disposal (P4.1–P4.3); access and correction (P5.1, P5.2); disclosure and notification (P6.1–P6.7, which alone covers obtaining privacy commitments from vendors and other third parties, breach notification, and providing data subjects with an accounting of information held and disclosed); quality (P7.1); and monitoring and enforcement (P8.1). Each needs a described control and a testable population — the table above sets out both, criterion by criterion.
DC 200 adds a disclosure burden on top: when a SOC 2 examination addresses privacy, clear disclosure of whether the service organisation acts as data controller, data processor or both may be necessary, because its responsibilities differ by role. And the escape hatch is narrower than teams hope. A criterion genuinely not relevant can be omitted with an explanation under DC8 — the standard’s own example is P3.1, where the organisation does not collect personal information directly from data subjects. But a policy forbidding an activity does not make a criterion irrelevant: if your policy prohibits disclosure to third parties, you still describe and test the controls that prevent or detect it.
Where the driver is regulatory rather than contractual, the Privacy category is often the wrong instrument entirely. A controller-side obligation under GDPR or India’s DPDP Act is better served by a privacy management system — ISO/IEC 27701, for instance — than by bolting eighteen criteria onto an attestation your buyers are reading for security assurance.
Who decides
The decision is management’s to make
The most common instinct — ask the CPA firm which categories we need — is itself a problem. Selecting the scope and designing the controls are management decisions. An auditor who made them would be reporting on its own work, and the AICPA independence rules are what stop it. The firm can tell you what a category would require of it; it cannot choose for you. That line runs through the whole engagement:
| Decision | Who owns it | Who cannot own it |
|---|---|---|
| Selecting the trust services categories | Management of the service organisation | The service auditor. Choosing the scope and designing the controls are management decisions; a CPA firm that made them could not then report on them without impairing its independence. |
| Drafting the system description against DC 200 | Management | The service auditor, which reports on the description and therefore cannot author it. TCSA can help you write and structure it; the description remains management’s. |
| Writing the assertion | Management | Anyone else. The assertion is management’s statement that the description is fair, the controls suitably designed and — in a Type 2 — operating effectively. The opinion is about that statement. |
| Designing, implementing and operating the controls | Management, supported by TCSA on readiness, control implementation, evidence and audit coordination | The CPA firm issuing the opinion. This is the line that decides who you can hire for which half of the work. |
| Defining populations, sample sizes and test procedures | The service auditor, exercising professional judgement under AT-C section 205 | Management or TCSA. You produce the complete population and may be asked to demonstrate completeness; you do not set the sample. |
| Forming and signing the opinion | The licensed CPA firm | Management, TCSA, or any non-CPA advisory firm. TCSA coordinates the examination and never certifies, attests, audits or signs. |
This is the practical reason scoping happens before the audit firm is even engaged, and the reason it is normal to buy the two halves separately. TCSA runs readiness, control implementation and evidence and coordinates the examination; the licensed CPA firm performs the examination and issues the report. TCSA never certifies, attests, audits or signs.
Evidence
What the CPA firm actually requests
A Type 2 examination does not run on policies. For each control the service auditor defines a population — every occurrence of the thing in the stated period — satisfies itself that the population is complete, then samples from it and inspects artefacts. What does not vary between firms is the demand for a complete population: a category you cannot produce a population for is a category you are not ready to scope.
| Category | Population the auditor defines | Artefacts requested | What gets rejected |
|---|---|---|---|
| Security | Joiners, movers and leavers; production changes; access reviews; scan and patch cycles; incidents raised. | System-generated user listings with dates, tickets showing approval before deployment, access-review exports showing what was removed and by whom, scan reports with remediation dates, incident timelines. | Undated screenshots. A change approved after the deploy timestamp. A review sign-off with no evidence of the accounts acted on. A control called “continuous” with nothing to sample. |
| Availability | Backup jobs executed; restore tests; capacity alerts and their handling; recovery exercises; availability incidents. | Backup job logs showing success and failure, a restore test report with date, scope and outcome, capacity or alert history covering the period, a signed after-action record for the recovery exercise. | A DR plan with no test behind it. A console screenshot proving backups are enabled on one date. A restore test performed before the period started. A capacity graph exported the week before fieldwork. |
| Confidentiality | Records that reached end of retention; terminations carrying return-or-destroy obligations; classification decisions; media and asset disposals. | A retention schedule mapped to the contractual clauses, deletion job output with record counts and dates, offboarding tickets with deletion confirmation, destruction certificates for physical media. | A retention policy with no deletion evidence. Deletion in the primary store with no account of backups, log archives, the analytics warehouse or downstream SaaS. A certificate dated after the contractual deadline. |
| Processing Integrity | Transactions or batches processed; records rejected by validation; reconciliations; exceptions raised and cleared; outputs delivered against specification. | The documented specification, validation rule configuration and rejection logs, reconciliations with preparer and independent reviewer, exception-queue ageing, delivery logs against agreed timing. | “The pipeline is automated, therefore accurate.” A reconciliation prepared and reviewed by one person. Open exceptions older than the period with no disposition. A specification that exists only in someone’s head. |
| Privacy | Access, correction and deletion requests received; consents captured and withdrawn; disclosures to third parties; notice changes; vendors with access to personal information; complaints; incidents involving personal information. | A request case log with received and completed timestamps and outcome, consent records tied to the version of the notice in force, a disclosure register, executed privacy commitments from vendors, breach notification records, a complaints log. | A privacy page with no version history, so nobody can show which notice was in force when consent was taken. Consent flags with no scope. A request log with outcomes but no dates. A vendor list with no privacy commitments obtained. |
Read that table as a cost model. Security is the largest control set, but its evidence is generated by systems you already run. Availability and Processing Integrity add populations that mostly already exist — job logs, reconciliations, exception queues. Confidentiality and Privacy add populations that usually do not exist yet and have to be built: retention clocks, deletion logs, versioned notices, consent records, dated request cases. That is the real difference between a category costing a fortnight of preparation and one costing a quarter.
Sample sizes
How many items each control actually costs you
Sample size follows control frequency and population size. The figures below are the service auditor’s professional judgement under AT-C section 205 rather than a published rule, and they vary between firms — nobody can quote you a binding number in advance. They are still the right way to price a category before you select it, because the shape does not change: a category made of annual controls is cheap to evidence and a category made of event-driven controls is not.
| Control frequency | Population over a 12-month period | Sample commonly drawn | Worked instance from this page |
|---|---|---|---|
| Annual | 1 | 1 | The recovery test under A1.3. |
| Semi-annual | 2 | 2 | The half-yearly user access review, commonly described against the CC6 series. |
| Quarterly | 4 | 2 | Restore evidence furnished under the enterprise rider — A1.2 and A1.3. |
| Monthly | 12 | 2–5 | The output reconciliation signed by an independent reviewer under PI1.4. |
| Weekly | 52 | 5–8 | The exception-queue ageing review under PI1.2; capacity review under A1.1. |
| Daily | 250+ (365 for a calendar-day job) | 15–25 | Backup job outcomes under A1.2. |
| Many times daily or event-driven | Varies with volume | 25–40 | Access requests under P5.1; production changes under CC8.1; joiners and leavers under the CC6 series. |
Two consequences worth carrying into the scoping workshop. First, describing a control as “continuous” does not reduce the sample — it enlarges the population and usually forces the largest one. Second, a control you run monthly that could defensibly run quarterly costs you three times the evidence for the same assurance, which is a design decision made before day one of the period rather than a negotiation during fieldwork.
What you already have
Categories that are nearly free if you run an ISMS
A large share of the organisations making this decision are already certified to ISO/IEC 27001 or running a continuity programme, and the honest question is which categories that investment has already paid for. The mappings below are practitioner crosswalks, not equivalences published by either standards body — certification never substitutes for a criterion, and no ISO control is evidence of operating effectiveness across a SOC 2 period on its own.
| Category | Nearest existing programme | What carries over | What still has to be built |
|---|---|---|---|
| Security | ISO/IEC 27001 ISMS, clauses 4–10 plus Annex A | Risk assessment and treatment, access control, change and incident management, supplier records, internal audit and management review as monitoring evidence. | A SOC 2 tests operating effectiveness across a period from complete populations, so the ISMS evidence has to be reproducible date by date rather than sampled at surveillance. The COSO-derived CC1–CC5 entity-level material — board oversight, communication, monitoring — usually needs sharpening. |
| Availability | ISO 22301 BCMS, or ISO/IEC 27001 Annex A A.5.29 and A.5.30 with A.8.13 and A.8.14 | The business impact analysis, the continuity plan, backup and redundancy design, and exercise records that satisfy A1.3 if they fall inside the period. | Capacity monitoring and evaluation under A1.1 is usually the gap: a BCMS proves you can recover, not that you manage capacity demand with thresholds and alerts. |
| Confidentiality | ISO/IEC 27001 Annex A A.5.12–A.5.14 with A.5.10 and A.8.10 | The classification scheme, labelling, transfer rules and the deletion control statement. | Retention clocks and disposal evidence for C1.2 almost never carry over. Annex A asks for information deletion; the SOC 2 asks for the population of records that reached end of retention in the period and what happened to them. |
| Processing Integrity | No ISO analogue in common use | Little. Change management and testing discipline help, but nothing in an ISMS defines the product specification the accuracy criteria are tested against. | PI1.1 is greenfield: a written, versioned specification of data processed and product or service specifications, before any of PI1.2–PI1.5 can be tested. |
| Privacy | ISO/IEC 27701 PIMS | Notice, consent management, the data-subject request workflow, the record of processing and the vendor commitments map closely to P1, P2, P5 and P6.4. | The dated evidence layer: a case log with received and completed timestamps, consent tied to the notice version in force, a disclosure register, and records for P6.6 and P6.7 that most PIMS implementations keep informally. |
The pattern is consistent. An ISO 22301 continuity programme makes Availability a small increment; a 27701 privacy management system makes Privacy tractable rather than cheap; and nothing you already own makes Processing Integrity easy, because the specification the accuracy criteria test against is written by your product organisation and nobody else. Existing certification changes the cost of a category. It never changes whether a commitment exists.
Worked example
One scoping decision, carried end to end
An illustrative composite, not a client — a sixty-person subscription-billing reconciliation platform preparing a first Type 2 over an observation period of 1 October 2026 to 30 September 2027. The dates run forward from today; the sequence is the one we run.
What the paper says. The standard MSA promises 99.9% monthly uptime with service credits; a confidentiality clause covers Customer Data with a defined retention period and return-or-destroy within thirty days of termination; and a further clause commits that invoice calculations will match the customer’s configured rate card. The standard DPA positions the company as a processor acting on documented instructions, with a published sub-processor list and no privacy notice of its own to end individuals. One enterprise customer’s rider adds quarterly restore evidence on request.
What that decides. The uptime SLA and the restore rider make Availability necessary. The confidentiality clause, with its retention period and destruction obligation, makes Confidentiality necessary — note that it is the clause that decides it, not the fact that billing data is sensitive. The rate-card accuracy commitment makes Processing Integrity necessary, and PI1.1 forces something useful before the period even opens: the processing specification has to be written down, which surfaces two undocumented rounding behaviours. Privacy is excluded, with the reasoning recorded for the description — processor role, no notice, no consent obtained from individuals, no access requests received directly.
18 Aug 2026
Scoping workshop
Contracts read before controls. Four categories selected, each traced to a clause. Privacy excluded, with the reason written down for the description.
1 Oct 2026
Period opens
Every control for all four categories is live from day one. The first restore test is booked for November so it lands inside the period, not after it.
14 Nov 2026
Restore test executed
A 4h12m restore of the production Postgres cluster into an isolated VPC against an eight-hour RTO commitment, signed off the same day. One artefact, one population, the whole of A1.3.
14 Apr 2027
Prospect asks for Privacy
Month seven. Adding Privacy now brings 18 criteria whose controls did not operate for months one to six — evidence nobody can create retrospectively.
1 May 2027
Privacy programme starts anyway
Notice, consent records, request workflow and disclosure register are built and begin operating outside the current examination, so they have a full period behind them next time.
30 Sep 2027
Period closes
The report covers four categories. The prospect gets it alongside the DPA, the sub-processor list and a written statement of the next period’s scope and dates — the answer a vendor-risk reviewer can act on, which a mid-period bolt-on would not have been.
Four categories, sized. The figures below are what a scope of this shape typically produces for a company of sixty people — illustrative, not a benchmark, since control counts move with how finely controls are split and sample sizes are the auditor’s to set.
| Category | Criteria addressed | Controls described in Section 3 | Populations defined | Items sampled |
|---|---|---|---|---|
| Security | 33 | 41 | 9 | 96 |
| Availability | 3 | 6 | 3 | 27 |
| Confidentiality | 2 | 5 | 3 | 18 |
| Processing Integrity | 5 | 9 | 4 | 44 |
| Total | 43 | 61 | 19 | 185 |
Twenty-eight of those 185 sampled items belong to the three elective categories’ own criteria; the rest sit under the common criteria the company was taking regardless. That ratio is the honest answer to “what do three extra categories cost” — far less in testing than in the record-keeping that has to exist before testing is possible.
The decision that matters is the one in April. The instinct at month seven is to ask the CPA firm to add Privacy “since the audit is still running”. The honest answer — build it now, scope it next period, and give the prospect the underlying documents plus a dated commitment — is both cheaper and more persuasive than a category tested across four months of a twelve-month period with a caveat attached.
Timing
Why a category cannot be bolted on in month eight
A Type 2 opinion addresses whether controls operated effectively throughout the specified period. Introduce a category part-way through and its controls did not operate for the earlier portion — and no amount of goodwill creates evidence for a month that has already passed. Under AT-C section 205 the service auditor must obtain sufficient appropriate evidence for the period the report covers, and it is the auditor, not you, who decides whether what exists supports an opinion. Four realistic paths, and only one is comfortable.
Defer to the next examination
CleanestDesign and operate the category’s controls now, outside the current examination, and add the category at the start of the next period so it has a full window of operation behind it. The current report is unaffected, the next one is complete, and the buyer gets a dated answer instead of a caveat.
Type 1 on the added category
Buys a document nowA Type 1 addresses the suitability of design of controls as of a specified date rather than their operating effectiveness throughout a period, so a category whose controls are live today can be reported on now while the Type 2 period for it starts running. The limits are real: buyers increasingly discount Type 1s, and it puts two reports in circulation with different scopes and different dates, which vendor-risk teams will ask about.
Re-cut the period
Costs a cycleShorten or restart the observation period so it begins after the new controls are live, or run a shorter separate period for the added category. Both work; both delay the report your sales team is waiting for, and a short period ages faster in buyers’ hands.
Take it in-period anyway
Carries consequencesThe description must disclose the change: DC9 requires the relevant details of significant changes to the system and controls during the period, and DC 200’s guidance expects that disclosure to include the date each change occurred and how the system differed before and after. Testing then covers only the sub-period in which the controls operated, and the service auditor decides whether that supports an opinion on the category or whether the opinion must be modified.
There is a second reason the “just add it” request fails, and it is structural rather than evidential. A category changes the applicable criteria disclosed under DC5, the principal service commitments disclosed under DC2, the controls set out in the description, and management’s written assertion — the document in which management, not the auditor, claims the controls were suitably designed and operated effectively. All four move together, and the assertion has to be true.
Contested ground
Where this gets argued
The straightforward eighty per cent is above. These are the cases that generate the real questions — in scoping workshops, and later in vendor-risk calls.
Availability does not audit your SLA number
The standard says plainly that the availability objective does not, in itself, set a minimum acceptable performance level. A1.1–A1.3 test capacity management, recovery infrastructure and recovery testing — not whether you achieved 99.99%. A buyer who wants attainment needs an uptime report. The reverse holds too, with a caveat worth getting right: if the same uptime commitment is made to the broad range of your customers it is a principal service commitment and DC2 puts it in the description. DC 200 adds that a commitment about system availability made to only one or a small subset of user entities may be omitted, because it is unlikely to support the understanding of a broad range of report users.
Confidentiality is not a substitute for Privacy
Confidential information may include personal information as well as trade secrets and intellectual property, so buyers routinely read a Confidentiality category as privacy coverage. It is not. Say so in the description rather than let the ambiguity work in your favour.
A criterion that is genuinely not relevant — and one that only looks it
In limited circumstances a criterion may not be applicable, and the standard gives its own example: P3.1, on collection, is not applicable to a service organisation that does not directly collect personal information from data subjects. DC8 then requires the description to explain why. But DC 200 is equally explicit that a policy forbidding an activity is not sufficient to render a criterion irrelevant — “we never disclose personal information to third parties” does not remove the disclosure criteria. The description still sets out the controls that prevent or detect such disclosure, and the auditor still tests them. A narrow door, and a disclosure rather than a discount.
Outsourced is not out of scope
DC 200 states that a criterion relevant to the services stays relevant even where every component supporting it has been outsourced to a subservice organisation — its own example is a service organisation running entirely on an infrastructure-as-a-service provider, where CC6.5 on discontinuing protections over physical assets remains relevant even with the provider carved out. Managed cloud does not delete criteria; it changes who performs the control and pushes the question into carve-out treatment and complementary controls.
Nil populations
Some controls may not operate at all in a quiet period — no access requests, no third-party disclosures, no breach notifications, no invoked recoveries. Where the population is nil, the service auditor can evaluate design and inspect the procedure but has nothing to sample for operating effectiveness, and the report says so. Not an exception, but a sentence buyers ask about. Brief your sales team first.
One product needs it, another does not
Processing Integrity may be true of your billing engine and meaningless for your analytics dashboard. The fix is the system boundary, not the category list: describe a system for which the category is coherently true. Widening the boundary and then adding categories to satisfy its noisiest part is the most reliable way to buy exceptions.
The two sentences nobody drafts in advance
Deselecting a category and reporting a nil population both come down to a sentence in the description or the test results, and both get written badly under time pressure at the end of fieldwork. Draft them at scoping instead. Both blocks below are illustrative wording to adapt with your service auditor — they are not text from the standard, and the description is management’s document.
Illustrative — excluding a category in the description
“The privacy category is not within the scope of this examination. The Company acts as a processor of personal information on the documented instructions of its user entities, does not publish a privacy notice to the individuals whose information it processes, and does not obtain consent from or respond directly to those individuals. Controls over the protection of that information are addressed under the security and confidentiality categories.”
Illustrative — a nil population in the test results
“No third-party disclosures of confidential information occurred during the period; accordingly, no items were available for testing and the service auditor’s procedures were limited to inspection of the procedure and evaluation of the design of the control.”
Several of these resolve into a boundary question rather than a category question. If you are unsure which system the categories are true of, settle the system description and the treatment of subservice organisations first. Category selection made on top of an unsettled boundary is guesswork with an invoice attached.
Objection handling
What the buyer’s security team says
Scope decisions get litigated in vendor-risk reviews, not in kick-off calls. Six push-backs worth rehearsing before the report goes out. The answers are drafted in the service organisation’s own voice, for your team to use in the call — the “we” below is you, not TCSA.
“Your report only covers Security. Our policy requires Confidentiality.”
The answer is either a date or a clause. If the contract carries a confidentiality obligation with a retention period and a return-or-destroy term, the category belongs in scope and the right response is the next period, with the start date named. If it does not, ask which of C1.1 and C1.2 the reviewer believes is unaddressed — identification and maintenance of confidential information, or its disposal — and show the common criteria controls that already cover it.
“You process our customers’ personal data. Why is Privacy not in scope?”
Because the privacy criteria evidence commitments made to data subjects, and as a processor acting on your documented instructions we make none: you publish the notice, you obtain consent, you own the response to access requests. Scoping the category would have us assert obligations we do not hold. What we can evidence is what we promised — the DPA, the sub-processor list, confidentiality and disposal, and the common criteria.
“We buy a 99.9% SLA from you and Availability is not in the report.”
The strongest version of this objection, and it usually deserves a concession. An uptime commitment with service credits is exactly what the standard means by a commitment, and if it is made to the broad range of customers DC2 discloses it as a principal service commitment whether or not the category is scoped. If Availability is absent while the SLA sits in the description, expect the question every time. Scope it at the next period rather than argue the point.
“Your competitor’s report covers all five categories.”
It may, and that is not automatically better. Every category selected is a set of criteria the description asserts and the auditor tests, and any failure lands in Section 4 as an exception under a clean-looking cover. Four earned categories with no exceptions read better to a careful reviewer than five carrying findings in an area the organisation never had reason to commit to.
“Can you just add the category before you send the report?”
No. A category is not a label on a cover page. It changes the applicable criteria disclosed under DC5, the principal service commitments disclosed under DC2, the controls described, and management’s written assertion. For a Type 2 the opinion addresses operating effectiveness throughout the stated period, so a category added after the period cannot be evidenced at all.
“Last year’s report had Confidentiality. This year’s does not.”
Dropping a category is permitted and occasionally correct — a commitment lapsed, a product was retired, the boundary changed. It is also the most noticed difference between consecutive reports, because vendor-risk teams compare them side by side. Put the reason in the description among the significant changes disclosed under DC9, and tell your largest customers before their reviewer finds it.
One point worth adding to any of these answers: the categories you scope also decide what you can publish. A SOC 2 is a restricted-use report, distributed under NDA to parties who understand it. A SOC 3 is issued over the same categories and the same period and is general-use, so it can sit on your website and in your trust centre without a signature. That cuts both ways. A category you scope buys a restricted-use report and a publishable one; a category you skip is absent from both, and the buyer asking why Availability is missing is often the same buyer who would have accepted a public SOC 3 covering it.
Frequently Asked Questions
Which trust services criteria are mandatory for SOC 2?
Security, in the sense that matters. The criteria are split into criteria common to all five categories and additional criteria specific to availability, processing integrity, confidentiality and privacy. The common criteria — CC1.1 through CC9.2, 33 criteria across nine series (CC1 to CC9) — are the complete set of control-activity criteria for Security, and for any other category a complete set is the common criteria plus that category’s additional criteria. Every SOC 2 therefore carries the common criteria; the other four sit on top of them by election.
Who decides which categories go into the report — us or the audit firm?
You do. Selecting the trust services categories, drafting the system description against the DC 200 description criteria, writing the assertion and designing the controls are all management decisions. A CPA firm that made them would be reporting on its own work, which the AICPA independence rules prevent, so "ask the auditor which categories we need" is the wrong opening move — the firm can tell you what a category would require of it, but cannot choose for you. What the service auditor does own is the testing: defining populations, setting sample sizes, performing procedures and forming the opinion. TCSA sits on the management side of that line — readiness, control implementation, evidence and audit coordination — and never certifies, attests or signs.
Do I need the Privacy category if I process personal data?
Usually not. Privacy applies only to personal information, but processing personal information is a precondition rather than a trigger. What triggers the category is making privacy commitments — declarations about how a system processing personal information will perform, communicated in agreements or in a published privacy notice. Most B2B software companies act as processors on their customer’s documented instructions, publish no notice of their own, and owe individuals nothing directly. In that position the honest scope is Security plus Confidentiality, with the DPA and sub-processor list supplied alongside the report.
What is the difference between the Confidentiality and Privacy categories?
Privacy applies only to personal information. Confidentiality applies to sensitive information of every kind — confidential information may include personal information as well as trade secrets and intellectual property. The other difference is what each obliges you to do. Confidentiality protects designated information from creation through to disposal: two criteria, C1.1 and C1.2. Privacy covers the individual’s relationship with their data — notice, consent, access, correction, disclosure, breach notification — across 18 criteria. Scoping Confidentiality does not give a buyer privacy assurance, and you should say so rather than let them assume it.
How much does each additional trust services category add?
Less in criteria count than in evidence streams, which is what drives cost. Availability adds three criteria and mostly draws on monitoring you already run, plus at least one recovery test inside the period. Processing Integrity adds five and usually needs a written specification first. Confidentiality adds only two but often requires retention clocks and deletion logs that do not yet exist. Privacy adds 18 and typically requires a whole records layer. TCSA runs readiness, control implementation and evidence and coordinates the examination — a fixed fee from $4,000 for early-stage startups, quoted after scoping. The CPA firm issues the report and bills its attestation fee separately.
How many evidence items will the auditor sample per control?
It follows control frequency, and the number is the service auditor’s professional judgement under AT-C section 205 rather than a published rule — firms differ, and nobody can bind an auditor in advance. The usual shape: an annual control yields a population of one and a sample of one; a quarterly control four and two; a monthly control twelve and two to five; a weekly control fifty-two and five to eight; a daily control several hundred and fifteen to twenty-five; an event-driven control such as access provisioning or production change is sampled at twenty-five to forty. That is why a category made of annual and quarterly controls, like Availability, is cheap to evidence, and why calling a control "continuous" makes it more expensive rather than less.
Can we add a trust services category in the middle of the observation period?
Rarely, and never comfortably. A Type 2 opinion addresses operating effectiveness throughout the specified period, so controls introduced in month eight have no evidence for months one to seven and none can be manufactured. Four paths exist: defer the category to the next examination, which is cleanest; issue a Type 1 on the added category, which reports on suitability of design as of a date and buys a document now at the cost of two reports with different scopes in circulation; re-cut the observation period so it starts after the controls are live, which costs a report cycle; or take it in-period, in which case the description must disclose the change under DC9 and the service auditor decides whether the shortened evidence window supports an opinion.
Does the Availability category prove we met our uptime SLA?
No, and the misconception causes real friction in sales cycles. The standard states that the availability objective does not, in itself, set a minimum acceptable performance level, and does not address system functionality or usability. A1.1 to A1.3 examine whether you monitor and evaluate processing capacity, maintain environmental protections, backup processes and recovery infrastructure, and test recovery procedures. A buyer who wants attainment against 99.9% needs an uptime report. What the SOC 2 does do is put your principal service commitments into the description under DC2 — so where the same uptime figure is promised to the broad range of your customers, every reader sees the number you promised. DC 200 notes that an availability commitment made to only one or a small subset of user entities may be omitted from the description instead.
When does Processing Integrity actually apply?
When accuracy of output is part of what you sell, and you have committed to it. Payment and trade processing, settlement, billing and fee calculation, payroll, claims adjudication and usage or regulatory reporting are the recurring cases. The standard describes processing integrity as processing being complete, valid, accurate, timely and authorised, usually addressed at the system or functional level rather than entity-wide. The practical gate is PI1.1: documented definitions of the data processed and the product or service specifications. Without a written specification there is nothing for the accuracy criteria in PI1.2 to PI1.5 to be tested against.
Should we scope categories on what customers ask for or what our contracts say?
Both, in that order of evidence and the reverse order of urgency. Contracts are the defensible basis: they create the commitments the criteria refer to, and DC2 puts the principal ones in the description whether or not you scope the matching category. Customer demand is a legitimate reason to add a category — a named requirement in a vendor-risk policy is a commercial fact — but it must be acted on before the observation period opens, because it cannot be applied retrospectively. Run the contract review first, overlay the last twelve months of security questionnaires, then settle the list before day one.
Related reading: the five trust services categories in full, the SOC 2 controls list, choosing your observation period, how to read a SOC 2 report, opinions and exceptions, common SOC 2 pitfalls, and the SOC 2 hub.
Written By Expert Auditors
Keep Exploring
Related Reading
Trust Services Criteria
Security, Availability, Confidentiality, Processing Integrity, Privacy.
Read moreSOC 2 Scope & System Boundary
What may legitimately be excluded, and the DC 200 test that stops a boundary flattering the vendor.
Read moreSOC 2 Controls List
No official list exists — illustrative controls by criteria series (CC1–CC9).
Read moreSOC 2 Observation Period: 3, 6 or 12 Months?
No AICPA minimum. Why short windows leave low-frequency controls untested.
Read moreSOC 2 Knowledge Hub
Type 1 vs Type 2, criteria, timelines and audit prep — all guides.
Read moreWhat Is SOC 2?
The AICPA attestation explained — five categories, Type 1 vs Type 2, report not certificate.
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