SOC 2 Trust Services Criteria in Plain English: Side‑by‑Side Decoder for Security, Availability, and Beyond

When SOC 2 Stops Being Abstract and Starts Costing You Deals

THE CALL WITH THE ENTERPRISE BUYER ENDS ABRUPTLY.

Your product demo landed, your pricing was fine—then procurement asked for your latest SOC 2 Type 2 report and a breakdown of which Trust Services Criteria you cover.

You mumbled “Security… and some others,” promised to “get back with details,” and watched the opportunity quietly die in the CRM.

The Trust Services Criteria (TSC) are where many otherwise‑mature teams lose the plot. This article decodes Security, Availability, Processing Integrity, Confidentiality, and Privacy in plain English.

It shows how they fit together and explains how to operationalize them with modern tooling—without overscoping yourself into a multi‑year science project.

What You’ll Learn

How the five SOC 2 Trust Services Criteria relate to each other and to the Common Criteria (CC1–CC9).
What “good enough” looks like for Security versus the optional criteria in practical control terms.
How to design controls and evidence that clearly map back to the TSC (and survive a Type 2 audit).
Where automation platforms (Drata, Vanta, Secureframe, Sprinto, Scrut, etc.) actually help with each criterion—and where they don’t.
A scoping strategy that avoids the most expensive mistake: adding criteria you don’t need yet.
The counter‑intuitive lesson seasoned teams learn only after their second or third SOC 2 cycle.

SOC 2 in One Page: How the Trust Services Criteria Fit Together

SOC 2 evaluates you against five Trust Services Criteria: Security (mandatory), plus optional Availability, Processing Integrity, Confidentiality, and Privacy.

Security is expanded through the Common Criteria (CC1–CC9) and effectively powers everything else. In practice, most organizations start with Security alone, then add one or two optional criteria as customer pressure and internal maturity grow.

Thinking of the TSC as a layered model—rather than five disconnected pillars—makes scoping and control design far easier.

The Five Criteria, Side by Side

Security (Required): The foundation. Prevents unauthorized access, use, disclosure, modification, or destruction of systems and data. Implemented via CC1–CC9: control environment, risk assessment, monitoring, access, ops, change management, and risk mitigation.
Availability (Optional): Systems are available for operation and use as committed or agreed. Think capacity planning, redundancy, backup, and disaster recovery.
Processing Integrity (Optional): Systems process data completely, validly, accurately, timely, and only when authorized. It’s about correct processing, not perfect data.
Confidentiality (Optional): Protects information designated as confidential (IP, non‑public financials, deals, internal roadmaps) over its lifecycle.
Privacy (Optional, Biggest Lift): Governs personal information in line with AICPA’s Generally Accepted Privacy Principles (GAPP): consent, data minimization, individual rights, disclosure, retention, and breach handling.

Key Takeaway
Security (CC1–CC9) is mandatory and does 80% of the heavy lifting. Optional criteria mostly add additional assurances on top of the Security baseline; they do not replace it.

Why the Common Criteria Matter So Much

The Security TSC is defined through nine Common Criteria:

CC1 – Control Environment: Tone at the top, policies, and code of conduct.
CC2 – Communication & Information
CC3 – Risk Assessment
CC4 – Monitoring of Controls
CC5 – Control Activities
CC6 – Logical & Physical Access Controls
CC7 – System Operations: Including incident response.
CC8 – Change Management
CC9 – Risk Mitigation: Including vendor risk.

Auditors expect at least two–three controls per CC point of focus to avoid single‑point failure. These same controls are reused when you add Availability, Confidentiality, etc.—which is why getting Security right first is non‑negotiable.

Security (Common Criteria): The Non‑Negotiable Core

Security is mandatory for every SOC 2 report and is where auditors will spend most of their time.

If you can’t convincingly demonstrate Security, the rest of the criteria are irrelevant. At a practical level, Security means you can prove three things:

Your governance is real (CC1–CC5).
Your access and operations are locked down (CC6–CC7).
Your change and vendor risk are under control (CC8–CC9).

Translating CC1–CC9 into Real Controls

For a mature cloud/SaaS environment, the core Security controls typically look like this:

