SOC 2 Requirements Explained: What SaaS Companies Actually Need in 2026

There's a moment in every enterprise deal — usually right when things are going well — where the conversation takes a sharp turn. "Love the product. Can you send us your SOC 2?"

That moment keeps showing up earlier and earlier in the buying process. And the companies that have their compliance story together? They're the ones who don't lose momentum when the question lands.

Here's the thing about SOC 2, though. The requirements aren't exactly intuitive. The framework is principle-based rather than prescriptive, which sounds great in theory (flexibility!) but in practice means there's no universal checklist that works for every company. You've got room to tailor your approach. You've also got plenty of room to spin your wheels.

This guide is meant to fix that. We'll walk through what SOC 2 actually asks of you, unpack each Trust Services Criterion without the jargon, and help you figure out which requirements map to controls that matter for your specific situation.

What Is SOC 2, Exactly?

SOC 2 — short for System and Organization Controls 2 — is an auditing framework that comes from the AICPA (the American Institute of Certified Public Accountants). At its core, it's asking one question: how does your organization handle customer data?

The answer gets evaluated across five Trust Services Criteria.

Now, here's where SOC 2 diverges from something like ISO 27001. ISO gives you a control catalog — a list of specific things to implement. SOC 2 doesn't do that. It gives you criteria that your controls need to satisfy, but it leaves the "how" up to you. A licensed CPA firm then audits whether the controls you chose actually work.

What this means in practice: two SaaS companies can both earn a clean SOC 2 report while running completely different control sets. Neither is wrong. The standard cares about whether your controls match your risks — not whether they match someone else's template.

A few terms worth knowing before we go further:

• Trust Services Criteria (TSC): The five requirement categories. Used to be called Trust Services Principles — you'll still see both names floating around.
• Common Criteria (CC): The numbered control points within each TSC that your auditor actually tests.
• Service Organization: That's you. The company providing services.
• User Entities: Your customers — the companies relying on what you provide.
• Complementary User Entity Controls (CUECs): The stuff your customers handle on their end, like managing their own user access. Auditors want to see that you've documented these clearly.

The Five Trust Services Criteria — What They Actually Mean

1. Security (CC1–CC9) — The One You Can't Skip

Security is mandatory. Full stop. Every SOC 2 report includes it, regardless of what else you select. The AICPA treats it as the foundation — they call these the "common criteria" because the other four build on top of them.

Here's what falls under each section:

CC1 — Control Environment. Think of this as governance. Does your leadership team take security seriously in a way that's visible and documented? Are there clear roles and accountability structures? If the answer is "our CTO kind of handles it," that's a gap.

CC2 — Communication & Information. Are your security policies written down? More importantly, do your employees actually know what's in them? Auditors look for evidence that policies are communicated — not just filed in a wiki nobody reads.

CC3 — Risk Assessment. Do you have a systematic way to identify what could go wrong and how bad it would be? This isn't about listing every conceivable threat. It's about showing you've thought through the ones that matter and made deliberate decisions.

CC4 — Monitoring. Controls aren't "set and forget." Auditors want to see how you track whether your controls are actually working over time — internal reviews, automated alerting, management check-ins, that sort of thing.

CC5 — Control Activities. This is the broadest category. Access controls, change management, network security, encryption policies — the specific mechanisms you've put in place to mitigate the risks you identified in CC3.

CC6 — Logical & Physical Access. Who can get into your systems, and how do you make sure it's only the right people? Authentication, authorization, MFA, encryption, and yes — even physical security for any on-prem infrastructure you maintain.

CC7 — System Operations. How do you detect when something's off? This covers infrastructure monitoring, anomaly detection, and incident management. If a server starts behaving strangely at 2 AM, what happens?

CC8 — Change Management. Code deploys, infrastructure changes, configuration updates — all of it. Auditors want to know there's a process that prevents untested changes from hitting production.

CC9 — Risk Mitigation. Vendor management lives here, along with business continuity and disaster recovery planning. Your SOC 2 posture is only as strong as the weakest link in your supply chain.

If you're a SaaS company, expect to spend about 80% of your effort on Security. This is where access management, encryption, logging, vulnerability scanning, and incident response all live. It's not something you bolt on at the end — it needs to be woven into how you build and operate your product.

2. Availability (A1)

This one's straightforward in concept: is your system up and running when you said it would be? For SaaS companies with enterprise customers, Availability is almost always in scope. Enterprises sign contracts with SLAs, and they expect the infrastructure behind those SLAs to be documented and tested.

What auditors look at:

