The SOC 2 Trust Services Criteria: Which of the Five Do You Actually Need?

Meet the Five Criteria Deciding Whether You Pass or Fail

The SOC 2 Series • The Trust Services Criteria, Broken Down

Welcome back. Earlier, we established the basics, what SOC 2 is, who introduced it (hi, AICPA), and why it’s become the unofficial cover charge for doing business with anyone who has a legal department. If you skipped that one, no judgment, but you might want to circle back before this gets technical. (https://regodit.com/blog/soc-2-introduction-complete-guide/)

Today we’re opening the hood. Every SOC 2 report is built on five categories called the Trust Services Criteria (TSC), think of them as five separate exams your company can sit for, except you only have to pass one of them, and the other four are electives you take based on what your business actually does. Confusing? A little. But by the end of this post, you’ll know exactly which exams apply to you, which one nobody gets to skip, and how to figure out your own personal syllabus.

Let’s meet the five.

1. Security: The One Nobody Gets to Skip

If SOC 2 were a university, Security would be the mandatory core curriculum. Officially known as the Common Criteria, it is the only one of the 5 trust services criteria SOC 2 requires for every single organization, full stop.

What does it actually measure? In plain terms: are you protecting your systems and data from people who shouldn’t be inside them?

This covers the foundational mechanics of trust:

• Who has access to what, and how tightly that access is controlled.
• How you detect and respond to security incidents.
• Whether changes to your systems go through a review before they go live.
• How you monitor for weird, suspicious, or unauthorized activity.

Auditors organize this into nine sub-sections,CC1 through CC9,covering everything from your overall control environment down to how you manage vendor risk. You do not need to memorize the numbering. You just need to know that this is the foundation everything else sits on. Even if you never touch the other four criteria in your life, Security alone gets you a valid SOC 2 report.

Who needs it: Everyone. No exceptions. If the words “SOC 2” appear anywhere near your company, Security is already on the guest list.

2. Availability: Can People Actually Get In?

Availability is the criterion for companies whose entire value proposition depends on one simple promise: we will be up when you need us.

This one asks whether your systems are accessible and operational as promised. It measures uptime, disaster recovery, backups, and how gracefully you handle the inevitable moment a server catches fire. It is less about keeping intruders out,that is Security’s job,and more about making sure the lights stay on for the people who belong inside.

Who needs it: Cloud infrastructure providers, SaaS platforms with uptime guarantees baked into their contracts, hosting companies, and anyone whose customers would riot in a group chat if the product went down for six hours. If you sell an SLA that promises “99.9% uptime,” a procurement team is going to want proof you can back that up. Availability is where you provide it.

Who can skip it: A company where downtime is inconvenient but not existential. An internal analytics tool that nobody is checking at 2 a.m. does not need to prove high availability to the world.

3. Processing Integrity: Is the Math Actually Right?

This is the quiet, unglamorous criterion that matters enormously if your business touches money, transactions, or anything where “close enough” is a liability.

Processing Integrity asks whether your system processes data completely, accurately, on time, and with proper authorization. Basically: when your system says a transaction went through, did it actually go through correctly? No duplicated charges. No silently dropped records. No rounding errors that quietly cost someone their rent money.

Who needs it: Payment processors, fintech platforms, trading systems, billing software, e-commerce checkout providers, and payroll systems. Anywhere numbers move and accuracy is not optional. If a bug in your system could mean someone gets charged twice or a transaction vanishes into the void, this is your criterion.

Who can skip it: A project management tool or a content platform where nothing being “processed” carries financial or transactional consequences.

4. Confidentiality: Keeping the Vault Locked

Confidentiality zeroes in on protecting information that has been specifically designated as sensitive. Think contracts, business strategies, source code, intellectual property, financial reports, or anything covered under an NDA.

It is about controlling who can access that information, how it is stored, and,just as importantly,how it is properly destroyed when it is no longer needed.

There is a subtle but critical difference between this and Privacy. Confidentiality protects business-sensitive information. Privacy protects personal information. A trade secret is a confidentiality issue. A home address is a privacy issue.

Who needs it: B2B SaaS companies handling client contracts or proprietary data, companies bound by NDAs with enterprise clients, legal tech platforms, and anyone whose customers would be genuinely alarmed if their strategic roadmap leaked. If your contracts include confidentiality clauses (and most enterprise contracts do), your buyers may want to see this criterion covered.

Who can skip it: A consumer app with no real confidential business data changing hands beyond standard user accounts.

5. Privacy: Handle Personal Data With Care

Privacy is the one that tends to raise eyebrows, largely because it is often the most demanding to implement.

It governs how personal information,names, addresses, emails, health data, financial identifiers, anything that identifies an actual human being,is collected, used, retained, disclosed, and eventually disposed of.

This criterion has the most granular requirements of the bunch, because personal data comes with the most ways to go wrong: over-collecting it, keeping it too long, sharing it without consent, or failing to properly delete it when asked. If your company operates anywhere near data privacy regulations like GDPR, Privacy is where SOC 2 and those regulations start talking to each other.

Who needs it: Companies handling significant volumes of consumer personal data, healthcare-adjacent platforms, HR and recruiting tech, marketing platforms built on user data, and anyone whose enterprise buyers specifically demand it in writing.

Who can skip it: Interestingly, more companies than you might expect. Many SaaS businesses satisfy their customers’ privacy concerns through solid Security and Confidentiality controls, paired with a separate internal privacy program. They only formally scope in the Privacy TSC when a specific enterprise buyer insists.

So… Which Criteria Do You Actually Need?

Here is the cheat sheet version, because you did not come here for suspense:

• Security: Mandatory. No discussion. Applies to literally everyone.
• Availability: Add it if uptime is part of what you contractually promise customers.
• Processing Integrity: Add it if your system handles transactions, payments, or anything where accuracy has consequences.
• Confidentiality: Add it if you handle business-sensitive data under NDAs or contracts.
• Privacy: Add it if you collect meaningful personal data and a buyer is specifically asking for it.

The honest, slightly liberating truth about SOC 2 mandatory requirements: you are not supposed to check every box.

A common,and expensive,mistake companies make is piling on extra criteria just to look thorough, without any actual business reason behind it. Every additional criterion means more controls to design, more evidence to collect, and more cost, all for a category your customers may not even care about.

A Quick Way to Self-Diagnose

Ask yourself these questions, and let the answers do the deciding:

1. Do I promise customers uptime in a contract or SLA? → Availability
2. Does money, a transaction, or a critical calculation move through my system? → Processing Integrity
3. Do my contracts include confidentiality or NDA clauses over business data? → Confidentiality
4. Do I collect meaningful personal information, and is a buyer explicitly requiring proof of how I handle it? → Privacy

If the honest answer to a question is “not really,” that criterion probably does not belong in your report yet. Most companies, especially in their first SOC 2 cycle, start with Security alone. They get comfortable with the process and layer on additional criteria only when a specific customer or contract demands it.

There is no prize for over-scoping your first audit.

The Reassuring Part

There is good news buried in all this: many of the controls you build for one criterion quietly do double duty for the others.

Access management, for instance, supports both Security and Confidentiality. Solid change management practices tend to check boxes across Security, Availability, and Processing Integrity all at once. You are not building five separate fortresses. You are building one well-designed fortress that happens to satisfy multiple inspectors.

Coming Up Next

Now that you know which criteria might apply to you, the next natural question is: what does it actually look like when an auditor checks whether you meet them?

That is where the two types of SOC 2 reports come in, and the difference between them is bigger, and more strategic, than most people realize.

In the next edition, Regodit is doing a full breakdown of Type I vs. Type II. We will cover what each one actually checks, how long they take, which one enterprise buyers really want to see, and how to decide which one makes sense for where your company is right now.

See you there.