Trust Services Criteria: what are you tested on in SOC 2?

SOC 2 is not one standard with a fixed checklist. It is a framework from the AICPA  with five categories: the Trust Services Criteria (TSC) . You choose which ones are relevant to your business. Security is mandatory, the rest is optional. That sounds simple, but the choice has a big impact on scope, costs and on what you need to implement.

This article explains each criterion: what it means, which controls belong to it, and when you should choose it.

The five criteria at a glance

Security (Common Criteria): the foundation

What it is: Protection of your systems and data against unauthorised access, use, disclosure, disruption, modification, or destruction. In plain terms: keeping hackers out, keeping data safe, protecting systems.

This is the only mandatory criterion. Everything revolves around the CIA triad: Confidentiality, Integrity and Availability at security level.

What gets tested:

Access controls

• Multi-Factor Authentication (MFA) on all critical systems
• Role-Based Access Control (RBAC): the right access for the right people
• Least privilege principle: nobody has more rights than they need
• Regular access reviews: check every quarter who still has access
• Onboarding and offboarding procedures: create or close accounts within 24 hours

Network security

• Firewalls with documented rules
• Network segmentation (production separate from development)
• Intrusion Detection and Prevention Systems (IDS/IPS)
• VPN for remote access
• DDoS protection

Encryption

• Data at rest encrypted (databases, storage, backups)
• Data in transit encrypted (TLS 1.2+, no legacy protocols)
• Encryption key management (who has access to the keys?)

Vulnerability and patch management

• Weekly automated vulnerability scans
• Critical patches within 30 days (often faster)
• Dependency scanning for third-party libraries
• Annual penetration testing by an external party

Logging and monitoring

• Centralised logging (all logs collected in a SIEM)
• Log retention of at least 90 days (often 1 year)
• Monitoring and alerting for security events
• Log review procedures (who checks the logs?)

Incident response

• Documented incident response plan
• Assigned roles (incident commander, communications lead, and so on)
• Regular testing (at least an annual tabletop exercise)
• Breach notification procedures (customers, supervisory authorities)

Physical security

• Access controls for data centres (if you run your own hardware)
• For cloud: the SOC 2 of your cloud provider (AWS, Azure, GCP) is often sufficient
• Office security (badge systems, visitor procedures)

Change management

• All production changes via a ticketing system
• Peer review and approval required
• Testing procedures for changes
• Rollback procedures if something goes wrong

Examples of controls:

A SaaS company on AWS:

• MFA required in the AWS Console, GitHub, and Google Workspace
• Engineers have no production access, only via a bastion host with logging
• Databases encrypted with AWS KMS, keys rotated annually
• Dependabot scans dependencies daily, critical vulnerabilities patched within 48 hours
• DataDog collects all logs, PagerDuty alerts on suspicious activity
• Changes via a Jira ticket, a GitHub pull request, and approval from a senior engineer

Availability: uptime and disaster recovery

What it is: Your system, product or service is available for use as agreed. If you promise an SLA (“99.9% uptime”), you must be able to prove you meet it. And if it goes down, you have procedures to get it back up quickly.

When to choose it:

• You have an SLA in your contracts
• Downtime has a direct business impact on customers
• You run mission-critical systems
• You sell to enterprise customers who require 24/7 availability

What gets tested:

Uptime monitoring

• Real-time monitoring of all critical services
• Alerting on downtime or performance degradation
• SLA reporting: can we prove we achieved 99.9%?

Capacity planning

• Resource monitoring (CPU, memory, disk, bandwidth)
• Forecasting and scaling procedures
• Load testing to know your limits

Disaster recovery

• Documented disaster recovery plan
• Recovery Time Objective (RTO): how quickly are you live again?
• Recovery Point Objective (RPO): how much data loss is acceptable?
• Regular DR testing (at least annually)

Backups

• Automated daily backups
• Backups stored in a separate geographic region
• Regular restore testing (quarterly): can we really restore?
• Backup retention policy documented

Redundancy

• No single points of failure in critical systems
• Load balancers, multiple availability zones
• Database replication or clustering
• Failover procedures documented and tested

Examples of controls:

A SaaS platform with a 99.9% SLA:

• Multi-AZ deployment in AWS (us-east-1a, 1b, 1c)
• RDS database with Multi-AZ replication
• Application Load Balancer distributes traffic
• Daily automated backups to S3 in a different region
• Quarterly restore tests (last test: 15 December 2025, successful)
• StatusPage.io for uptime transparency
• PagerDuty escalation: critical alert, on-call engineer within 15 minutes

Processing Integrity: data is processed correctly

What it is: Data is processed completely, validly, accurately and on time. In the right order, without errors, without data loss. If you process input X, output Y is consistent and correct.

When to choose it:

• You process financial transactions
• You perform calculations that customers rely on (billing, analytics, reporting)
• Data accuracy is business-critical
• You are a payment processor, accounting software provider, or financial platform

What gets tested:

Data validation

• Input validation: data is checked before processing
• Error handling: what happens with invalid data?
• Data integrity checks: checksums, hashes, validation rules

Processing controls

• Completeness checks: have all records been processed?
• Duplicate detection: no double processing?
• Sequencing: data processed in the correct order?
• Reconciliation procedures: do input and output match?

Quality assurance

• Automated testing of processing logic
• Regular audits of output quality
• Exception handling and logging
• Correction procedures for errors

Timeliness

• Processing happens within defined timeframes
• SLA for processing speed
• Monitoring of processing delays
• Queue management for workloads

Examples of controls:

A payment processor:

