SOC 2 Trust Services Criteria Explained

The five Trust Services Criteria structure

The scope decision for SOC 2 is the one most companies get wrong — not because the criteria are complicated, but because companies select criteria based on what they think they should have rather than what enterprise buyers are actually asking for. Adding Confidentiality when no customer has ever requested it means paying for controls and audit coverage that do not move any deal. Excluding Availability when every enterprise prospect asks about uptime SLAs means explaining in every sales cycle why your report does not cover the thing they care about most. The right scoping decision starts with your prospect’s vendor security questionnaire, not with a framework document.

SOC 2 compliance is built on five Trust Services Criteria (TSC) defined by the American Institute of Certified Public Accountants (AICPA). Security is mandatory for every SOC 2 report. The other four — Availability, Processing Integrity, Confidentiality, and Privacy — are optional and chosen based on what your service does and what your customers require.

Understanding which criteria to include in scope is the first strategic decision in SOC 2 planning. A customer-facing SaaS platform handling customer data would scope Security and Availability. A financial calculations engine would add Processing Integrity. A company processing employee personal information would add Privacy. Each criterion maps to a set of control families that auditors will test.

This breakdown shows what each criterion requires in practice, what auditors look for as evidence, and when to include it in your audit scope.

Security (Common Criteria — mandatory)

Security is the foundation of every SOC 2 report. It comprises nine control families organized under the heading “Common Criteria” (CC). These controls cover governance, risk management, system operations, and incident response.

CC1 — Control Environment

The control environment is where organizational accountability and governance live. Controls in this family address:

• Board and management oversight of the security program
• Organizational structure and role clarity
• Delegation of security responsibilities
• Leadership communication of security expectations
• Assignment of security ownership to specific roles

What auditors look for: Evidence that security governance exists above the technical level — that the board or executive leadership has assigned someone to own the security program, that security decisions are documented, that roles and responsibilities are clear in writing. Small companies often fail here by treating security as an IT responsibility without executive visibility.

CC2 — Communication and Information

Controls in this family ensure that security policies, expectations, and requirements are communicated to everyone who needs them — employees, vendors, customers, and regulators.

• Security policies are documented, approved, and made available
• Employees are informed of their security responsibilities
• External parties (vendors, partners, customers) understand their obligations
• Security policies are reviewed and updated regularly
• Communication mechanisms exist for reporting incidents and vulnerabilities

What auditors look for: Proof that employees have read and understood the security policy. Training records showing that new hires complete security training within their first month. Documentation that vendor contracts include security requirements. Incident reporting procedures that are communicated and actually used.

CC3 — Risk Assessment

Risk assessment is the systematic identification and analysis of threats and vulnerabilities to your systems and data. Controls in this family include:

• A documented methodology for conducting risk assessments
• Identification of assets, threats, and vulnerabilities across in-scope systems
• Risk rating and prioritization (high/medium/low or similar scale)
• Documentation of risk treatment decisions (mitigate/transfer/accept/avoid)
• Regular updates to the risk assessment (minimum annually, more frequently when significant changes occur)

What auditors look for: A formal risk assessment completed within the past 12 months. The assessment should cover all systems in the SOC 2 scope. Identified risks should be linked to treatment plans. Risk acceptance decisions (consciously accepting a risk rather than mitigating it) should be documented with business rationale and appropriate approvals. The security risk assessment guide covers the methodology and controls in detail.

CC4 — Monitoring Activities

Monitoring is the ongoing evaluation of whether controls are working as designed. Controls in this family include:

• Regular reviews of control operation and effectiveness
• Monitoring systems that track security-relevant events
• Procedures for investigating control failures or anomalies
• Remediation processes for control deficiencies
• Management review of monitoring results and remediation

What auditors look for: Evidence that you monitor control effectiveness, not just that controls exist. For access controls, this means quarterly access reviews with documented approval or remediation. For change management, it means a log showing that changes went through the approval process. For incident response, it means a ticketing system showing that alerts were investigated. Most SOC 2 exceptions trace back to CC4 deficiencies — a control was designed well but nobody monitored whether it actually operated.

CC5 — Control Activities

CC5 is the broadest control family in the Common Criteria. Where the other families address specific operational domains, CC5 covers all the policies and procedures that actually mitigate identified risks — change management, encryption, access provisioning, and configuration governance. What auditors actually test here is the gap between the policy and the practice. They will pull code commits to verify that your branch protection rule requiring peer review is actually enforced, not just documented. They will query your cloud infrastructure to verify that encryption at rest is enabled on the specific database instances your policy covers. A policy that says the right things but cannot be verified in production evidence produces exceptions in every field it touches.

CC6 — Logical and Physical Access Controls

Access controls determine who can do what on your systems. Controls in this family address:

• Authentication requirements (passwords, multi-factor authentication, single sign-on)
• Authorization and access provisioning (least-privilege principles, role-based access)
• Access provisioning and revocation (onboarding and offboarding procedures)
• Privileged access management (monitoring and restricting admin accounts)
• Physical security (if applicable — data centers, server rooms)

