SOC 2 Requirements

SOC 2 compliance means your security controls meet the Trust Services Criteria (TSC), a framework created by the American Institute of Certified Public Accountants (AICPA).

There is no universal checklist. Your auditor evaluates whether the controls you have in place satisfy the criteria that apply to your system and scope.

Every SOC 2 report must address the Security criterion, also called the Common Criteria. Beyond that, most audits cover access control, encryption, monitoring, incident response, change management, vendor risk management, and security awareness training for employees.

To pass, you need to demonstrate that your controls work consistently and that you have documented policies and evidence to back them up.

SOC 2 Requirements Overview

The table below summarizes the most common SOC 2 requirement areas and what auditors typically look for in each.

Requirement Area	Examples
Access control	Role-based access, least-privilege enforcement, multi-factor authentication, quarterly access reviews
Monitoring	Centralized logging, intrusion detection systems, alerting on suspicious activity
Incident response	Documented incident response plan, defined escalation paths, post-incident reviews
Vendor risk	Vendor security assessments, third-party risk register, data protection requirements in contracts
Security training	Security awareness training for employees, onboarding training, phishing simulations
Change management	Documented approval process, code review requirements, separation of development and production
Data protection	Encryption in transit and at rest, data classification policy, backup and recovery procedures
Risk assessment	Annual risk assessment, threat identification, documented mitigation plans

This list is not exhaustive. The controls your auditor expects will depend on the system being audited, which Trust Services Criteria you selected, and the risks specific to your environment.

Key Takeaway

SOC 2 requirements are not a single checklist. Your job is to design and operate controls that meet the Trust Services Criteria and protect customer data. Auditors then check whether those controls are appropriate and working consistently. For timing details, see our SOC 2 audit timeline guide.

SOC 2 Trust Services Criteria

The SOC 2 framework is built around five Trust Services Criteria. Security is always required. The other four are Availability, Confidentiality, Processing Integrity, and Privacy. You choose which ones to include based on what your customers need and the type of system you operate.

Security (Common Criteria)

The Security criterion protects your systems and data from unauthorized access and misuse. Controls typically cover access management, monitoring, encryption, vulnerability management, and incident response.

When a SOC 2 report includes only one criterion, it is always Security.

Availability

Availability measures whether your system stays operational as promised in your service-level agreements (SLAs). Common controls include infrastructure redundancy, disaster recovery planning, system monitoring, and capacity management.

SaaS companies with uptime guarantees commonly include this criterion in their SOC 2 scope.

Confidentiality

Confidentiality protects information that your organization has labeled as confidential by contract or policy. Typical controls include data classification policies, encryption requirements, access restrictions, and secure disposal procedures.

Companies handling proprietary business data or intellectual property are the most likely to include this criterion.

Processing Integrity

Processing Integrity verifies that your system processing is complete, accurate, valid, and timely. It matters most for systems that handle financial calculations, data transformations, or transaction processing.

Controls may include input validation, reconciliation procedures, automated integrity checks, and error handling. For AI and machine learning systems, Processing Integrity also covers model reliability, drift monitoring, and output validation. Our SOC 2 for AI companies guide goes deeper on this topic, and our AI security controls guide covers implementation steps.

Privacy

Privacy governs how you collect, use, retain, disclose, and dispose of personal information. Common controls include privacy notices, consent management, data minimization practices, and data retention policies.

Companies that handle personal data under regulatory or contractual requirements often include this criterion. See our SOC 2 Type I vs Type II guide for how these criteria are evaluated differently across report types.

Core Security Controls Most Auditors Expect

SOC 2 does not prescribe a fixed set of controls. In practice, though, most auditors expect to see these foundational security practices in place.

Identity and Access Management

Identity and access management controls limit who can reach your systems and data. Auditors want to see:

Multi-factor authentication for administrative and production access
Role-based access control with least-privilege principles
Formal onboarding and offboarding processes that grant and revoke access promptly
Quarterly access reviews with documented approval

Network and Infrastructure Security

Infrastructure security protects your systems from unauthorized network access. Key controls include:

Firewall configurations and network segmentation
Encryption of data in transit using TLS
Endpoint detection and response (EDR) software on employee devices
Patch management programs that address vulnerabilities promptly

Logging and Monitoring

Security monitoring helps you detect suspicious activity and supports incident investigations. Your auditor will look for:

Centralized log collection from cloud infrastructure, identity providers, and applications
Real-time alerts for security-relevant events
Log retention policies that preserve records for an adequate period (commonly 90 days or more)

Vulnerability Management

Vulnerability management keeps your systems secure as new threats surface. Auditors expect to see:

Regular vulnerability scanning of infrastructure and applications
Annual penetration testing performed by an independent third party
Documented remediation timelines based on vulnerability severity

Together, these controls form the baseline that most SOC 2 auditors expect. If any are missing, your auditor will likely flag them as gaps that need remediation before the report can be issued.

Policy Requirements

SOC 2 audits require formal, written policies that describe how your organization manages security. Auditors review both the policies themselves and the evidence that you actually follow them. Below are the core policies most audits require.