• Every transaction gets a unique ID, logged in multiple systems
• End-of-day reconciliation: total input must match total output
• Automated checks: transaction amount matches invoice amount
• Duplicate detection: the same payment_id within 5 minutes is blocked
• Processing SLA: 95% of transactions within 2 seconds
• Failed transactions are retried with exponential backoff
• Monthly reconciliation reports for each merchant

Who this is NOT relevant for:

If you build a CRM, a collaboration tool, or a social media platform where the focus is “store and display” rather than “calculate correctly”, Processing Integrity is probably overkill. Security and Confidentiality are more relevant then.

Confidentiality: protecting confidential information

What it is: Information classified as “confidential” is protected against unauthorised disclosure. This goes further than Security: it covers data classification, who may see what, how you share confidential information, and how you prevent data leaks.

When to choose it:

• You process proprietary information from customers (trade secrets, strategic data)
• You have contractual confidentiality obligations (NDAs)
• You work in a sector where data leaks would be disastrous (legal, finance, healthcare)
• Your customers are competitors who do not want their data leaked

What gets tested:

Data classification

• Documented data classification scheme (public, internal, confidential, restricted)
• All data is classified
• Labels or tags on data so systems know how to handle it
• Regular reviews of the classification

Access controls

• Access based on need-to-know
• Confidential data accessible only to authorised personnel
• Separation of duties: no single person can see all confidential data
• Logging of all access to confidential data

Data handling procedures

• Secure transfer procedures (encrypted channels)
• Secure storage (encryption, access controls)
• Data retention and destruction policies
• Clean desk policy (no confidential printouts left lying around)

Agreements

• NDAs with employees and contractors
• Data Processing Agreements (DPAs) with vendors
• Confidentiality clauses in customer contracts

Monitoring

• Data Loss Prevention (DLP) tools
• Monitoring of data exports (who downloads large datasets?)
• Alerting on unusual access patterns

Examples of controls:

A legal tech platform:

• Data classification: case files = Confidential, billing = Internal, marketing = Public
• Access controls: lawyers see only their own cases, admins see only metadata
• S3 buckets with restrictive policies, no public access
• DLP rules in Google Workspace: no emailing confidential files to personal addresses
• Annual employee training on confidentiality
• NDA signed at onboarding, reminder every year
• Audit log: every access to a case file logged with user, timestamp and action

Overlap with Security: Yes, Confidentiality overlaps a lot with Security. The difference: Security focuses on “keeping hackers out”, Confidentiality focuses on “keeping insiders and authorised users within their lane”. Both matter.

Privacy: handling personal data correctly

What it is: Personal information about individuals is collected, used, retained, disclosed and disposed of in line with your privacy policy and relevant legislation (GDPR, CCPA, and so on). This is the GDPR-like criterion within SOC 2.

When to choose it:

• You process a lot of personal data (names, emails, addresses, health data, financial data)
• You run a consumer-facing app
• Your customers are in Europe (GDPR) or California (CCPA)
• You want to show US customers who do not understand GDPR that you comply with it

What gets tested:

Notice and consent

• Privacy policy is clear and accessible
• Users are informed about data collection
• Consent is obtained where needed (opt-in, not opt-out)
• Cookie banners and tracking consent

Data collection

• Only collect what you need (data minimisation)
• Documented purpose for each data point
• No secondary use without consent

Data quality

• Data is accurate and up to date
• Users can view and correct their data
• Procedures for data accuracy

Data retention and deletion

• Retention policies: how long do you keep data?
• Automatic deletion after the retention period
• Users can submit a deletion request (right to be forgotten)
• Backup deletion procedures

Data subject rights

• Users can submit an access request (a copy of their data)
• Users can submit a portability request (data export)
• Users can object (stop processing)
• Response within 30 days (a GDPR requirement)

Third-party disclosure

• Documented list of which vendors have access to personal data
• DPAs with all processors
• Sub-processor lists publicly available
• Prior notice of new sub-processors

Examples of controls:

A consumer health app:

• Privacy policy in plain English, GDPR and CCPA compliant
• Cookie consent banner (strict mode: no tracking without consent)
• Data collection: only health metrics relevant to app functionality
• Retention: inactive accounts automatically deleted after 2 years
• User dashboard: view your own data, download button, delete account button
• Deletion request by email: processed within 7 days, confirmation sent
• Sub-processor list on the website: AWS, SendGrid, Stripe
• DPAs with all vendors, reviewed annually

GDPR alignment: The Privacy criterion is not the same as GDPR, but there is 70% overlap. If you are GDPR compliant, you already have many Privacy controls. SOC 2 Privacy plus GDPR means you are well covered.

Which criteria should you choose? A practical guide

Adding criteria later

You start with Security only. A year later, customers ask for Availability. Can you add it? Yes.

Process:

• Next audit: expand the scope to include Availability
• The auditor tests all Availability controls from scratch
• You receive an updated report with Security and Availability
• Cost: +15-25% for the added criterion

Timing: You can add criteria at any re-audit. It does not have to happen in the first year.

Advice: Start pragmatically (Security only, or Security + Availability). If customers specifically ask for other criteria, expand then. Do not proactively choose 5 criteria “because you can.”

Cost impact per criterion

More criteria means more controls to implement, more evidence to collect, and more audit time. Choose strategically.

More information

• Step-by-step guide: The 12 steps to SOC 2
• Costs and timeline: What it costs per criterion
• The audit process: What exactly the auditor tests
• Common controls: Concrete examples per criterion
• AICPA Trust Services Criteria : Official source with all points of focus