Control Environment (CC1)
- Approved, version‑controlled security policies (information security, acceptable use, change management, incident response, vendor management).
- Code of conduct and background checks for relevant roles.
Risk Assessment & Monitoring (CC3, CC4)
- Formal risk register with documented likelihood/impact and owners.
- Periodic risk reviews and continuous control monitoring dashboards in your SOC 2 platform.
Logical & Physical Access (CC6)
- SSO + MFA for all admin and production access.
- Role‑based access control (RBAC) and least privilege.
- Timely provisioning/deprovisioning tied to HR events.
- Physical access controls for offices/data centers where relevant.
System Operations & Incidents (CC7)
- Centralized logging, defined alert thresholds, and documented on‑call rotations.
- Incident response plan, with at least one tabletop exercise per year and incident logs.
Change Management (CC8)
- Ticket‑ or PR‑based change process with approvals and testing.
- Separation of duties for production changes where feasible.
Risk Mitigation & Vendors (CC9)
- Vendor inventory, risk assessments, and security reviews (SOC 2 / ISO reports, DPAs).
- Documented complementary user‑entity controls (CUECs) for major subservice orgs.

Modern tools like Drata, Vanta, Secureframe, Sprinto, and Scrut automate much of the evidence for these controls: user lists and MFA status from Okta, change approvals from Jira, pipeline protections from GitHub, vendor questionnaires and SOC 2 uploads, and so on.

Mini‑Checklist – Security “Day 1” Must‑Haves

Centralized, approved security policy set (incl. access, incident, change, vendor)

SSO + MFA on all core systems and cloud consoles

Quarterly user access reviews for production and admin roles

Central log collection with alerting on critical events

Documented, tested incident response plan

Vendor inventory and basic risk questionnaire for each critical third party

If you can’t confidently tick these, you are not ready for a credible SOC 2 Type 2 Security scope—no matter what a tool dashboard says.

Availability, Processing Integrity, Confidentiality, Privacy: What They Really Mean

The optional criteria are where scope (and costs) explode if you’re not deliberate. They also carry real commercial value when aligned to your product.

Availability: Uptime and Resilience

Availability asks: Can customers rely on your service to be there when they need it, as you promised?

Controls typically build on Security and include:

Capacity management and scaling.
Redundant infrastructure (multi‑AZ, backups, failover).
Documented, tested disaster recovery (DR) and business continuity (BCP).
Uptime monitoring and incident communications.

If your SLAs or business model are uptime‑sensitive (CI/CD, payments, infrastructure), Availability is often the first optional TSC to add.

Key Takeaway
Most Availability evidence already exists if your SRE/DevOps function is competent—monitoring, DR tests, backup reports. The work is organizing and proving it over time.

Processing Integrity: Correctness of Processing, Not Perfection of Data

Processing Integrity ensures systems perform their functions:

Completely – All relevant transactions are processed.
Validly & Accurately – No unapproved or corrupted processing.
Timely – Within expected windows.
Authorized – Only through approved paths.

Classic candidates include billing engines, order routing, and financial calculations.

An e‑commerce platform can pass Processing Integrity even if a customer types the wrong shipping address; what matters is whether the order flows through your system as designed.

This TSC is heavy on application‑level controls: input validation, reconciliations, error queues, and audit trails. Generic SOC 2 tools help with workflow and evidence, but they cannot design these controls for you.

Confidentiality: Protecting “Sensitive but Not Personal” Data

Confidentiality covers non‑public data your contracts or policies call “confidential”: source code, internal financial plans, customer pricing, and M&A documents.

Controls include:

Data classification (public/internal/confidential).
Encryption at rest and in transit for confidential data.
Need‑to‑know access and logging.
Retention and secure disposal (deletion, shredding, secure wipe).

Security (CC6) already does most of the heavy lifting here. Confidentiality formalizes those protections around specific data sets and commitments.

Privacy: The Biggest Incremental Lift

Privacy is where many organizations overscope themselves into pain. It adds eight points of focus around:

Notice and transparency.
Choice and consent.
Collection and data minimization.
Access and correction rights.
Disclosure and onward transfer.
Security for personal data.
Retention and disposal.
Handling privacy incidents and complaints.

If you are not substantially processing personal data (especially in regulated ways), adding Privacy to your first SOC 2 is usually a poor trade‑off.

You can address buyer concerns with your Security + Confidentiality posture and your separate privacy program.

Pro Tip
Treat Privacy as an “advanced specialization.” Don’t add it because it sounds impressive; add it when your data flows, legal obligations, and customer base clearly demand it—often after at least one full Security‑only Type 2 cycle.

Designing Controls That Actually Map to the Criteria

Auditors don’t grade you on how pretty your policies are; they grade you on whether you have clear control objectives, operating controls, and evidence that ties back to each TSC and CC.

A Simple Design Pattern: Objective → Control → Evidence