Information Security Policy. Defines your overall security program.
Access Control Policy. Describes how system access is granted, reviewed, and revoked.
Incident Response Policy. Outlines procedures for detecting and responding to security incidents.
Change Management Policy. Explains how system changes are reviewed and deployed.
Data Classification Policy. Defines how sensitive data is categorized and protected.
Acceptable Use Policy. Describes how employees may use company systems and data.
Vendor Management Policy. Covers how third party vendors are evaluated and monitored.
Business Continuity and Disaster Recovery Policy. Explains how operations continue during disruptions.

Every policy should be reviewed at least annually, version-controlled, and accessible to all employees. Auditors also expect evidence that employees have acknowledged key policies, typically through a signed acknowledgment or a tracked confirmation in a compliance platform.

Compliance platforms like Drata and Secureframe provide policy templates aligned with SOC 2 requirements and tools to track employee acknowledgments automatically.

Technical Security Requirements

Auditors evaluate the technical safeguards protecting your systems and data. The focus is on production environments and the infrastructure that supports them.

Encryption

Encryption is a baseline expectation for protecting data at rest and in transit.

Encryption of stored data using strong algorithms such as AES-256
TLS encryption for all external communications
Secure key management with restricted administrative access

Authentication and Authorization

Strong authentication protects administrative access to critical systems.

Multi-factor authentication (MFA) for administrative systems
Secure authentication methods for service accounts
Session timeouts and re-authentication for sensitive operations

Infrastructure Hardening

Production systems must follow secure configuration standards:

Hardened server configurations based on established benchmarks
Removal of unnecessary services and open ports
Replacement of default credentials before systems enter production

Backup and Recovery

Reliable backups protect against data loss and support business continuity.

Scheduled backups of critical data and system configurations
Periodic testing of backup restoration
Defined recovery time objectives and recovery point objectives

Cloud Configuration

If you use AWS, Azure, or Google Cloud, auditors will review:

Identity and access management settings
Storage permissions
Network security rules
Logging and monitoring configuration

Compliance platforms like Vanta and Sprinto can automatically detect cloud configuration issues before your audit begins.

Operational Processes Auditors Review

SOC 2 audits look at how your team operates, not just the technology you use.

Incident Response

You need a documented incident response process that defines roles, severity levels, and communication procedures. If an incident occurred during the audit period, the auditor will review how your team handled it.

Change Management

All production changes should follow a documented process that includes review, approval, testing, and deployment records. Auditors typically sample recent changes to confirm the process was followed.

Onboarding and Offboarding

Your employee lifecycle processes need to grant access when people join and revoke it when they leave. Auditors verify this by reviewing recent hires and departures.

Vendor Management

You need to evaluate the security posture of third-party vendors that process or store your data. Auditors review vendor risk assessments, security reports (like the vendor's own SOC 2), and data protection clauses in your contracts. See common vendor management gaps that cause SOC 2 failures for detailed auditor expectations.

Risk Assessment

Most SOC 2 programs require an annual risk assessment that identifies threats, evaluates their impact, and documents mitigation strategies. This process keeps your controls aligned with real risks as your company grows. See our SOC 2 Readiness Checklist for a practical guide.

SOC 2 Requirements FAQ

Is there an official SOC 2 requirements checklist from the AICPA?

No, the AICPA does not publish an official SOC 2 checklist. It defines the Trust Services Criteria, but each organization designs its own controls to meet them. Auditors then evaluate whether those controls are appropriate for the system in scope.

Do companies need all five Trust Services Criteria?

No, Security is the only required criterion. Availability, Confidentiality, Processing Integrity, and Privacy are optional. You choose which ones to include based on your system type and what your customers or prospects expect.

What policies are required for SOC 2?

Most SOC 2 audits require at least eight core policies: information security, access control, incident response, change management, data classification, acceptable use, vendor management, and business continuity. Your auditor may ask for additional policies depending on the Trust Services Criteria in scope.

Does SOC 2 require penetration testing?

Not explicitly, but most auditors expect it. Annual penetration testing by an independent third party is considered standard practice for a mature vulnerability management program.

How do compliance platforms help with SOC 2 requirements?

Compliance platforms automate evidence collection, provide ready-to-use policy templates, continuously monitor your controls, and simplify auditor workflows. The result is less manual work for your team and more consistent control performance throughout the audit period.

What happens if a SOC 2 control is not met?

The auditor documents it as an exception in your report. SOC 2 reports do not produce a simple pass or fail result. Minor exceptions are common and usually not a dealbreaker. Major or repeated exceptions, however, may raise concerns with customers reviewing your report. See our guide on failed SOC 2 audits for more detail.

Do SOC 2 requirements change over time?

Yes, they do. The Trust Services Criteria evolve as the AICPA updates the framework, and industry expectations shift alongside them. Controls that were optional a few years ago may now be standard. For example, AI security controls are increasingly expected for companies that build or rely on AI systems.

How is SOC 2 different from ISO 27001?

SOC 2 is an attestation issued by a licensed CPA firm based on the Trust Services Criteria. ISO 27001 is a certification for information security management systems, issued by accredited certification bodies. They serve different audiences, but many organizations pursue one or both depending on what their customers require.

Compare SOC 2 Auditors

The auditor you choose affects your cost, timeline, and how smoothly the audit goes. If you are also evaluating compliance platforms, see our Drata vs Vanta comparison or our guide to SOC 2 compliance platforms.

Browse and compare specialized SOC 2 auditors in our directory: