SOC 2 Trust Services Criteria in Plain English: Side-by-Side Decoder with Real-World Analogies

The auditor’s email hit your inbox at 4:47 PM: “Can you show evidence that this control operated throughout the period?”
You open the SOC 2 tracker and realize you have two problems. One: you’re not even sure which Trust Services Criteria (TSC) this request maps to. Two: the phrase “processing integrity” reads like a math textbook when what you actually need is a simple translation into operational reality.

This post is that translation—plain English, side-by-side, with analogies you’ll remember during audit week.

What you’ll learn

A plain-English decoder for each SOC 2 Trust Services Criterion (Security, Availability, Processing Integrity, Confidentiality, Privacy)
How the Common Criteria (CC1–CC9) fit under Security and why they matter
Real-world analogies that make each criterion “click” (and help you explain it internally)
How scoping choices can reduce cost and effort without weakening trust
Practical evidence examples you can gather continuously (not as a screenshot scramble)

SOC 2 Trust Services Criteria (TSC) in plain English: the side-by-side decoder

Answer-first: The SOC 2 Trust Services Criteria are five categories auditors use to evaluate your controls: Security (required) plus Availability, Processing Integrity, Confidentiality, and Privacy (optional). You select optional criteria based on what your service promises customers and what risks matter most. The fastest way to reduce SOC 2 pain is to scope only what you can defend with real operating evidence.

Elaboration: Here’s the “decoder ring” version you can paste into an internal doc. Think of this as the map you reference before you debate scope, tools, or evidence strategy.

Side-by-side decoder (with analogies)

Security (required): “Only the right people and systems can get in, and we can detect/respond when something goes wrong.”
Analogy:** The building has locks, badges, cameras, a guard desk, and incident drills.
Availability (optional): “The service stays up as promised (or recovers fast) so customers can use it.”
Analogy:** The building has backup generators, fire exits, and a plan when the elevator breaks.
Processing Integrity (optional): “The system does what it’s supposed to do—correctly, completely, on time, and only when authorized.”
Analogy:** The cashier rings up the right items, totals them correctly, and completes the transaction—every time.
Confidentiality (optional): “We protect sensitive business data that’s not necessarily personal.”
Analogy:** The safe for contracts, financial plans, and proprietary recipes.
Privacy (optional): “We handle personal data according to privacy commitments and accepted privacy principles.”
Analogy:** The receptionist follows strict rules for collecting, using, sharing, and deleting visitor information.

Experience signal (from our research): When we researched SOC 2 tooling and practitioner discussions, we repeatedly hit login/token blocks on Reddit and human-verification prompts on Gartner—an uncomfortable reminder that access control and monitoring aren’t theory; they’re live everywhere.

Evidence: Secureframe’s guidance emphasizes that Security is mandatory and other criteria should be chosen based on service commitments and customer demand. Market trends also point toward starting with Security (often plus Availability or Confidentiality) and expanding later.

Mini-checklist: “Am I scoping the right criteria?”

Does the criterion match an explicit customer promise (SLA, contract, product claims)?
Would a buyer reasonably expect assurance here?
Do we have continuous evidence sources (not one-off screenshots)?
Can we explain it in one sentence to Sales and Product?

Security (Common Criteria CC1–CC9): the foundation you can’t opt out of

Answer-first: Security is required in every SOC 2 report, and it’s implemented through the Common Criteria (CC1–CC9). Security is about preventing unauthorized access and reducing the impact of security events through governance, access controls, monitoring, incident response, and change management. If you only do one criterion, it will be this one—so it needs to be real, not performative.

Elaboration: The Common Criteria are often where teams get lost because they sound abstract. Here’s the practical translation:

CC1–CC9 in operational language

CC1 (Control environment): leadership tone, roles, policies, and accountability
CC2 (Communication): how expectations and security info are communicated internally/externally
CC3 (Risk assessment): how you identify and analyze risks (including vendor risk)
CC4 (Monitoring): how you verify controls keep working over time
CC5 (Control activities): the actual procedures people follow
CC6 (Logical & physical access): identity, auth, authorization, physical safeguards
CC7 (System operations): detection, response, vulnerability handling, operational procedures
CC8 (Change management): controlled, approved changes to systems and code
CC9 (Risk mitigation): broader risk response, including third-party/vendor management

Analogy that sticks: Security is the whole “security program” for a venue—not just a lock. It’s the people, procedures, monitoring, and response when something breaks.

What evidence usually looks like (examples):

SSO/MFA enforcement reports from your IdP
Joiner/mover/leaver logs from HRIS + ticketing (offboarding proofs)
Change tickets and approvals from Jira/ServiceNow
Incident tickets and post-incident reviews
Vulnerability scan outputs and remediation tracking
Access reviews (who approved what, when)

Experience signal: Our research also surfaced how hard it is to get “grassroots” practitioner stories due to platform access controls. That friction mirrors what auditors want: proof you’re gating access and logging activity, even when it makes life harder.

