The SOC 2 trust principles are five categories of controls: security, availability, processing integrity, confidentiality and privacy. The AICPA now calls them the Trust Services Criteria. Security is the only one every SOC 2 report must include. The other four are optional, and you choose them based on what your service does and what your customers ask of you.
This guide explains what each category covers, how to decide which ones belong in your report, what separates a Type 1 from a Type 2 report, and how to prepare without losing months to avoidable rework. We wrote it for security, GRC and sales leaders at software companies, the people who see SOC 2 from both sides: the audit and the customer questionnaire that follows it.
TL;DR
- SOC 2 has five trust categories: security, availability, processing integrity, confidentiality and privacy. Only security is mandatory.
- "Trust principles" is the older wording. The current AICPA term is Trust Services Criteria (TSC).
- SOC 2 is an attestation by an independent CPA firm, not a certificate issued by a regulator. "SOC 2 certified" is shorthand.
- Type 1 tests control design at one point in time. Type 2 tests design and operating effectiveness over an observation period, and it is what most enterprise buyers ask for.
- Choose categories by your service commitments and customer contracts, not by wanting the longest report.
Table of Contents
- Principles or criteria: what the terms mean
- The five categories at a glance
- How to choose which categories belong in your report
- Type 1 and Type 2: what changes for the trust criteria
- Our perspective: the report is only half the job
- Preparing for the audit: a realistic sequence
- Updated criteria and AI systems
- Where Skypher fits after the report
- FAQ
- Sources
Principles or criteria: what the terms mean
You will see "trust principles," "trust services principles" and "trust services criteria" used almost interchangeably. The older documents used "principles." The AICPA's SOC 2 page describes a SOC 2 examination as a report on controls at a service organization relevant to security, availability, processing integrity, confidentiality or privacy. Those five are the categories, and within each sit the individual criteria an auditor tests.
The criteria are outcome-based. They do not tell you to use a particular tool or write a particular policy. They ask whether your controls, as designed and operated, support the commitments you make to customers. That is why two companies can both pass with very different technology stacks.
Also worth knowing: SOC 2 is technically an attestation, not a certification. As practitioners point out in Pulumi's explainer, no regulator issues a SOC 2 certificate. What you receive is a CPA firm's report with an opinion, and a clean opinion is what buyers care about. DataGuard's guide makes the same point: it is an independent audit report, not a regulator-issued credential.
The five categories at a glance
| Category | Required? | The question it answers |
|---|---|---|
| Security (Common Criteria) | Always | Is the system protected against unauthorized access, unauthorized disclosure and damage? |
| Availability | Optional | Can customers rely on the system being up when you promised? |
| Processing integrity | Optional | Is processing complete, valid, accurate, timely and authorized? |
| Confidentiality | Optional | Is information designated confidential protected as committed? |
| Privacy | Optional | Is personal information collected, used, retained and disposed of as committed? |
The definitions follow the wording in the AICPA's attestation guide, reproduced in PwC's Viewpoint. Here is what each looks like in practice.
Security: the mandatory foundation
Security is built on the Common Criteria, labeled CC1 through CC9. They are aligned with the COSO Internal Control framework, and the AICPA's materials treat them as the base for every SOC 2 report. The series cover the control environment, communication, risk assessment, monitoring, control activities, logical and physical access, system operations, change management and risk mitigation.
In day-to-day terms, auditors will ask for things like:
- Evidence that access is granted, reviewed and removed on a defined schedule.
- Change approvals showing that production changes were reviewed before release.
- Logging and monitoring, plus an incident response process that has actually been exercised.
- Vendor management, including how you assess your own subprocessors.
- Board or leadership oversight of security risk.
Availability
Availability matters when your contracts include uptime commitments or your customers run critical workflows on your service. Auditors look at capacity planning, backups, disaster recovery and whether you test your recovery procedures. It is a frequent add-on for SaaS and infrastructure providers. According to the 2026 SOC 2 Audit Benchmark Report, security-only remains the most common starting point for first-time reports, with security plus availability a frequent next step.
Processing integrity
This category fits services that transform or calculate on customers' behalf: payment processing, billing engines, data pipelines, analytics. The auditor checks that inputs are validated, processing is accurate and complete, and outputs are delivered to the right party. If your product is a simple content tool, you may not need it.
Confidentiality
Confidentiality covers information you have agreed to protect as confidential, such as customer business data, source code or contract terms. Typical controls include encryption, data classification, NDAs and secure disposal. It is common among enterprise-facing providers because large customers write confidentiality obligations into their agreements.
Privacy
Privacy is the most specific category. It concerns personal information: notice, consent, collection limits, use, retention, access rights and disposal. Add it if you act as a custodian of end users' personal data and your customers expect the report to speak to it. It does not replace compliance with privacy laws, and it is not the same as confidentiality.
How to choose which categories belong in your report
Start with your contracts rather than the framework. Pull the last ten security questionnaires and the master agreements from your largest customers, then look for what they actually ask:
- Uptime or recovery commitments in the agreement. Include availability.
- Obligations to keep customer data confidential. Include confidentiality.
- Calculations or transactions you perform for customers. Consider processing integrity.
- Personal data of end users that you control or process. Consider privacy.
- None of the above. Start with security alone and expand at renewal.
Every category you add increases the number of controls, the evidence you collect and the places an auditor can find an exception. It is usually better to deliver a clean, narrower report in year one and widen scope later than to pursue everything at once. Your first-year scope also sets the baseline buyers will compare against next year.
We cover the broader requirements in our SOC 2 compliance requirements guide and the SaaS angle in SOC 2 requirements for SaaS trust and speed.
Type 1 and Type 2: what changes for the trust criteria
The five categories apply to both report types. What differs is the depth of testing.
- Type 1 assesses whether your controls are suitably designed at a single point in time.
- Type 2 assesses design and operating effectiveness over an observation period, typically 3 to 12 months, according to the 2026 benchmark report.
The same report says Type 2 is the standard requirement for most enterprise buyers. Its benchmark data also found Type 2 examinations were more likely to contain at least one exception (76% versus 55% for Type 1) and needed more evidence artifacts, about 1,650 on average against about 900.
That gap comes from sampling. For a Type 2 report, auditors do not review every event. They sample across the observation window, so one missed access review or one change without an approval inside a sample can become a noted exception. The practical lesson is to treat each criterion as a recurring operating habit, not a document you write once. For a side-by-side view, see our Type 1 versus Type 2 comparison, and for the quick-start route, SOC 2 Type 1 as fast-track assurance.
Our perspective: the report is only half the job
We build software that answers security questionnaires, so we see SOC 2 from the point where it meets a buyer. Three observations come from that vantage point.
The report answers fewer questions than teams expect. A SOC 2 report is trusted, but prospects still send questionnaires covering their own policies, subprocessors and architecture. Many of those answers sit in the report itself, in policies, or in earlier responses. The teams that move fastest keep that material in one governed knowledge base instead of hunting through folders each time. That is the idea behind our Smart Security Knowledge Base, where answers carry versioning and a confidence score so reviewers know what to check.
Categories should mirror what you tell customers. If your sales team promises uptime or data confidentiality in questionnaires, the matching categories should be in scope, or the report and the sales claims drift apart. Alignment is easier when security and sales share the same source of truth.
Evidence quality beats evidence volume. The benchmark report's advice is to map documented policies, system configurations and operating logs directly to the criteria, rather than gathering documents for their own sake. We agree, and we would add that the same mapped evidence shortens questionnaire response time later.
— Gaspard
Preparing for the audit: a realistic sequence
Timelines vary by scope, but the 2026 benchmark report puts the end-to-end audit journey at roughly 3 to 9 months. It breaks out the pieces: readiness and remediation often take 4 to 12 weeks, fieldwork by the CPA firm typically spans 6 to 10 weeks, and a Type 2 observation period of 3 to 12 months comes first. Many teams mistake the start of the engagement for the start of the process and are surprised by the calendar.
A sensible order of work:
- Define scope. Decide which systems, locations and categories are in.
- Run a gap assessment. Compare current controls with the criteria and note missing policies, undocumented procedures and absent evidence. episki's audit process guide lays out this step in more detail.
- Remediate. Fix access management, logging and change management first, because those generate the most sampled evidence.
- Start the observation window for Type 2, and automate evidence collection where you can.
- Select your auditor. The report must come from a licensed CPA firm. Our note on SOC 2 auditors covers what to ask.
- Complete fieldwork and review the draft for exceptions before it is final.
- Plan the renewal. SOC 2 is an annual cycle. Buyers look for a report covering the latest 12 months, and an expired one can stall a deal, as DataGuard notes.
Updated criteria and AI systems
The criteria have not been rewritten in years, but the guidance has moved. The 2017 Trust Services Criteria were refreshed with revised points of focus in 2022, and the AICPA still lists that version as current as of October 2026. Practitioners such as Kyudo in its Type II preparation guide say expectations around identity and access management, and around governance of AI systems and training data, have risen under those points of focus. If you ship AI features or use AI agents internally, assume auditors will ask who can act on what, and how you evidence it. For a deeper look at how segregation of duties applies to AI agents in regulated settings, see this guide to audit-ready oversight of AI agents.
Where Skypher fits after the report
Once you hold a SOC 2 report, the work shifts to proving it, again and again. Our Questionnaire Automation Tool parses questionnaires in any format, drafts answers from your approved content with confidence scoring, and connects to third-party risk platforms such as OneTrust and ServiceNow, plus Slack, Teams, Confluence, Notion and SharePoint. Our Trust Center lets buyers see your security posture up front, so fewer questionnaires arrive at all. Pricing is quote-based, so a short demo is the fastest way to see whether it fits your volume.
FAQ
What are the 5 SOC 2 trust principles?
They are security, availability, processing integrity, confidentiality and privacy. Security is required in every SOC 2 report, and the other four are added when they match your service and customer commitments. The AICPA now refers to them as the Trust Services Criteria.
Is SOC 2 a certification?
No. It is an attestation: an independent CPA firm examines your controls and issues a report with an opinion. People say "SOC 2 certified" as shorthand, but no regulator issues a certificate, and buyers care about the report's opinion and its coverage period.
What is the difference between SOC 2 Type 1 and Type 2?
Type 1 evaluates whether controls are designed appropriately at one point in time. Type 2 also tests whether they operated effectively across an observation period, usually 3 to 12 months. Most enterprise buyers ask for Type 2.
Do I need all five categories?
No. Security is mandatory, and the rest depend on your service and contracts. Many first-time reports cover security alone or security plus availability, and teams add categories as customer requirements grow.
Sources
- AICPA & CIMA: SOC 2 Trust Services Criteria
- PwC Viewpoint: Categories of Trust Services Criteria
- Pulumi: What is SOC 2?
- DataGuard: How to get SOC 2 certified
- 2026 SOC 2 Audit Benchmark Report
- episki: SOC 2 audit process
- SOC 2 Trust Services Criteria overview
- Kyudo: SOC 2 Type II Preparation Guide