SOC 2 Compliance Requirements: Everything You Need to Know

After guiding dozens of companies through their first SOC 2 audits, we have learned that the biggest stumbling block is rarely a lack of motivation — it is a lack of clarity about what SOC 2 actually requires. This guide distills what we tell every client on day one.

SOC 2 compliance requires your organization to demonstrate that security controls satisfying the AICPA's Trust Service Criteria are designed, implemented, documented, and — for Type II reports — operating effectively over time. Unlike prescriptive frameworks that mandate specific technical configurations, SOC 2 is principle-based: it defines what outcomes your controls must achieve, but your organization decides how to achieve them. This flexibility makes SOC 2 adaptable across industries and technology stacks, but it also means understanding the actual requirements takes careful attention.

This guide covers everything required for SOC 2 compliance: the mandatory Security criteria, optional additional criteria, required policies and documentation, evidence and monitoring obligations, the audit process, and common requirements that surprise first-time organizations. The target audience is compliance managers, IT leaders, and founders who have decided to pursue SOC 2 and need a clear understanding of what must be in place before their audit begins.

For a broader overview of the SOC 2 framework, see the complete guide to SOC 2 compliance.

The Core Requirement: Trust Service Criteria

SOC 2 is built on five Trust Service Criteria (TSC) defined by the AICPA. Every SOC 2 engagement requires the Security criterion. The remaining four are optional and selected based on your business model and customer requirements.

Security (Common Criteria) — Required

The Security criterion, also called the Common Criteria, is the foundation of every SOC 2 audit. It encompasses nine categories of controls that collectively ensure information and systems are protected against unauthorized access, unauthorized disclosure, and damage that could compromise availability, integrity, confidentiality, or privacy.

The Common Criteria categories are:

Category	Code	What It Covers
Control Environment	CC1	Governance, ethics, organizational commitment to security, competence
Communication and Information	CC2	Internal and external communication of security policies and objectives
Risk Assessment	CC3	Risk identification, analysis, fraud risk assessment, change management
Monitoring Activities	CC4	Ongoing evaluation of controls, deficiency communication
Control Activities	CC5	Selection and development of controls, technology general controls, policies
Logical and Physical Access	CC6	Access management, authentication, encryption, network security, physical security
System Operations	CC7	System monitoring, anomaly detection, incident response and recovery
Change Management	CC8	Infrastructure and software change control processes
Risk Mitigation	CC9	Vendor risk management, business continuity planning

Each category contains specific criteria points that your controls must address. The auditor evaluates whether your controls are suitably designed (Type I) or both designed and operating effectively (Type II) against these criteria.

Availability — Optional

The Availability criterion requires controls that ensure your system meets its processing, capacity, and uptime commitments. We recommend including this criterion if your customers rely on your service for business-critical operations or if you have contractual SLAs.

Specific requirements:

• Documented uptime commitments and service level agreements
• Capacity monitoring and planning to prevent performance degradation
• Backup and recovery procedures with documented recovery time objectives (RTO) and recovery point objectives (RPO)
• Disaster recovery and business continuity plans that have been tested
• Incident communication procedures for availability events

Processing Integrity — Optional

Processing Integrity requires controls that ensure system processing is complete, valid, accurate, timely, and authorized. We advise including this if your platform processes transactions, performs calculations, or transforms data that customers depend on.

Specific requirements:

• Input validation controls that verify data completeness and accuracy
• Processing monitoring that detects errors, duplicates, and anomalies
• Output verification procedures
• Error handling and correction processes
• Audit trails for data processing activities

Confidentiality — Optional

Confidentiality requires controls that protect information designated as confidential throughout its lifecycle. In our experience, companies that handle proprietary business data, financial information, or other materials requiring protection beyond standard security measures should include this criterion.

Specific requirements:

• Data classification procedures that identify confidential information
• Access controls specific to confidential data categories
• Encryption of confidential data in transit and at rest
• Secure disposal procedures for confidential data that has exceeded its retention period
• Contractual confidentiality protections with vendors that access confidential data

Privacy — Optional

Privacy requires controls that address the collection, use, retention, disclosure, and disposal of personal information in accordance with privacy commitments and applicable regulations. We recommend including this if your platform collects or processes personally identifiable information (PII).

Specific requirements:

• Privacy notice that describes your data collection and use practices
• Consent mechanisms for data collection where required
• Data subject rights management (access, correction, deletion requests)
• Data retention and disposal schedules for personal information
• Privacy impact assessments for new data processing activities

Documentation Requirements