What auditors look for: Multi-factor authentication is enforced on all production systems and cloud consoles. Access is provisioned through a documented process with approval. Quarterly access reviews are conducted with evidence of who reviewed what and what changes were made. Offboarding checklist shows that access was revoked within 24 hours of termination. Privileged accounts (admin, root, database superuser) are tracked separately with additional monitoring.

CC7 — System Operations

System operations controls address how you detect and respond to security incidents and operational failures. Controls in this family include:

• Incident and problem management procedures
• Incident detection and response timelines
• Logging and monitoring of production systems
• Procedures for identifying and addressing security anomalies
• Involvement of appropriate personnel in incident response

What auditors look for: A documented incident response plan that describes detection, containment, and recovery procedures. Evidence that incidents are logged in a ticketing system with dates, actions taken, and resolutions. Monitoring alerts configured for security-relevant events (failed login attempts, privilege escalation, unusual data access, configuration changes). Test results showing the incident response plan has been exercised through tabletop exercises.

CC8 — Change Management

Change management controls ensure that changes to infrastructure, applications, and configurations are planned, tested, approved, and documented. This is where many organizations struggle during SOC 2 audits — auditors look for evidence that not a single change to production escaped review.

• Change approval process with documented authorization
• Testing of changes in non-production environments before production deployment
• Separation of duties (the person who writes code does not approve and deploy it)
• Emergency change procedures with post-change review requirements
• Detailed change records (who, what, when, why, approved by whom)

What auditors look for: For code changes, a requirement that pull requests receive peer review before merge and that merges are restricted to production-approved branches. For infrastructure changes, a process requiring approval before deployment with evidence that non-approved changes did not occur. If emergency changes are allowed without pre-approval, evidence that post-change review was completed within a defined window. The change management policy template details what auditors expect.

Operator note: CC8 is where engineering culture and compliance requirements collide most visibly. Teams that ship fast are accustomed to pushing hotfixes directly to production during incidents. SOC 2 auditors will find those commits. The resolution is not eliminating emergency changes — it is building a lightweight emergency change process with a 24-hour post-change review requirement that engineers will actually follow. An undocumented emergency change is an exception. A documented emergency change with a next-day review is a compliant process.

CC9 — Risk Mitigation

Risk mitigation controls address how you respond to identified risks, including vendor management and security incidents.

• Selection and implementation of risk response activities
• Vendor and subservice organization management
• Security incident response and recovery
• Contingency and disaster recovery planning

What auditors look for: The risk register from your risk assessment linked to treatment activities (controls, process changes, tools). For vendors, an inventory of critical third parties with documented security assessments. For contingency planning, a documented business continuity and disaster recovery plan with test results showing that recovery procedures actually work.

Availability (optional)

The Availability criterion evaluates whether your system is available for operation and use as committed. It is relevant for any service with uptime commitments — nearly all SaaS platforms, cloud hosting, managed services, and infrastructure providers.

Availability controls include:

• Uptime monitoring and performance metrics
• Capacity planning to prevent outages from resource exhaustion
• Disaster recovery and backup procedures
• Business continuity planning and testing
• Maintenance procedures that do not disrupt service

What auditors look for (Type II): If your SLA commits to 99.9% uptime, the auditor will verify that you tracked uptime through the observation period and met the commitment. Backup completion records showing that backups ran daily and recovery testing showing that you can actually restore from backups. Disaster recovery plan documentation and evidence that the DR plan was tested during the observation period. Capacity metrics showing you have headroom to handle expected growth without running out of resources.

Operator note: The Availability finding that surprises companies most often is backup restoration testing. Organizations configure daily backups, confirm the backup jobs are completing, and assume this satisfies the Availability criterion. It does not. Auditors want evidence that restoration was tested — that someone attempted to restore from backup and verified the data was complete and consistent. A backup that has never been successfully restored is an untested assumption. Document one restoration test per observation period with the date, the system, and the validation result.

Who should include it: Any company whose customers rely on service availability and have SLA expectations. This includes nearly all SaaS companies, hosting providers, and managed service providers. If your service is a tool that customers could theoretically use in an offline mode or if availability is explicitly carved out of your service promise, you might exclude Availability. But most modern SaaS services should scope Availability if they claim uptime commitments.

Processing Integrity (optional)

Processing Integrity evaluates whether system processing is complete, valid, accurate, timely, and authorized. It applies to services where data accuracy is part of the core service promise.

Processing Integrity controls include:

• Data validation and completeness checking
• Authorization of transactions and processing steps
• Accurate and timely recording of transactions
• Monitoring and prevention of errors in processing
• Audit trails showing what data was processed and by whom

What auditors look for: If you are a financial calculations platform, the auditor will verify that amounts are calculated correctly, that decimal rounding follows specified rules, and that transaction records are complete. If you are an analytics platform, auditors will verify that data imports are complete (no records silently dropped), that metrics are calculated according to your documented methodology, and that results are consistent over time.

