The Five SOC 2 Trust Service Criteria
Reviewed by Marcus Dunhill, CISA, CISSP
The five SOC 2 Trust Service Criteria — Security, Availability, Processing Integrity, Confidentiality, and Privacy — define the categories of controls that auditors evaluate during a SOC 2 engagement. Security is mandatory in every audit; the other four are optional based on business model and customer requirements. According to the AICPA's 2024 SOC reporting data, Security and Availability are included in 92% of SOC 2 reports, while Privacy is included in only 34%, making scope selection one of the highest-impact cost and effort decisions in the audit process.
You're reading through a SOC 2 report and the auditor keeps referencing the Trust Service Criteria. You're wondering what that means, what the auditor was actually evaluating, and whether your report covers the things your customers care about. The five criteria sound like alphabet soup at first — Security, Availability, Processing Integrity, Confidentiality, Privacy — but they're actually the five categories that customers care about most when they're deciding whether to trust you with their data and systems. Every SOC 2 audit evaluates some combination of these five, and understanding what each one means is essential because it tells you what the auditor was looking for, what evidence you needed to gather, and what your customers will be looking for when they read your report.
Security: The Foundation That Gets the Most Attention
Security addresses the most fundamental question in any SOC 2 audit: can bad actors break into your systems and steal data or cause damage? This criterion commands the most resources because it covers the broadest attack surface. The auditor is looking at access controls — how you're restricting who can get into what systems and data. They're examining encryption, both for data at rest (sitting in your storage systems) and data in transit (moving across networks). They're looking at how you find and fix vulnerabilities, what your incident response plan looks like and whether you actually follow it, and how you're monitoring your systems to detect when attacks are happening. According to the Verizon 2024 DBIR, 68% of breaches involve a human element, which is precisely why the auditor spends disproportionate time on access controls and incident response within this criterion.
In the audit, the auditor verifies that you have documented controls for each of these categories and that they actually work in practice. You'll need to show evidence that you're restricting access to the right people using role-based access controls or similar mechanisms. You'll need to demonstrate that you're monitoring for unauthorized access attempts or suspicious behavior. You'll need to produce a documented incident response plan and evidence that you've actually used it when incidents happened. You'll need to show that you have a plan for what to do if a security breach occurs, including notification procedures.
If your audit scope includes Security — and it always does — prepare to invest significant effort in documenting your access controls, incident response procedures, and security monitoring infrastructure. The auditor isn't trying to break into your systems or find every vulnerability. They're evaluating whether you've designed reasonable controls and whether you're actually maintaining them. The bar isn't "perfect security" (which doesn't exist). The bar is "you have thought about the main attack vectors and have controls to mitigate them."
Availability: Why Your Uptime Commitments Matter
Availability evaluates whether your systems are usable when customers need them — and for SaaS companies, data centers, or any service provider with uptime commitments, this criterion directly maps to revenue risk. The auditor is looking at backup and recovery procedures (can you restore service if something breaks?), your change management process (how do you deploy updates without accidentally taking down your own system?), capacity planning (do you have enough resources to handle your expected traffic?), and infrastructure monitoring (do you know when things are failing before your customers start complaining?).
The audit verifies that you have monitoring in place to detect outages, that you can actually recover from failures with your documented procedures, and that you have a documented change management process that prevents accidents. The auditor asks to see your monitoring dashboards or logs, your incident reports showing outages and how you recovered, your capacity planning documentation, and your change management logs showing who deployed what and when. If you're in the business of providing infrastructure or data processing services, Availability might actually be more important to your customers than Security in some contexts because an outage is an immediate revenue and operational impact for them, while a security breach is a potential future impact.
Here's what makes Availability different from just "keeping your systems up." It's about having documented, repeatable processes for maintaining uptime. You could have systems that never go down by accident, but if you don't have a documented change management process and evidence that you're following it, you fail the Availability criterion. The auditor isn't looking for uptime. They're looking for evidence that your uptime is the result of deliberate controls, not luck.
Processing Integrity: Making Sure Data Moves Correctly
Processing Integrity ensures that data remains accurate and complete as it moves through your systems — and a failure here carries real operational and legal weight. This covers data validation (making sure incoming data is correct before you process it), error handling (what you do when data is malformed, incomplete, or doesn't meet your validation rules), and completeness of processing (making sure that all records get processed, none get silently lost or dropped).
This matters because if a customer uploads 1,000 records and 50 of them silently fail to process, that's a Processing Integrity failure. If your system silently corrupts timestamps, drops decimal places, or modifies data in ways you don't intend, that's a Processing Integrity failure. If a transaction gets processed twice, that's a Processing Integrity failure. The auditor verifies that you have controls to catch these failures and either fix the data or alert the user that something went wrong. You'll need to show evidence of data validation rules, error logs showing how your system handled bad data, and processes for identifying and remediating data quality issues.
In financial services or healthcare, Processing Integrity is critical because bad data isn't an annoyance — it's a legal and operational liability. A bank can't have transactions silently fail to post. A healthcare system can't have patient records become corrupted. In other industries, Processing Integrity is less central to the risk profile but still important because data corruption erodes trust even if it's rare. The controls here prove that your systems maintain data integrity by design, not by accident.
Confidentiality: Access Control for Sensitive Information
Confidentiality controls restrict who can access data that's supposed to be secret or limited-access — and the key difference from Security is focus. Security is about the entire system perimeter and protecting everything from external attacks. Confidentiality is specifically about protecting data that requires restricted access from internal and external actors alike. This includes access controls specifically for sensitive data, encryption of sensitive data (making sure that even if someone gets the data, they can't read it), logging of who accessed sensitive data so you can detect snooping, and deletion of sensitive data when it's no longer needed.
A company with good Confidentiality controls restricts access to customer billing information to only the accounting team, requires audit logs showing who looked at what and when, and deletes credit card data immediately after payment processing is complete. The auditor verifies that you have role-based or attribute-based access controls in place that restrict sensitive data access appropriately, and that you're maintaining those controls over time. They want to see evidence that the people with access to sensitive data are the people who should have it, and that your access logs show nobody inappropriate is looking at things they shouldn't.
Confidentiality is particularly important for SaaS companies because customer data is inherently sensitive and customers need to know that only the right people within your organization can see their data. This is different from preventing external attackers from getting in. This is about preventing internal access that shouldn't happen. The controls are about treating sensitive data differently from everything else, and about proving that access is restricted and monitored.
Privacy: Doing What You Promised with Personal Data
Privacy shifts the focus from internal controls to external commitments and regulatory compliance — specifically, whether you're doing what you told people you'd do with their personal data. This includes data collection (are you collecting only the data you need or are you hoarding?), notice and consent (did you tell people you were collecting it, and did they agree?), use restrictions (are you using data only for the purposes you said you would?), retention (are you deleting data when you promised to?), and breach notification (do you have a plan to tell people if their data gets out?).
Privacy sounds like a purely legal compliance question, and there's a legal layer, but from the SOC 2 perspective it's about operational controls that support your privacy commitments. The auditor verifies that you have documented privacy policies, that you're following those policies, and that you have procedures for things like honoring data deletion requests, responding to data access requests (critical under GDPR, which imposes fines up to 4% of global annual revenue for violations), or notifying people when a breach happens. You'll need to show evidence of your privacy policies, documentation of how you classify and handle personal data, processes for honoring deletion or access requests, and procedures for breach notification.
Privacy controls permeate operations. You need a data inventory — knowing where personal data lives in your systems. You need access controls preventing unauthorized access to that data. You need retention procedures ensuring data doesn't sit around indefinitely. You need deletion procedures ensuring you can actually remove data when requested. You need processes for responding to data subject access requests. You need incident response procedures that specifically address data breaches. And you need evidence that all of this is actually happening. If you process personal data from EU residents, you'll have GDPR commitments on top of your own privacy policies, and the auditor evaluates whether you're meeting those commitments too.
How the Criteria Interact and Which Ones Apply to You
In practice, most SOC 2 audits evaluate all five criteria, but they don't carry equal weight in every organization. Your scope defines which criteria are most relevant to your business and where the auditor concentrates evaluation effort. A pure infrastructure company focused on cloud hosting or storage emphasizes Security and Availability because customers primarily care about preventing intrusions and ensuring uptime. A data analytics company emphasizes Processing Integrity and Security because customers care that their data is accurate and not breached. A healthcare application emphasizes Security, Privacy, and Confidentiality because those are the deep concerns of healthcare law and HIPAA requirements. A company processing payments emphasizes Processing Integrity and Confidentiality.
The criteria also overlap, which is important to understand. A single control can satisfy multiple criteria at once. Encryption of sensitive data contributes to both Confidentiality (controlling access to sensitive data) and Privacy (protecting personal data). Role-based access controls contribute to both Security (controlling system-wide access) and Confidentiality (controlling sensitive data access). A documented incident response plan contributes to Security and also to Privacy if the incident response includes breach notification procedures. The auditor understands this interconnection and won't double-count controls or create unnecessary duplication. But you should understand it when building your evidence library so you don't miss the ways that a single operational control can provide evidence of multiple criteria.
The scope conversation with your auditor determines which criteria get the most attention and where you concentrate evidence-gathering efforts. Understanding your own scope is crucial for planning your evidence collection and knowing what your auditor will be looking at most closely.
Reading Your Report Through the Lens of the Criteria
When you receive your SOC 2 report, it will be organized around these five criteria (or however many are in your scope). The report has sections for Security, and within that section you'll see subsections describing your access controls, encryption practices, monitoring capabilities, and incident response procedures. You'll see sections for Availability describing your uptime monitoring and change management. You'll see Processing Integrity controls described, Privacy controls detailed, and Confidentiality controls explained. Each section includes the auditor's findings about whether those controls are effective.
Understanding what each criterion covers helps you read the report intelligently. When someone asks to see your SOC 2 report, you can tell them "it covers Security, Availability, and Processing Integrity" and they'll understand what was actually evaluated. If a customer asks whether your report covers Privacy, you can check the scope and give them a direct answer. The report itself becomes much less mysterious when you understand that it's organized documentation of controls in five defined categories, and you understand what each category covers.
The Five Trust Service Criteria — Security, Availability, Processing Integrity, Confidentiality, and Privacy — are the five categories of controls that customers care about most. Understanding what each one measures and which ones your business requires is the foundation for every conversation you'll have about SOC 2 scope, cost, and customer requirements.
Frequently Asked Questions
Which Trust Service Criteria do most SOC 2 audits include?
According to AICPA reporting data, Security is included in 100% of SOC 2 audits (it's mandatory). Availability is included in approximately 92% of reports. Processing Integrity appears in roughly 45%, Confidentiality in about 55%, and Privacy in only 34%. Most SaaS companies include Security and Availability at minimum.
Does including more criteria significantly increase audit cost?
Yes. Each additional criterion adds auditor testing time, evidence collection requirements, and control documentation. Adding one criterion beyond Security typically increases auditor fees by 10% to 20% and internal labor by a similar margin. Adding all five criteria versus Security alone can increase total audit cost by 40% to 60%.
Can we add criteria to our SOC 2 scope after the first audit?
Yes. Expanding scope in subsequent years is common and is a sign of compliance program maturity. The auditor will need to observe and test the additional controls during the next observation period. Expect costs closer to first-year levels for the newly added criteria.
What's the difference between the Confidentiality criterion and the Security criterion?
Security protects the entire system perimeter against unauthorized access from external threats. Confidentiality specifically protects data that has been designated as restricted — controlling who within and outside your organization can access sensitive information. A company can pass Security while failing Confidentiality if it prevents external attacks but allows unrestricted internal access to sensitive data.
Do we need the Privacy criterion if we already comply with GDPR?
GDPR compliance and the SOC 2 Privacy criterion overlap significantly but are not identical. GDPR is a regulatory requirement with enforcement penalties up to 4% of global annual revenue. The SOC 2 Privacy criterion evaluates operational controls supporting privacy commitments. Including Privacy in your SOC 2 scope provides third-party verification of your GDPR-supporting controls, which is valuable for customers conducting vendor due diligence.
Which criterion matters most for a SaaS company?
Security and Availability. Security is mandatory and addresses the highest-risk attack vectors. Availability directly maps to uptime commitments and SLA obligations that SaaS customers care about most. Together, these two criteria cover the vast majority of what enterprise procurement teams evaluate when reviewing a SaaS vendor's SOC 2 report.