SOC 2 requires documented policies, procedures, and system descriptions that formally describe your security program. Documentation serves two purposes: it establishes your organization's commitment to security governance, and it provides the standard against which your auditor evaluates control effectiveness.

Required Policies

At minimum, your organization needs documented policies covering:

1. Information Security Policy — Overarching security governance, roles, responsibilities, and program objectives
2. Access Control Policy — User provisioning, authentication requirements, role-based access, and access review procedures
3. Change Management Policy — Change request, approval, testing, and deployment procedures for infrastructure and application changes
4. Incident Response Plan — Detection, classification, escalation, response, recovery, and post-mortem procedures for security incidents
5. Risk Assessment Policy — Risk identification methodology, assessment frequency, risk register management, and treatment plan procedures
6. Data Classification Policy — Data categories, handling requirements for each category, and labeling procedures
7. Acceptable Use Policy — Employee guidelines for appropriate use of company systems, data, and resources
8. Vendor Management Policy — Vendor assessment criteria, onboarding procedures, ongoing monitoring, and contract requirements
9. Business Continuity and Disaster Recovery Plan — Recovery procedures, testing schedules, and continuity strategies
10. Human Resources Security Policy — Background check requirements, onboarding security procedures, training requirements, and offboarding processes

These policies must be formally approved by management, communicated to all relevant personnel, and reviewed at least annually. Your GRC platform tracks policy approval, distribution, and employee acknowledgment as auditable evidence.

System Description

Your auditor requires a system description — a document that describes your services, infrastructure, system boundaries, data flows, and the control environment in scope for the audit. The system description becomes Section III of your SOC 2 report and must accurately represent your actual environment.

The system description typically includes:

• Overview of services provided and the nature of your business
• Description of system components (infrastructure, software, people, procedures, data)
• System boundaries defining what is in scope and out of scope
• Relevant aspects of the control environment, risk assessment process, monitoring activities, and information and communication systems
• Complementary user entity controls (CUECs) — controls your customers must implement on their end

Operational Requirements

Beyond policies and documentation, SOC 2 requires ongoing operational activities that demonstrate your controls are functioning in practice — not just on paper.

Continuous Monitoring

Your organization must monitor controls continuously and respond to issues promptly:

• Real-time alerting for security-relevant events (failed login attempts, privilege escalations, configuration changes)
• Cloud configuration monitoring to detect when infrastructure settings drift from compliant baselines
• Endpoint compliance monitoring to verify that all employee devices maintain required security configurations
• Access anomaly detection that flags unusual access patterns or unauthorized access attempts

A GRC platform automates most monitoring by connecting to your infrastructure and alerting you when controls are not operating as expected.

Evidence Collection

For Type II audits, you must collect and retain evidence that controls operated effectively throughout the entire observation period (six to twelve months). Evidence categories include:

• Automated evidence: Cloud configuration snapshots, access logs, vulnerability scan results, MFA enforcement records, code review approvals
• Manual evidence: Access review documentation, risk assessment reports, tabletop exercise results, vendor security assessments, board/leadership security briefings

Evidence must be continuous — gaps during the observation period create audit exceptions. Configure your GRC platform to alert you when evidence collection fails or manual evidence tasks are overdue.

Recurring Compliance Activities

SOC 2 requires several activities on defined schedules:

Activity	Typical Frequency	Evidence Produced
Access reviews across critical systems	Quarterly	Review records with approvals and remediation
Risk assessment	Annually	Risk register, treatment plans, assessment report
Security awareness training	Annually (all employees)	Completion records with timestamps
Vendor security assessments	Annually per vendor	Assessment records, vendor SOC 2/ISO reports
Incident response testing (tabletop)	Annually	Exercise documentation, findings, action items
Business continuity/DR testing	Annually	Test results, recovery time documentation
Penetration testing	Annually	Pen test report, remediation tracking
Policy review and approval	Annually	Updated policies with approval records
Board/leadership security reporting	Quarterly	Meeting minutes, security updates

Missing any of these during the observation period is a common source of audit exceptions.

Audit Process Requirements

Independent CPA Firm

SOC 2 attestation must be performed by an independent CPA firm. This is a non-negotiable requirement — you cannot self-attest or use a non-CPA security assessor for SOC 2. The CPA firm issues the report containing their professional opinion on your control environment.

Management Assertion

Your organization's management must provide a written assertion that the system description is accurate and that controls are suitably designed (Type I) or designed and operating effectively (Type II). This management assertion is included in the final SOC 2 report.

Complementary User Entity Controls (CUECs)

Your SOC 2 report may include CUECs — controls that your customers must implement on their end for the overall control environment to function as intended. Common CUECs include requirements for customers to use strong passwords, restrict access to authorized personnel, and report suspected security incidents. We recommend documenting CUECs clearly so your customers understand their responsibilities.

