SOC 2 Trust Services Criteria Explained with Control Examples

SOC 2 can feel abstract until you connect it to the day-to-day controls your team already runs: access reviews, logging, backups, change approvals, incident drills, and vendor checks.

The SOC 2 Trust Services Criteria (TSC) are the evaluation framework auditors use to determine whether those controls are suitably designed and operating effectively.

For startups and growing SaaS companies, the most practical approach is to treat the Trust Services Criteria as structured control categories and intentionally scope which criteria apply based on your service commitments, system boundaries, and data handling practices.

What the SOC 2 Trust Services Criteria Are

SOC 2 is an AICPA attestation framework for service organizations.

The Trust Services Criteria define how auditors assess controls relevant to the security, availability, processing integrity, confidentiality, and privacy of a system.

There are five criteria:

• Security (required in every SOC 2 report)
• Availability (optional, based on scope)
• Processing Integrity (optional, based on scope)
• Confidentiality (optional, based on scope)
• Privacy (optional, based on scope)

Security is often referred to as the Common Criteria because it forms the required baseline.

The other four criteria are included only if they are relevant to the services described in your system description. However, once a criterion is included in scope, all applicable controls under that criterion must be met and tested.

“Optional” refers to scoping, not reduced rigor.

Choosing SOC 2 Scope Without Over-Scoping

A SOC 2 report is only as effective as its scope.

Include criteria that do not reflect your actual service commitments and you create unnecessary operational burden. Exclude criteria that enterprise buyers expect and security reviews may stall.

A practical scoping framework:

What failure would most materially impact customers: breach, downtime, incorrect processing, or data misuse?
What do you contractually commit to: uptime targets, RTO/RPO, confidentiality obligations, breach notification timelines?
What data do you process: internal-only data, confidential business data, or regulated personal information?

Many B2B SaaS companies begin with Security + Confidentiality. Organizations offering uptime guarantees or mission-critical workflows often add Availability.

Scope should reflect your real risk profile and customer expectations, not aspirational positioning.

SOC 2 Type I vs. Type II: What Startups Should Consider

When planning your SOC 2 audit, you must decide between a Type I and Type II report.

A SOC 2 Type I evaluates whether controls are suitably designed at a specific point in time.

A SOC 2 Type II evaluates whether controls are both suitably designed and operating effectively over a defined observation period, typically three to twelve months.

Early-stage companies sometimes begin with Type I to demonstrate initial control design. However, most enterprise buyers prefer a Type II report because it provides evidence of sustained operating effectiveness.

If enterprise sales acceleration is a priority, planning directly for a SOC 2 Type II often avoids duplicative audit cycles.

Security (Required): The Foundation Control Set

Purpose: Protect systems against unauthorized access, unauthorized disclosure, and security events.

Security is mandatory in every SOC 2 report and forms the backbone of the Trust Services Criteria.

Auditors evaluate whether your organization consistently maintains:

• Identity and access management controls
• Secure system configuration
• Formal change management
• Logging and monitoring
• Vulnerability management
• Incident response procedures
• Ongoing risk assessment

Even when additional criteria are included, Security remains the structural foundation of your SOC 2 program.

Security Control Examples Auditors Expect

Access Control

• Multi-factor authentication (MFA) for workforce and privileged users
• Role-based access control
• Periodic access reviews
• Timely deprovisioning

Change Management

• Documented approvals for production changes
• Evidence of testing prior to deployment
• Defined change ownership

Monitoring and Incident Response

• Centralized logging
• Alerting for security-relevant events
• Documented incident response plan
• Post-incident reviews

Control + Evidence Example

Control: “Terminated users lose access promptly.”

Evidence may include:

• HR termination ticket
• Automated deprovisioning log from your identity provider
• Access review confirming removal of access

Auditors test whether controls are operating consistently over time, not whether policies merely exist.

Availability: Reliability, Resilience, and Recovery

Purpose: Ensure systems remain available as committed or agreed with customers.

Availability is relevant when uptime, recoverability, or service continuity are material to your service commitments.

Auditors evaluate whether you:

• Plan for system disruption
• Detect service interruptions promptly 
• Restore service in a predictable timeframe

This criterion commonly aligns with business continuity and disaster recovery controls.

Availability Control Examples

• Scheduled, encrypted backups
• Periodic restore testing
• Defined RTO/RPO targets
• On-call rotations and severity classifications
• Infrastructure monitoring and resilience architecture

If uptime guarantees or operational continuity are part of your contractual commitments, Availability is typically in scope.

Processing Integrity: Accurate, Complete, Timely, and Authorized Processing

Purpose: Ensure that system processing is accurate, complete, timely, and authorized.