For each relevant point of focus:

Objective – What must be true?
- Example (CC6): “Only authorized personnel can access production databases.”
Control – What process/tech enforces it?
- SSO + MFA, RBAC, joiner/mover/leaver process, and quarterly access reviews.
Evidence – What artifacts prove it over the period?
- Identity provider exports, access review attestations, HR tickets, and logs.

Compliance platforms shine at layers 2 and 3: they pull the data that shows your controls are operating. But you still own the objectives and design.

Key Takeaway
If you can’t articulate the objective and the control in one or two sentences each, the evidence your tool collects will look arbitrary to an auditor.

Reusing Controls Across Multiple Criteria and Frameworks

Because the Common Criteria map closely to ISO 27001, NIST CSF, and even GDPR, a well‑designed control almost always supports multiple obligations:

An MFA‑enforced SSO setup:
- SOC 2 Security (CC6), Confidentiality, Privacy.
- ISO 27001 Annex A access controls.
- GDPR’s “security of processing.”
Vendor risk management:
- SOC 2 CC9.
- ISO supplier controls.
- GDPR Art. 28 processor obligations.

Platforms like AuditBoard, Drata, Secureframe, Sprinto, Scrut, and Hyperproof come with pre‑mapped control libraries so a single control can be linked once and reused across many criteria.

Using Tooling to Operationalize the Trust Services Criteria

The TSC are abstract by design; operationalizing them is where SOC 2 software earns its keep. Without tools, you are left managing 150+ controls with spreadsheets and screenshots.

Where Automation is Indispensable

Across leading platforms, several capabilities are now “table stakes”:

Automated Evidence Collection
- Cloud configs (AWS/Azure/GCP): encryption, network rules, backups.
- Identity: MFA status, group membership, SSO enforcement.
- HRIS: joiner/mover/leaver events.
- Code and CI/CD: protected branches, required reviews, pipeline logs.
- Ticketing: incident and change records.
Continuous Testing and Alerts
- Vanta advertises 1,200+ hourly tests across 375+ services.
- Drata, Secureframe, Sprinto, Scrut, and Scytale implement similar continuous checks.
- Deviations (e.g., a public S3 bucket) generate alerts and remediation tasks.
Integrated Risk and Vendor Management
- Central risk registers with AI‑assisted scoring.
- Vendor inventories, questionnaires, SOC 2 / ISO uploads, and risk ratings.
- Mappings from risks to controls to evidence (especially for CC3 and CC9).

Mini‑Checklist – What Your SOC 2 Platform Should Do Out of the Box

Integrate with your primary cloud(s), IdP, HRIS, code host, and ticketing tools

Provide pre‑mapped SOC 2 control library aligned to CC1–CC9

Run continuous configuration tests with alerting, not just point‑in‑time checks

Offer a risk register and vendor risk workflows tied to controls

Provide an auditor‑friendly portal or export model

Where Tools Don’t Replace Real Work

Research is blunt on this point: tools identify gaps; they do not fix them.

They can show that ex‑employees still have access; they can’t fix poor HR–IT coordination.
They can flag missing DR tests; they can’t convince leadership to prioritize running one.
They can centralize vendor questionnaires; they can’t decide your risk appetite.

Developer‑centric tools like Aikido Security complement compliance platforms by actually remediating vulnerabilities (e.g., AI‑generated code fixes in pull requests), but you still need governance around risk acceptance and rollout.

The Counter‑Intuitive Lesson Most People Miss

The lesson most teams miss until the second or third SOC 2 cycle is this:

Maximizing value from SOC 2 is less about adding criteria and more about continuously tightening Security.

Many organizations assume progress means expanding from Security into Availability, Confidentiality, Processing Integrity, and Privacy as quickly as possible.

In reality, the biggest improvements in both audit outcomes and real‑world risk reduction usually come from:

Deepening CC6 (access) and CC7 (operations) with better IAM hygiene, logging, and incident response.
Maturing CC3 (risk assessment) and CC4 (monitoring), so continuous monitoring actually feeds decisions.
Systematically managing CC9 (vendor risk) as supply‑chain attacks become the dominant failure mode.

Optional criteria can absolutely differentiate you, especially in regulated or uptime‑sensitive markets. But adding them on top of a wobbly Security foundation creates complex reports that impress nobody and are fragile under real‑world stress.

In other words: treat Security as a product you iterate, not a box you tick once before “moving on” to more glamorous criteria.

Key Terms Mini‑Glossary