Common Requirements That Surprise First-Time Organizations

Based on what we see working with first-time SOC 2 companies, several requirements consistently catch organizations off guard:

1. Background checks for all employees. Many startups do not conduct background checks. SOC 2 expects pre-employment screening for all personnel with access to production systems. If you have existing employees who were never screened, we recommend conducting retroactive checks or documenting the exception with a plan to screen all future hires.

2. Formal risk assessment. A documented, formal risk assessment is required — not just an informal understanding of risks. The assessment must identify specific risks, evaluate their likelihood and impact, and document treatment decisions (accept, mitigate, transfer, avoid).

3. Vendor management program. Every third-party vendor that handles customer data must be inventoried and assessed. This includes cloud providers, payment processors, analytics tools, support platforms, and subcontractors. What we tell clients is to start vendor assessments early — they require vendor cooperation and often take longer than expected.

4. Annual penetration testing. Most SOC 2 programs include annual penetration testing by an independent firm. The test results, along with evidence of remediation for any findings, serve as audit evidence.

5. Board or management oversight documentation. Auditors expect evidence that security is discussed at the leadership level. This does not require a formal board of directors — meeting minutes from leadership team discussions about security topics satisfy this requirement.

Key Takeaways

• We consistently see that the Security (Common Criteria) requirement is where teams need to invest the most upfront effort — it is mandatory for every SOC 2 audit, while Availability, Processing Integrity, Confidentiality, and Privacy are optional and selected based on your business model
• What we recommend is treating SOC 2's principle-based flexibility as a strength: you choose how to implement controls as long as they satisfy the criteria, which lets you build a program that fits your stack and stage
• Ten core policies are required, each formally approved, communicated, and reviewed annually — we advise clients to start drafting these as early as possible
• A system description documenting your services, infrastructure, and boundaries is required for the audit and often takes longer to prepare than teams expect
• Continuous monitoring, evidence collection, and recurring compliance activities (quarterly access reviews, annual risk assessments, annual pen tests) are operational requirements that must run without gaps during your observation period
• Only an independent CPA firm can perform a SOC 2 attestation — this is non-negotiable
• Based on what we see, background checks, formal risk assessments, vendor management programs, and leadership security oversight are the requirements that most commonly surprise first-time organizations

Frequently Asked Questions

Does SOC 2 require specific technical configurations?

What we tell clients is that SOC 2 is principle-based, meaning it defines outcomes (protect against unauthorized access, ensure system availability) rather than prescribing specific configurations. Your organization decides how to satisfy each criterion. However, based on what we see across audits, certain baseline configurations are effectively universal because they are the most straightforward way to satisfy the criteria: MFA for all users, encryption at rest and in transit, centralized logging, automated vulnerability scanning, and endpoint management are practical requirements even if they are not technically mandated by the framework itself.

What happens if we do not meet all requirements by the audit date?

Based on what we see, if controls are not fully implemented or evidence is missing, the auditor will document these as exceptions in the final report. A small number of exceptions is normal and generally acceptable to customers. However, fundamental gaps — such as lacking an incident response plan or having no access review process — may result in a qualified opinion or the auditor recommending that you delay the audit. What we recommend is that it is better to postpone an audit by a few weeks than to receive a report with significant exceptions.

Are there specific employee training requirements?

What we tell clients is that SOC 2 requires security awareness training for all employees, typically conducted annually. The training must cover topics relevant to your security program: phishing awareness, data handling, password practices, incident reporting, and acceptable use policies. Training completion must be documented with timestamps. Most GRC platforms integrate with training providers or offer built-in training modules. New employees should complete training during onboarding, and annual refresher training ensures ongoing awareness.

Do we need to address physical security?

Based on what we see, if you have physical office locations where employees access production systems or handle sensitive data, physical security controls apply. This includes visitor management, physical access restrictions (badge access, locks), and workstation security. For fully remote organizations with cloud-only infrastructure, physical security requirements are limited — but your cloud provider's physical security (documented in their own SOC 2 report) must be referenced.

How often do SOC 2 requirements change?

What we tell clients is that the Trust Service Criteria are updated periodically by the AICPA, though major revisions are infrequent. The most recent significant update was in 2017 when the criteria were revised to align with the COSO 2013 framework. Your auditor will inform you if any criteria changes affect your audit. Between major revisions, the practical requirements evolve through auditor expectations and industry best practices rather than formal framework updates. We recommend staying current with your GRC platform and maintaining ongoing auditor communication to ensure you remain aligned with current expectations.