Every SOC 2 includes the Security criteria. The other four — Availability, Confidentiality, Processing Integrity and Privacy — are optional, and you choose them. The right way to choose is to look at what you have promised customers in writing, not at what sounds thorough.
The most common scoping mistake in a first SOC 2 is including criteria nobody asked for. Each additional category brings controls you have to operate, evidence you have to produce, and testing the auditor has to perform, every year, forever. Adding one because it seemed prudent in month two is a commitment your successor inherits.
The five categories in plain terms
Security (the common criteria, sometimes written CC) is mandatory. It covers the control environment, communication, risk assessment, monitoring, control activities, logical and physical access, system operations, change management and risk mitigation. Roughly speaking, it is “the system is protected against unauthorised access, use or modification”. If you only ever do one thing, this is it, and for a large share of SaaS companies it is the whole report.
Availability addresses whether the system is available for operation and use as committed. Think capacity planning, monitoring, backup, recovery, and environmental protections. It does not certify an uptime number — it examines whether the controls supporting your availability commitments were designed and operating.
Confidentiality addresses information designated as confidential — usually by contract or by your own classification policy — and how it is protected through its lifecycle, including retention and disposal. The reference point is your commitment to confidentiality, not the sensitivity of the data in the abstract.
Processing Integrity addresses whether system processing is complete, valid, accurate, timely and authorised. This is a transaction-oriented category: it asks whether the thing your system computes or moves came out right.
Privacy addresses personal information across its lifecycle — notice, choice and consent, collection, use, retention, disclosure, access by data subjects, quality and monitoring. It is measured against your own privacy notice and applicable criteria, and it is by far the largest of the four optional categories.
One thing worth knowing: within the criteria you will also see points of focus. They are illustrative considerations that help you and the auditor think about how a criterion might be met. They are not a checklist you must satisfy item by item.
Start from your contracts, not your ambitions
The honest test for whether a category belongs in your report is: have we made a written commitment to customers that this category speaks to?
- If your MSA or SLA promises a percentage of uptime, credits for downtime, or a recovery time objective, you have made an availability commitment.
- If your contracts or NDAs say you will treat customer data as confidential, restrict who sees it, and delete it on termination, you have made a confidentiality commitment.
- If customers rely on your system to calculate, reconcile, settle, bill or transmit records accurately, you have made a processing integrity commitment.
- If you collect and use personal information in ways described in a privacy notice — particularly if you are the one deciding how that data is used, rather than just processing it under instruction — privacy is in play.
Write the list from your own paper. Then compare it against what buyers are asking for. Where those two overlap is your scope.
Which ones buyers actually ask for
Patterns vary by market, but a few hold up consistently.
Most enterprise security reviews ask for Security and stop. It answers their core question and it is what their standard names.
Availability comes up when the buyer’s own service depends on yours being up — infrastructure, APIs, anything embedded in their production path. If you are a component of their product rather than an internal tool, expect it.
Confidentiality comes up when you handle data the buyer considers sensitive but which is not necessarily personal — source code, financial models, unreleased product data, legal documents.
Processing Integrity comes up in payments, payroll, billing, claims processing, trading, and anything with a number at the end that someone relies on. It is the category most often asked for by finance and audit functions rather than security teams.
Privacy comes up less often than founders expect, because buyers concerned about personal data usually ask for something else — a data processing agreement, GDPR commitments, a HIPAA business associate agreement, or evidence of specific safeguards. Those are not the same as the SOC 2 Privacy criteria, and a Privacy scope does not satisfy them.
Why adding a category is more expensive than it looks
The obvious cost is more controls and more testing. The less obvious cost is what the category drags in behind it.
Availability pulls in backup restoration testing you actually perform and document, capacity monitoring with thresholds someone reviews, and business continuity or disaster recovery exercises with evidence. If you have never restored from a backup in a controlled test, that is a real project.
Processing Integrity pulls in input validation, error handling, exception queues, reconciliation procedures and evidence that someone investigates and resolves processing failures. Engineering teams often discover their error handling is excellent at retrying and terrible at recording.
Privacy pulls in whole functions outside engineering — a maintained privacy notice, a data inventory, a documented process for handling data subject requests with evidence of responses, retention schedules that are actually enforced, and controls over disclosure to third parties. It typically touches legal, support and marketing. Companies that add Privacy in a first SOC 2 frequently spend more effort there than on everything else combined.
Removing a category later is possible, but it looks like a step backwards to anyone comparing this year’s report to last year’s, and they will ask about it.
A workable default
For most first-time SaaS companies, this sequence holds up:
- Year one: Security only. Get a clean examination over a real observation window with controls you genuinely run.
- Add Availability when a buyer asks, or when your contractual uptime commitments become material enough that you want them examined.
- Add Confidentiality when customers are pushing classification, retention and deletion questions at you in security reviews.
- Add Processing Integrity when your product’s output is the thing customers depend on being correct, and they have said so.
- Consider Privacy only when a buyer specifically requires the SOC 2 Privacy criteria, and after the underlying privacy programme exists.
There is nothing unserious about a Security-only SOC 2. It is the most common scope there is, and a clean Security report with controls you actually operate is worth far more in a security review than a five-category report full of exceptions.
What to do next
Pull your standard customer agreement and your last three security questionnaires. Highlight every commitment about uptime, confidentiality, accuracy of processing and personal data. That highlighted list is your candidate scope — everything else is optional, and probably premature.
Then ask your two most demanding prospects which criteria they require. If both say Security, scope Security. Assurion scopes trust services criteria with clients before an examination begins, precisely so nobody ends up committed to a category their buyers never asked about.