The 5 Trust Services Categories of SOC 2 Reports

You’ve just gotten the request. Maybe it came from your sales team after a prospect asked for it. Maybe your investors flagged it during due diligence. Either way, someone uttered the phrase “SOC 2,” and now you’re down the rabbit hole of jargon and various confusing acronyms and AICPA documentation trying to figure out what you actually need.

At some point in that research, you landed on “trust services categories” and it has something to do with what is tested in the report. So lets explain it.

What Trust Services Categories Actually Are

The 2017 Trust Services Criteria, published by the AICPA’s Assurance Services Executive Committee, which you can get for free here, defines the framework that SOC 2 audits are built on. The criteria are organized into five categories (hopefully i’m not losing you), each representing a different set of commitments your organization might make to customers about how it handles their data and systems. You need at least one to have a SOC 2 Report engagement.

Those five categories are: Security, Confidentiality, Availability, Processing Integrity, and Privacy.

In practice, Security is the baseline. The rest depend on your service commitments and what you’ve actually promised your customers. So bust out your contracts and start looking at what you may need. After security, the second most common category is confidentiality.

The criteria are outcomes-based, not prescriptive. This means there’s no mandatory checklist of controls you’re required to implement. Each SOC 2 Report issued can be different because the auditor is evaluating whether your controls achieve the outcomes described in the criteria. This is a feature of the SOC 2 that makes it different from other frameworks that have prescriptive controls that outline requirements. It makes the framework apply to many different types of environments.

Category	What it Covers
Security	The baseline for every SOC 2. Covers logical and physical access controls, identity and authentication, network security, encryption, vulnerability management, change management, incident response, and monitoring. Essentially: who can get into your systems, what you’re doing to keep threats out, and how you detect and respond when something goes wrong.
Confidentiality	Whether information designated as confidential is protected from unauthorized access, use, or disclosure. Covers data classification, access restrictions, encryption, retention schedules, disposal practices, and vendor obligations. Applies to business data, trade secrets, and proprietary information, not personal data.
Availability	Do you have SLAs for uptime? Hosted service? A core system for your clients day to day work? They need assurances… Whether your system is accessible for use as committed. Availability covers what you are doing over: uptime monitoring, disaster recovery, business continuity planning, backup processes, capacity planning, and incident handling. This is specific to topics over the resilience of your system! Does not set a minimum performance standard on its own. It holds you to whatever you’ve promised. Your customers can see your independently audited control and confirm that you are meeting your obligations.
Processing Integrity	Whether your system processes data completely, accurately, validly, and on time. Covers input validation, error detection and correction, output accuracy, and processing records. Garbage in, garbage out still applies: if a customer feeds your system bad data and it processes it exactly as designed, that is not a processing integrity failure. A failure is when the system itself breaks the contract, such as a payment processor that correctly receives a $500 transaction but posts it twice, or failes to post, or a data pipeline that silently drops records and delivers incomplete output downstream (yup – saw that once).
Privacy	Whether personal information is collected, used, retained, disclosed, and disposed of appropriately. Covers your privacy notice, consent mechanisms, collection practices, data subject rights, breach notification, third-party data sharing, and ongoing monitoring of compliance. Applies to PII specifically, which is where it diverges from Confidentiality.

Security

The common criteria, which form the backbone of any SOC 2 engagement, are designed specifically to evaluate Security. So, you’re only adding one category, this is the one. The AICPA describes it as protecting information and systems from unauthorized access, unauthorized disclosure, and damage that could compromise availability, integrity, confidentiality, and privacy. In practice, that means controls over things like identity and access management, logging and monitoring, incident response, change management, and protecting against malicious software.

Security doesn’t mean your environment has to be perfect. Its risk based. It means you’ve identified the risks, implemented controls proportionate to those risks, and can demonstrate they’re operating. Compensating controls exist. Documented exceptions with remediation timelines are acceptable. What’s not acceptable is pretending gaps don’t exist or having no evidence your controls actually ran. If you are doing this the first time, consider the processes you have to detect issues and how you should be documenting the gaps in your environment. The framework calls for risk assessments and discussions internally about what is acceptable for the business and how they evaluate the operating performance of your environment.

Availability

This one trips people up because the name sounds more broadly applicable than it is.

Processing integrity addresses whether system processing is complete, valid, accurate, timely, and authorized. The AICPA is explicit that this refers to your processes doing what you say they do, not necessarily the accuracy of the data going into them. If a customer gives you bad data and your system processes it exactly as designed, that’s not a processing integrity failure.

The category is most relevant to companies where the correctness and completeness of data processing is central to the value they deliver. Think financial data aggregators, payment processors, analytics platforms, or anywhere a customer is relying on your system to produce accurate outputs they’ll use for real decisions.

Controls here cover input validation, error detection and correction, output distribution, and record keeping around processing activities.

For a lot of SaaS companies, Processing Integrity won’t be in scope on the first audit. For others, it’s the whole point of the product. Know which one you are before you commit to including it.

Privacy

Privacy is often the category people are most uncertain about. Privacy is the most granular of the five categories and the one with the most moving parts. It covers the full lifecycle of personal information: collection, use, retention, disclosure, and disposal.

Organized around eight areas: notice and communication, choice and consent, collection, use and retention and disposal, access, disclosure and notification, quality, and monitoring and enforcement. The 2022 revisions to the Trust Services Criteria added updated points of focus specifically to address evolving legal and regulatory requirements, and to better differentiate between the obligations of a data controller versus a data processor.

So if you’re a SaaS company processing personal data on behalf of your business customers. In that case, you’re likely functioning as a data processor. Your customers may be data controllers. Your obligations under the Privacy criteria will reflect that.

If you have any PII triggers, does that mean you need to include it? The short answer is no, it doesn’t. Inclusion of the privacy category is based on your service commitments, not just the presence of personal data. That said, if you have documented privacy commitments, a published privacy notice, or customers who specifically ask about privacy controls, then the category may be needed.

How Do You Decide?

Start with your contracts and your terms of service. What agreements do you have currently in place? What are your customers looking to see or get coverage over? What are the risks your customer is considering when trusting you? What have you promised about uptime? What data have you agreed to protect? Have you made any representations about how you process or handle data?

The commitments you’ve made to customers are the right guide for scoping your SOC 2.

Think about what your actual prospects are asking for. Consider what will they eventually ask for features being developed in the pipeline. Look at the security questionnaires hitting your inbox right now.

First-year audits that include Security and Confidentiality, or sometimes just Security alone, are completely normal. Companies add categories over time as their commitments and customer requirements evolve. Trying to scope everything in year one usually creates more overhead than benefit.

If you’re unsure where to draw the line, that’s what a scoping conversation with your auditor is for. The answer should be grounded in what you’ve actually committed to, not what looks most impressive in your sales deck.