Who should include it: Companies where data accuracy is contractually critical or affects customer financial decisions. Examples include payment processors, loan servicers, payroll platforms, accounting software, analytics platforms, and financial data transformation services. Companies providing communication tools or marketing platforms where data accuracy matters less (or where customers own data accuracy) typically do not scope Processing Integrity.

Confidentiality (optional)

Confidentiality controls protect information designated as confidential. This includes trade secrets, customer intellectual property, business plans, and any data subject to contractual confidentiality obligations.

Confidentiality controls include:

• Data classification and sensitivity levels
• Encryption of confidential data at rest and in transit
• Access restrictions based on sensitivity level
• Procedures for secure disposal and destruction of confidential data
• Monitoring and logging of access to confidential information

What auditors look for: A data classification scheme defining what counts as confidential. Evidence that confidential data is encrypted at rest (database encryption, file system encryption) and in transit (TLS for all network communications). Access controls limiting who can view confidential data. Procedures showing that confidential data is securely deleted when no longer needed (overwriting, cryptographic erasure, or secure destruction of storage media).

Who should include it: Companies whose services involve handling trade secrets, pre-release information, or NDA-protected client data. Examples include management consulting, design agencies, contractors handling proprietary client IP, and technology companies with customer usage data that is commercially sensitive. Companies handling only generic business data (emails, documents, standard configurations) without confidentiality obligations might exclude this criterion.

Privacy (optional)

The Privacy criterion addresses how you collect, use, retain, disclose, and dispose of personal information. Privacy aligns with general privacy principles: notice, choice and consent, collection, use and retention, access, disclosure and notification, quality, and monitoring and enforcement.

Privacy controls include:

• Privacy notice and consent documentation
• Limits on collection and use of personal information
• Data retention and disposal procedures
• Access controls and logging for personal data
• Disclosure and breach notification procedures
• Vendor management for data processors

What auditors look for: Privacy policies that clearly explain what personal information you collect, why, and how long you keep it. Consent records showing that individuals agreed to your data practices (if consent is required by law or your practice). Documentation that personal data is only used for the stated purposes. Procedures showing that personal data is deleted when retention periods expire. Breach notification procedures and evidence that breaches were reported to affected individuals and regulators as required by law.

Who should include it: Companies whose service involves processing personal information — names, contact information, payment methods, government IDs, health data, biometric data, location data, or any information identifying an individual. Examples include HR platforms, healthcare technology, consumer applications, identity verification services, and marketing platforms. Companies that process only employees’ personal data for payroll and benefits (not as a core service function) often exclude Privacy. Companies that do not collect or process any personal information can exclude Privacy.

The Common Criteria in detail: CC1–CC9 control families

The Security criterion (Common Criteria) is the most detailed. Each control family (CC1–CC9) contains multiple specific controls that auditors will test. Understanding the control families helps with audit planning and remediation prioritization.

How Type I and Type II differ across criteria

The Trust Services Criteria are the same in both Type I and Type II reports, but the scope of testing differs significantly.

Type I evaluates whether controls are suitably designed at a point in time. For Availability, this means reviewing your disaster recovery plan and confirming it is documented and technically sound. For Privacy, this means reviewing your privacy policy and consent procedures and confirming they align with legal requirements.

Type II evaluates whether controls operated effectively throughout the observation period. For Availability, the auditor will request backup completion logs from across the entire period and evidence that disaster recovery was actually tested — not just that the plan exists. For Privacy, the auditor will review deletion requests received during the period and verify that personal data was actually deleted, not just that the policy says you delete it.

The distinction is material. A control that fails to operate even once during a Type II observation period becomes an exception. If quarterly access reviews are due but one quarter was skipped, that is a Type II finding. The same control design passes Type I because Type I asks only whether the process is properly designed.

Practical compliance: building to the criteria

Most organizations approach SOC 2 compliance by selecting criteria that match their service, then building or documenting controls for each criterion. The control families within Security provide a clear structure.

Start with Security (mandatory). Assess which criteria are needed based on customer requirements and service function. For each criterion, map your existing practices to the control families and identify gaps. The SOC 2 compliance checklist provides a detailed working list of controls for each family.

Engage auditors or compliance consultants early to confirm scope and provide a readiness assessment. A formal readiness assessment identifies gaps that can be remediated before the observation period begins — preventing exceptions that would otherwise appear in the audit report. Organizations serious about a clean audit invest in readiness work upfront.

For Type II audits, remember that controls must operate consistently throughout the observation period. Implementing a control in month six of a twelve-month observation period leaves a gap in the first five months. Calendar the observation period start date and ensure controls are operational and monitored from day one.

Nick Shevelyov spent fifteen years as Chief Security Officer at Silicon Valley Bank, building and maintaining SOC 2 programs across an enterprise-scale organization. Cyber War…and Peace covers the operational discipline and governance structures that transform SOC 2 compliance from a periodic audit project into a continuously improving security program.