Processing Integrity is most relevant when your service’s value depends on the correctness of outputs, such as billing systems, analytics pipelines, financial calculations, or automated workflows.

Auditors assess whether processing produces intended results without unauthorized manipulation.

Processing Integrity Control Examples

• Input validation and structured error handling
• System reconciliations (e.g., orders vs invoices)
• QA gates prior to release
• Monitoring for data pipeline failures
• Review of exception logs

Strong Processing Integrity includes both preventive controls (validation, approvals, test coverage) and detective controls (reconciliations, anomaly detection).

Confidentiality: Protecting Designated Sensitive Information

Purpose: Protect information designated as confidential in accordance with commitments.

Confidentiality extends beyond personal data. It may include:

• Customer confidential business data
• Source code
• Financial data
• Security findings
• Strategic documentation

Your policies must clearly define what constitutes confidential information, and your technical and administrative controls must enforce that definition.

Confidentiality Control Examples

• Encryption in transit (TLS) and at rest
• Data classification frameworks
• Least-privilege access controls
• Periodic access reviews
• Restrictions on bulk exports

Auditors typically validate Confidentiality through encryption settings, data flow documentation, and access review evidence.

Privacy: Personal Information Lifecycle Governance

Purpose: Govern the collection, use, retention, disclosure, and disposal of personal information in accordance with organizational commitments.

The Privacy criterion aligns with the AICPA’s Generally Accepted Privacy Principles (GAPP).

Privacy is typically included when:

• You make explicit privacy commitments within scope
• You define purposes for collecting personal information
• You assume defined responsibilities regarding personal data handling

Merely processing personal data does not automatically require including the Privacy criterion. Inclusion depends on how your system description and commitments are defined.

Privacy Control Examples

• Clear notice and consent mechanisms
• Documented retention schedules
• Deletion workflows with tracking
• Data Subject Access Request (DSAR) procedures
• Privacy training for relevant personnel

Auditors evaluate whether privacy commitments are operationalized, not just documented.

Mapping Trust Services Criteria to Controls and Evidence

Each SOC 2 Trust Services Criterion maps to defined controls and recurring evidence.

Examples:

• Security: access review records, vulnerability scan results, incident logs
• Availability: backup logs, restore test documentation, uptime monitoring records
• Processing Integrity: reconciliation reports, QA documentation, exception logs
• Confidentiality: encryption configurations, permissions reviews
• Privacy: retention schedules, DSAR tickets, consent tracking

Exact testing procedures vary based on scope and auditor methodology.

Turning Controls Into an Audit Narrative

Auditors evaluate:

• Whether controls are clearly defined
• Whether responsibility is assigned
• Whether controls operate consistently
• Whether evidence demonstrates performance over time

A useful control structure:

• What is the requirement?
• Who performs it, and how often?
• What artifact demonstrates execution?

Most audit findings stem from inconsistent execution or missing evidence, not absence of intent.

Common evidence types:

• Identity provider logs
• Cloud configuration exports
• Change approval tickets
• Access review records
• Periodic control attestations

Consistency and documentation maturity make SOC 2 audits predictable.

Where Automation Helps (And Where It Does Not)

SOC 2 programs become inefficient when evidence is fragmented across tools and stakeholders.

Automation improves reliability by:

• Collecting evidence from integrated systems on a defined cadence
• Alerting when controls drift from expected states
• Maintaining structured, auditor-ready documentation

Platforms like Klaay support this model by centralizing SOC 2 controls, automating evidence collection across integrated systems, and maintaining continuous monitoring aligned to the Trust Services Criteria. For lean teams, this reduces manual coordination and keeps audit readiness continuous rather than deadline-driven.

Automation does not replace governance decisions or control ownership.

You still need:

• Clear scoping decisions
• Assigned control owners
• A process for remediating identified gaps

Automation increases efficiency. Operational discipline maintains compliance integrity.

If you’re mapping controls to the Trust Services Criteria for the first time, a centralized system can prevent drift and reduce audit back-and-forth. Klaay is designed to streamline SOC 2 audit preparation for SaaS teams.

Planning Your SOC 2 Program Strategically

Before drafting policies, create a concise scope statement defining:

• In-scope services
• System boundaries
• Data types processed
• Trust Services Criteria included

That scope statement determines:

• Required controls
• Expected evidence
• Audit testing boundaries

Once scope is intentionally defined and controls are operating consistently, the SOC 2 Trust Services Criteria stop reading like compliance terminology and start functioning as a structured security operating model:

• Secure access
• Reliable service
• Accurate processing
• Protected confidential information
• Responsible personal data governance

When implemented thoughtfully, SOC 2 becomes less about passing an audit and more about sustaining operational maturity.