The five SOC 2 Trust Services Criteria, and how to choose which apply
SOC 2 lets you pick which of five trust categories your report covers. Security is always required; the other four are optional and should be driven by what you actually do and what you promise customers.
The five categories, and why only one is mandatory
SOC 2 is built on the AICPA's Trust Services Criteria, most recently issued in the 2017 framework with revised points of focus published in 2022. There are five categories an examination can cover: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security, also called the Common Criteria, is the only one that is mandatory and forms the backbone of every SOC 2 report. The other four are optional add-ons, and you choose which to include based on the commitments you make to customers and the nature of the service you run. This selection is not a marketing decision, because each category you add brings its own control criteria that the auditor will test, and any criterion you cannot support cleanly becomes an exception in the report.
Security and Availability: the most common starting set
Security covers protection against unauthorized access, disclosure, and damage to systems and data, and it spans the nine Common Criteria families that touch governance, risk assessment, access control, change management, and incident response. The vast majority of first-time SOC 2 reports cover Security alone, and for many SaaS vendors that is genuinely sufficient for the questions buyers are asking. Availability is the next most frequently added category, and it is appropriate when you have made uptime or accessibility commitments, typically through an SLA. Its criteria focus on capacity monitoring, backups, environmental protections, and a tested recovery or business continuity capability. If you sell to customers who treat your system as operationally critical and you publish availability targets, adding this category aligns your report with the promises in your contracts.
Confidentiality versus Privacy: they are not the same thing
These two categories are frequently confused, but they protect different things. Confidentiality concerns information that has been designated as confidential, such as customer business data, source code, contracts, or intellectual property, and its criteria focus on identifying that information and controlling its access, retention, and disposal regardless of whether it relates to a person. Privacy is narrower in subject but deeper in obligation, because it deals specifically with personal information and runs across eight criteria families (P1 through P8) covering notice, choice and consent, collection, use, retention and disposal, access, disclosure, data quality, and monitoring and enforcement. A useful rule of thumb is that Confidentiality fits when you hold sensitive customer data they consider proprietary, while Privacy fits when you collect or process personal data on behalf of individuals and want to demonstrate handling commitments beyond what Security alone shows.
Processing Integrity: the most situational category
Processing Integrity addresses whether system processing is complete, valid, accurate, timely, and authorized to meet the entity's objectives. It is the least commonly included category because it only makes sense when the correctness of your processing is itself the product you sell. Payment processors, payroll and billing platforms, transaction-clearing services, e-commerce order systems, and data-transformation pipelines are the classic candidates, because a customer's core concern is that a transaction or calculation came out right. If your product mainly stores, transmits, or grants access to data rather than computing results that must be provably accurate, this category usually adds testing burden without answering a question your buyers are actually asking. Be honest about what you do before adding it, since processing-integrity controls require evidence of input validation, error handling, and output reconciliation that not every organization has matured.
How to decide: start from commitments and obligations, not from a checklist
The right way to scope categories is to work backward from two sources of truth: the commitments you have made to customers and the regulatory or contractual obligations you carry. Read your SLAs, your data processing agreements, your security questionnaires, and the recurring asks in your sales cycle, because those reveal which categories your buyers genuinely want assurance on. Resist the temptation to include every category to look thorough, since each one you add lengthens fieldwork, raises cost, and increases the chance of a noted exception that you then have to explain. A common and defensible progression is Security plus Availability for a typical infrastructure or SaaS vendor, adding Confidentiality when you custody sensitive customer data, and reserving Privacy and Processing Integrity for organizations whose business model directly turns on personal data handling or processing accuracy. When in doubt, scope tighter for your first report and expand in later periods as customer demand and your control maturity justify it.