• A1.1: You're tracking current capacity, monitoring demand, and planning ahead. Not just reacting when things break.
• A1.2: Your backup systems, recovery infrastructure, and environmental protections are designed, built, and maintained to actually meet your availability promises.
• A1.3: You test your recovery procedures. Not "we have a DR plan in a Google Doc somewhere." Actual tests, with documented results.

What this looks like day to day: Published SLAs backed by real architecture decisions. Uptime monitoring that's more than a status page. Backup procedures you've actually restored from (recently). Failover and redundancy design — multi-region, load balancing, the works.

Here's the part people miss: Your SLAs are contracts. If you've committed to 99.9% uptime, your auditor will ask to see historical uptime data, incident logs, and test results that prove the commitment is credible. Saying "we've never had a major outage" isn't evidence — it's a claim.

3. Processing Integrity (PI1)

Processing Integrity is about whether your system does what it's supposed to do — accurately, completely, and on time. If your product processes transactions, runs calculations, generates reports, or transforms data in ways your customers depend on, this criterion matters.

The key control points:

• PI1.1: You've defined what "processing integrity" means for your specific product, based on what customers actually need.
• PI1.2: You use measurable quality objectives — completeness, accuracy, timeliness — to manage how data moves through your system.
• PI1.3: You've got input validation, processing logic checks, and output review built into your workflows.
• PI1.4: Your users can flag when something looks wrong.
• PI1.5: When issues surface, you investigate and fix them promptly. There's a trail showing you did.

Should you include it? If your platform handles financial data, produces reports that drive business decisions, or runs any kind of computation customers treat as authoritative — yes. If you're building a project management tool or a messaging app, probably not. Let your customer contracts be the guide.

4. Confidentiality (C1)

Confidentiality covers information that's been designated as confidential — trade secrets, proprietary data, IP, business plans, customer data governed by NDAs or contractual agreements. It's narrower than Privacy (which deals specifically with personal information).

What the auditor checks:

• C1.1: You know what confidential information you hold, and you manage it deliberately across its full lifecycle.
• C1.2: When confidential information is no longer needed, you dispose of it properly. Not "it's sitting in an old S3 bucket we forgot about."

In the real world, this translates to: Data classification policies that define what "confidential" means at your company. Encryption at rest and in transit for anything that qualifies. Access restrictions that go beyond standard authentication. Retention schedules with actual destruction procedures. And a clear process for what happens to customer data when they churn.

For SaaS companies: If customers are trusting you with contracts, financial information, security documentation, or anything they'd consider proprietary — include Confidentiality. It's especially relevant if you're in the business of handling security questionnaires, legal documents, or compliance artifacts. (Which, if you're reading this blog, you probably are.)

5. Privacy (P1–P8)

Privacy is the most detailed of the five criteria. It covers the full lifecycle of personal information — collection, use, retention, disclosure, and disposal. There are eight sub-criteria, and they map closely to what you'd recognize from GDPR or CCPA.

The quick version:

• P1 — Notice: Tell people what you're doing with their data. Clearly.
• P2 — Choice & Consent: Give them meaningful options.
• P3 — Collection: Only collect what you said you'd collect.
• P4 — Use, Retention & Disposal: Don't use data beyond its stated purpose. Don't keep it longer than necessary.
• P5 — Access: Let people see and correct their own information.
• P6 — Disclosure & Notification: Only share data as agreed, and notify people if there's a breach.
• P7 — Quality: Keep personal data accurate and complete.
• P8 — Monitoring & Enforcement: Actually check that you're following your own privacy policies.

Here's the honest take for B2B SaaS: Most B2B companies skip Privacy in their SOC 2 and handle personal data obligations through separate GDPR or CCPA compliance programs. That's a perfectly valid approach. Include Privacy if your customers explicitly ask for it, or if your product processes consumer-facing PII at significant scale.

Which Criteria Should You Actually Include?

For most SaaS companies, the decision looks something like this:

The simplest way to decide: Look at your customer contracts, SLAs, privacy policies, and marketing claims. If you've made a commitment — explicit or implied — in any of those places, the corresponding criterion should be in your report. Auditors can only test what's in scope, and savvy buyers are starting to ask about criteria beyond just Security.

The Gap Between Requirements and Controls

This is where first-timers get stuck. SOC 2 tells you what needs to be addressed. It says nothing about how.

Take CC6.1 as an example. The requirement is to "restrict logical access to information assets." Okay — but what does that look like in your environment? It could mean:

• SSO with role-based access control
• MFA enforced for every user
• Least-privilege policies managed through a proper IAM tool
• Quarterly access reviews with sign-off documentation

Any combination of those (and others) could satisfy the requirement. The "right" answer depends on your tech stack, your risk profile, and what you've promised customers.