Evidence: The AICPA standards note that Security is the only mandatory TSC and that CC1–CC9 cover governance through risk mitigation. They also highlight that auditors often expect redundancy (multiple controls supporting key points of focus) to avoid single-point failures that can lead to qualified opinions.

Key Takeaway: If your Security controls aren’t continuously monitored (CC4) and operationally enforced (CC6–CC8), SOC 2 becomes a yearly scramble—exactly what modern automation tools are built to eliminate.

Availability: “Can customers use the service when they need it?”

Answer-first: Availability in SOC 2 means your system is available for operation and use as committed or agreed—not “we never go down.” It focuses on resilience: redundancy, backups, disaster recovery, and business continuity. You scope Availability when downtime is a material customer risk or you make uptime commitments.

Elaboration: Availability is often misunderstood as “SRE perfection.” In audits, it’s closer to: “We planned for failure, we test our plan, and we can recover.”

Availability analogies

Backups: spare keys and a safe deposit box copy
Disaster recovery: relocating operations when the main office floods
Capacity planning: not selling 500 tickets to a 200-seat room
Monitoring: dashboard alarms when the generator fails its self-test

Evidence examples (what auditors commonly want)

Backup schedules and restore tests (not just “backup enabled”)
Disaster recovery plan + test results (tabletop or restore exercises)
Uptime monitoring and incident history
Capacity/scale policies and alerts (where applicable)

Experience signal: In our tooling research, a recurring theme is that companies want to move away from “point-in-time screenshots.” Availability evidence is one of the easiest places to go continuous—because monitoring and backup logs already exist if you operationalize them.

Evidence: The Trust Services Criteria state Availability addresses reliability and resilience (backup, DR, business continuity). Adding optional criteria increases scope and cost; industry benchmarks report direct audit cost can increase by 20–30% per added TSC, which is why you should only include Availability when it aligns with real commitments.

Pro Tip (scoping): If you don’t have an uptime/SLA promise and downtime wouldn’t materially harm customers, don’t add Availability “for completeness.” Add it when it matches your business reality.

Processing Integrity: “Did the system do the job correctly?”

Answer-first: Processing Integrity evaluates whether system processing is complete, valid, accurate, timely, and authorized. It is not the same as “data integrity” or “our database is correct.” You scope Processing Integrity when customers rely on your system to execute transactions or workflows correctly (payments, orders, approvals, calculations, job runs).

Elaboration: This is the criterion that most often gets mis-scoped because the name feels generic. Here’s the clean mental model:

Processing Integrity vs. data integrity (simple example)

Processing Integrity: An e-commerce system processes an order correctly and in sequence.
Data integrity: The shipping address entered by the customer is correct.

The SOC 2 interpretation explicitly notes that Processing Integrity is distinct from pure data correctness: the process can be correct even if the input is wrong.

Where Processing Integrity shows up in real companies

Payments: authorization, reconciliation, and fraud controls
HR/Payroll: correct calculation and timely processing
Workflow platforms: correct routing, approvals, and audit trails
Data pipelines: job completeness, error handling, reruns, and access controls

Evidence examples

Input validation rules and exception handling logs
Reconciliation reports (system A totals match system B totals)
Job run histories, failure alerts, and documented rerun procedures
Authorization models (who can approve/trigger processing)

Experience signal: We see teams try to “template” this criterion using generic controls. That’s risky. Processing Integrity is where your unique business logic matters, and shallow integrations or one-size-fits-all templates can create a false sense of readiness.

Evidence: The criteria state Processing Integrity is supported by multiple points of focus and is best suited for transaction-intensive environments. This optional criterion adds meaningful operational burden—so it should be customer- and risk-driven.

Mini-checklist: Should you include Processing Integrity?

Would a processing error create financial or safety impact for customers?
Do you perform transactions, calculations, or approvals customers depend on?
Can you produce audit trails (not just policies) showing correct processing?
Do you have error handling and reconciliation as routine operations?

Confidentiality vs. Privacy: the fastest way to stop mixing them up

Answer-first: Confidentiality protects sensitive information designated as confidential (often non-personal), while Privacy protects personal data and requires alignment with privacy principles around collection, use, retention, disclosure, and disposal. Confidentiality is about “secrets”; Privacy is about “people.” If you handle meaningful personal data, Privacy is the heavier lift.

Elaboration: In practice, Confidentiality and Privacy often share controls (access control, encryption), but the governance expectations differ.

Confidentiality (think: “company secrets”)

Examples: proprietary algorithms, internal financials, customer non-public business data, legal documents
Typical controls: classification, encryption, access restrictions, retention/destruction

Privacy (think: “personal data lifecycle”)

Examples: names, emails, IDs, health/HR data (depending on your business)
Typical controls: notices, consent/rights handling, retention limits, disclosure controls, breach notification alignment

Analogy:

Confidentiality is a safe with restricted keys.
Privacy is the entire front desk process for visitor data: what you collect, why, how long you keep it, who sees it, and how you delete it.

Experience signal: One of the research “scars” we hit is how limited public, longitudinal data is on long-term ROI and how often teams over-scope early. Privacy is the most common over-scope mistake: it sounds good in a sales deck, but it’s operationally demanding.