SOC 2: An AICPA attestation report that evaluates controls over Security, Availability, Processing Integrity, Confidentiality, and Privacy for service organizations.
Trust Services Criteria (TSC): The five high‑level categories (Security, Availability, Processing Integrity, Confidentiality, Privacy) SOC 2 reports are scoped against.
Common Criteria (CC1–CC9): The nine mandatory criteria under the Security TSC covering control environment, risk assessment, monitoring, access, operations, change, and risk mitigation.
Type 1 Report: A SOC 2 report that opines on the design of controls at a single point in time.
Type 2 Report: A SOC 2 report that opines on both design and operating effectiveness of controls over a defined period (usually 3–12 months).
Complementary User‑Entity Controls (CUECs): Controls customers must implement on their side to rely on your SOC 2 report (for example, restricting who can access your admin console).
Risk Register: A central log of identified risks, their likelihood/impact, owners, and mitigation plans, commonly embedded in SOC 2/GRC platforms.
Vendor (Third‑Party) Risk Management: Processes and controls for assessing and monitoring the security of third‑party service providers, mapped mainly to CC9.
Continuous Monitoring: Ongoing automated tests of control states (for example, hourly checks for MFA), as opposed to annual point‑in‑time reviews.
Bridge Letter: A management‑issued letter that asserts no material changes occurred between the end of the SOC 2 audit period and a later date.

FAQ

How should an engineering‑heavy SaaS choose which Trust Services Criteria to include?

Start with Security only unless there is a clear, current commercial driver for more.

Add Availability if your SLAs or product category make uptime a core buying criterion; add Confidentiality if you hold substantial non‑public business data for customers.

Leave Processing Integrity and Privacy for later unless your system logic or personal‑data processing are central to your value proposition.

Is it worth doing a Type 1 report, or should teams go straight to Type 2?

Type 1 can be useful as a tactical milestone or marketing signal, but sophisticated buyers increasingly treat it as preliminary.

If your controls are reasonably mature, many practitioners recommend going straight to Type 2 and using a readiness assessment (often supported by a SOC 2 platform) to de‑risk the first audit instead of paying for both.

How do automation platforms map to the Trust Services Criteria in practice?

They primarily operationalize Security and parts of the optional criteria by:

Pulling evidence for CC1–CC9 controls.
Continuously testing configurations.
Orchestrating access reviews.
Centralizing risk and vendor data.
Exposing auditor‑ready views.

They do not remove the need to design process‑level controls for things like Processing Integrity or Privacy.

Can a company be “over‑scoped” on SOC 2?

Yes. Including criteria like Privacy when you handle minimal personal data, or Processing Integrity when your system has little transactional logic, increases audit cost and operational burden without commensurate value.

Guidance across sources emphasizes risk‑ and customer‑driven scoping rather than “all five TSCs by default.”

How do SOC 2 TSC map to other frameworks like ISO 27001 or NIST CSF?

The Common Criteria align closely with ISO 27001 Annex A controls and NIST CSF functions.

For example, CC3/CC4 align with NIST “Govern” and “Monitor,” and CC6 maps to ISO access‑control clauses. Many platforms leverage official AICPA mappings so one control and its evidence can satisfy multiple frameworks simultaneously.

What’s the biggest control failure auditors still see under Security?

Access control remains the perennial weak point:

Delayed deprovisioning of ex‑employees and contractors.
Over‑privileged accounts.
Incomplete access reviews.

These map directly to CC6 and often drive exceptions in Type 2 reports, even for otherwise mature organizations.

Conclusion

In that earlier sales call, the question the buyer really asked wasn’t “Do you have SOC 2?”—it was “How well have you operationalized the Trust Services Criteria that matter to us?”

Understanding the TSC in plain language is the first step:

Security (CC1–CC9) is the mandatory backbone that underpins everything.
Availability, Processing Integrity, Confidentiality, and Privacy are targeted assurances you add when there is clear risk and revenue justification.
Good controls follow a simple pattern of objective → control → evidence and should be reusable across frameworks.

Modern SOC 2 platforms make it feasible to run this as a continuous program rather than an annual scramble, but they cannot choose your scope or design your governance. That part is still on you.

Treat the Trust Services Criteria as a design brief for how your organization should actually work—day in, day out.

If you get that right, the report becomes more than a procurement artifact; it becomes a credible, continually refreshed signal that your security and reliability are not just marketing copy, but verifiable operational reality.

SOC 2 Trust Services Criteria in Plain English: Side-by-Side Decoder for Security, Availability, and Beyond