This ambiguity is by design — but it's also where companies waste enormous amounts of time building controls that are either overkill for their situation or don't quite address what auditors care about.

Working with someone who knows the framework and your technology can save you months. YSecurity specializes in hands-on cybersecurity services for SaaS companies and can help you map controls to your actual risk landscape instead of guessing at what an auditor might want to see. The goal isn't maximum controls — it's the right controls.

Requirements That Catch SaaS Companies Off Guard

Vendor management (CC9.2). Your SOC 2 isn't just about your systems. Auditors want to see how you vet and monitor the third-party services your product depends on — AWS, Stripe, your logging provider, your CI/CD toolchain. Most SaaS companies rely on somewhere between 20 and 50+ vendors. Documenting risk assessments for all of them is a bigger project than people expect.

Policy documentation. Every control needs a written policy behind it. Auditors don't accept "this is how we do things" — they want to see the documented policy, evidence that it's followed, and proof that someone checks whether it's working. If your security practices live in tribal knowledge rather than written documents, start there.

Continuous evidence for Type II. A SOC 2 Type I report looks at your controls on a single date. A Type II report looks at them over a period — usually 6 to 12 months. That means one-time screenshots won't cut it. You need ongoing logs, ticket histories, access review records, and monitoring outputs collected consistently across the observation window.

Security questionnaires — before and after the audit. Even while you're still preparing for your SOC 2, prospects will be sending DDQs (due diligence questionnaires) and security questionnaires asking detailed questions about your controls. And once you have the report, the questionnaires don't stop — they just reference it. Responding manually to hundreds of questions per questionnaire, across dozens of prospects simultaneously, is one of the most painful bottlenecks in enterprise sales.

This is exactly why Cyberbase exists. The platform's Context Engine absorbs your security posture — policies, control documentation, audit reports — and then generates accurate responses to DDQs and security questionnaires, getting smarter with each interaction. The Augment Code team (whose CISO, Jon McLachlan, co-founded Cyberbase) used the platform to work through 155 contracts and save 743 hours in a single year. That's a 13:1 return on investment.

And here's what makes it stick: Cyberbase includes a free-forever Trust Center where prospects can browse your compliance documentation and self-serve answers before a sales call even happens. Competitors charge $6,000 to $15,000+ a year for comparable functionality. Cyberbase gives it away. Permanently.

A Practical Framework for Mapping Requirements to Controls

If you want a structured approach (and you should), here's how to translate SOC 2 criteria into work you can actually assign and track.

Step 1 — Scope your report. Decide which Trust Services Criteria apply to your organization. Map each one to customer commitments, contractual language, and regulatory requirements you're subject to.

Step 2 — Run a gap analysis. Take your current controls and compare them against each criterion you've selected. Where are you already solid? Where are there holes?

Step 3 — Design controls for the gaps. For every gap, define a control: who owns it, how often it runs, and what evidence it produces. Be specific. "We review access quarterly" is weak. "The IT lead reviews all active user accounts in Okta every Q1/Q2/Q3/Q4 and documents approvals in Jira" — that's auditable.

Step 4 — Implement and document everything. Turn designs into reality and build the paper trail as you go. Policies, procedures, screenshots, configs, training records, access logs — all of it matters.

Step 5 — Start monitoring before your audit window opens. This is critical for Type II. Get automated monitoring, regular access reviews, and internal assessments running before the observation period begins. You can't retroactively create evidence for months that already passed.

Step 6 — Bring in your auditor. Choose a CPA firm with SaaS experience. Share your control matrix, hand over the evidence, and work collaboratively through the examination. No surprises.

After the Audit: Where Cyberbase Fits

Here's something that doesn't get said often enough: SOC 2 compliance isn't a destination. The audit report is a milestone, but the operational work — responding to questionnaires, maintaining documentation, keeping your public trust posture current — that's ongoing. Every quarter. Every deal.

Cyberbase is an AI-native platform built for this lifecycle:

• DDQ & security questionnaire automation. The Context Engine ingests your SOC 2 report, policies, and control documentation, then produces context-aware responses that reflect your actual posture — not generic boilerplate. It compounds: every interaction makes it more accurate.
• Trust Center. A public-facing page where prospects browse your compliance docs, download what they need, and answer their own questions before your team ever gets involved. Free. Forever. No annual contract, no usage caps.
• AI contract redlining. The compliance conversation often leads straight into contract negotiation. Cyberbase handles that transition too — flagging risk in redlines, suggesting edits, and compressing legal review cycles.

The SaaS companies closing enterprise deals fastest right now aren't just compliant. They've made compliance frictionless — for their own teams and for the people buying from them.

You can get access to the Cyberbase for free. We’re SOC 2 compliant.