Evidence: The criteria explicitly note Privacy is centered on personal data and aligns with Generally Accepted Privacy Principles, and that it is often the most demanding optional criterion (with more points of focus than others). Confidentiality concerns sensitive non-personal information like intellectual property and financial plans.

Key Terms (mini-glossary)

SOC 2: An AICPA attestation report on controls at a service organization.
Trust Services Criteria (TSC): The five criteria categories used in SOC 2: Security, Availability, Processing Integrity, Confidentiality, Privacy.
Security (Common Criteria): The mandatory TSC, implemented through CC1–CC9.
Common Criteria (CC1–CC9): Security subcategories covering governance, risk, access, operations, change, and mitigation.
SOC 2 Type 1: Evaluates control design at a point in time.
SOC 2 Type 2: Evaluates control design and operating effectiveness over a period (often months).
Evidence collection: Artifacts proving controls operated (logs, tickets, reports, approvals).
Continuous monitoring: Ongoing tests/alerts showing controls stay effective over time.
Vendor risk management: Processes to assess and monitor third parties that affect your security posture.
Control mapping: Linking controls and evidence to SOC 2 criteria (and often other frameworks).

Key Takeaway: If your buyers care about personal data handling, Privacy can be a strong trust signal—but only if you’re ready to operationalize it beyond “we have a privacy policy.”

The Counter-Intuitive Lesson I Learned

Answer-first: The counter-intuitive lesson: SOC 2 gets easier when you stop treating it like documentation and start treating it like systems engineering. The best “compliance work” is often boring operational plumbing—integrations, logs, workflows, and ownership. Tools help, but they don’t replace governance.

Elaboration (grounded in our research scars): Here are the specific lessons we ran into while building our SOC 2 tooling and criteria research at Gradum.io:

Access control is the point—even in research. We were blocked from Reddit discussions without login/developer tokens, and Gartner pages triggered repeated human verification. That friction is exactly what SOC 2 Security expects: identity checks, least privilege, monitoring.
Pricing opacity is real. Most SOC 2/GRC vendors don’t publish full rate cards, so teams underestimate long-term costs and over-optimize for short-term “quick wins.”
Longitudinal ROI data is limited. Lots of claims exist about time-to-compliance improvements, but durable multi-year benchmarks are scarce in public sources.
Tooling can amplify chaos. If your onboarding/offboarding process is unclear, automation will surface more failures—not fewer. That’s good, but it feels worse before it feels better.
Scope discipline beats heroics. Starting with Security (and only adding criteria your service truly commits to) reduces rework and prevents expensive midstream scope creep.

Evidence: Modern SOC 2 platforms exist because manual evidence collection is untenable. Typical SMB automation subscription ranges are USD 6,000–25,000/year, and automation can reduce overall SOC 2 program costs by 50–70% compared to fully manual approaches.

Pro Tip: Before you buy another SOC 2 tool or add another criterion, write a one-page “evidence architecture” doc: what systems produce evidence, who owns them, and how evidence is retained for the audit period.

FAQ: SOC 2 Trust Services Criteria (plain English)

1) Is Security really mandatory in SOC 2?

Yes. Security (the Common Criteria) is required for every SOC 2 engagement; the other four criteria are optional based on scope.

2) Should we start with all five Trust Services Criteria?

Usually no. Experts recommend starting with the criteria closest to being achieved or most demanded by customers—commonly Security, then adding others over time.

3) What’s the simplest way to explain Processing Integrity to a non-auditor?

Processing Integrity means your system completes processing correctly, on time, and only when authorized—like ensuring orders, approvals, or payouts run properly end-to-end.

4) How do Confidentiality and Privacy differ in SOC 2?

Confidentiality protects sensitive information (often non-personal). Privacy covers personal data handling across its lifecycle and is typically more demanding.

5) Do SOC 2 automation tools “do SOC 2 for you”?

No. The reality is clear: tools automate evidence collection and monitoring, but your teams still must operate and remediate the underlying controls.

6) What’s a bridge letter?

A bridge letter is a management-issued letter stating there were no material changes since the last SOC 2 report period. It’s not a new audit report, but it helps cover timing gaps.

7) What’s a realistic cost range for SOC 2 tooling and audits?

SMB SOC 2 automation software often falls around USD 6,000–25,000/year, and Type II audit fees for growing SaaS firms commonly fall around USD 20,000–40,000/year, depending on scope.

Conclusion: closing the loop on that 4:47 PM audit email

That evidence request wasn’t really about a screenshot. It was about translation: “Which criterion is this?” and “What does operating effectiveness look like in our systems?”

Now you have a decoder: Security is your foundation (CC1–CC9). Availability is resilience. Processing Integrity is correct execution. Confidentiality is secrets. Privacy is people.

If you want help turning this into a scoped, evidence-driven SOC 2 plan—criteria selection, control mapping, and a workflow your engineers won’t hate—Gradum.io can help you design a program that stays audit-ready all year, not just during audit season.