SOC 2 Requirements: Everything Your Organization Needs to Achieve Compliance

SOC 2 requirements are the administrative, technical, and organizational controls an organization implements to protect customer data and demonstrate compliance with the American Institute of Certified Public Accountants (AICPA) Trust Services Criteria. Every SOC 2 audit includes the Security criterion, while Availability, Processing Integrity, Confidentiality, and Privacy are selected based on the services your organization provides. Most organizations spend 2–6 months preparing, while a Type II audit requires an additional 3–12 month observation period to verify that controls operate consistently.

At a Glance

What Are SOC 2 Requirements?

SOC 2 requirements are the administrative, technical, and organizational controls an organization puts in place to prove that customer data is handled securely, in line with the Trust Services Criteria.

In practice, this means three things have to exist at once: a written policy that says what you do, a technical control that actually does it, and evidence that proves it happened consistently over time. Auditors fail companies far more often for the third piece — missing evidence — than for a weak policy document.

Across a SOC 2 engagement, this generally shows up as:

• Security governance and risk assessment
• Access management and least-privilege enforcement
• Documented security policies
• Employee security awareness training
• Vendor and third-party risk management
• Incident response procedures
• Business continuity and disaster recovery planning
• System monitoring and logging
• Change management for code and infrastructure
• Data protection and encryption
• Continuous evidence collection

The SOC 2 Trust Services Criteria, Explained

Every SOC 2 audit is scored against one or more of five criteria. Security is the only one every company must include; the other four are chosen based on what you actually promise customers in your contracts or SLAs.

1. Security (Mandatory)

This is the baseline every SOC 2 report includes, regardless of industry. It covers protection against unauthorized access — both external attackers and internal misuse.

Expect to demonstrate: firewalls and network segmentation, multi-factor authentication (MFA), endpoint protection, vulnerability management, centralized logging, access controls, encryption at rest and in transit, active security monitoring, a documented risk management process, and a tested incident response plan.

2. Availability

Add this criterion if your contracts include uptime commitments or SLAs. It measures whether your systems stay operational and recoverable, not whether they’re fast.

Auditors look for backup procedures, a disaster recovery plan that’s actually been tested (not just written), business continuity planning, infrastructure monitoring, capacity planning, and redundancy across critical systems.

3. Processing Integrity

Relevant if your platform processes transactions, calculations, or data transformations customers rely on being accurate — payment processors and billing platforms almost always include this.

This means validation controls, error detection, quality assurance checks, transaction verification, and ongoing processing reviews.

4. Confidentiality

Applies when you handle non-public information beyond standard personal data — contracts, IP, business plans, or anything under an NDA.

Controls typically include data classification, encryption, strict access restrictions, secure storage, and documented, provable data disposal procedures.

5. Privacy

This applies specifically to personal information collected from individuals, and it overlaps with — but is not a replacement for — GDPR or CCPA compliance.

Expect requirements around privacy notices, consent management, data subject access rights, secure deletion processes, and a published privacy policy that matches what you actually do.

Core SOC 2 Requirements Every Organization Must Meet

Information Security Policies

Auditors expect a documented policy set, not a single master document. At minimum: information security policy, password policy, acceptable use policy, remote work policy, asset management policy, data handling policy, encryption policy, incident response policy, and vendor management policy. These need version history and evidence that employees have actually read and acknowledged them — a policy nobody’s seen doesn’t count as a control.

Risk Assessment

This should be a living process, not an annual box-check. Organizations need to identify risks, evaluate the likelihood and impact of each threat, prioritize remediation, and revisit the assessment when something material changes — a new vendor, a new product line, a security incident.

Evidence auditors ask for: a risk register, dated annual (or more frequent) reviews, and documented treatment plans for identified risks.

Access Control

The principle is least privilege — people get access to exactly what their role requires, nothing more.

This requires MFA everywhere it’s supported, role-based access control, a documented joiner-mover-leaver (onboarding/offboarding) process, periodic privileged access reviews, and strong authentication across all critical systems.

Change Management

Every code deployment and infrastructure change needs a paper trail: documented changes, testing evidence, approval sign-off, and a rollback plan if something breaks. Auditors will sample actual change tickets, so this can’t just be a policy — it has to match what’s happening in your ticketing system.

Incident Response

A written incident response plan needs defined roles, escalation paths, an investigation process, a customer communication protocol, and — critically — a lessons-learned step after every real incident. Auditors specifically check whether past incidents actually fed back into policy updates.

Security Awareness Training

Training needs to happen on a set cadence (usually annually, ideally with phishing simulations more frequently) and cover phishing, password hygiene, social engineering, safe data handling, insider threat awareness, and how to report a suspected incident.

Vendor Management

Any third party touching your data or infrastructure needs a documented risk assessment, a security review before onboarding, contractual security terms, and periodic reassessment — not just a one-time check at signing.

Asset Management

You need a current inventory of servers, cloud resources, applications, endpoints, databases, and software licenses. Auditors will ask how you know an asset has been decommissioned, not just how you tracked it when it was active.

Logging and Monitoring

Centralized visibility into authentication events, administrative actions, security alerts, network activity, cloud infrastructure, and critical applications — with alerting that someone is actually accountable for reviewing.

Vulnerability Management

Regular vulnerability scanning, a defined patch management SLA, periodic penetration testing, and a tracked remediation process through to verified closure.

Documentation Required for SOC 2

Auditors will request most or all of the following:

• Information Security Policy
• Risk Assessment
• Asset Inventory
• Access Control Policy
• Incident Response Plan
• Disaster Recovery Plan
• Business Continuity Plan
• Vendor Management Policy
• Employee Handbook
• Security Awareness Training Records
• Change Management Policy
• Backup Procedures
• Monitoring Procedures
• Password Policy
• Encryption Policy

Technical Controls Auditors Verify

MFA, endpoint detection and response (EDR), antivirus/anti-malware, SIEM or centralized log monitoring, cloud security configuration, encryption in transit and at rest, tested backups, email security (SPF/DKIM/DMARC, phishing filtering), and identity/access management tooling.

Administrative Controls

Policies, procedures, risk management processes, training programs, governance structure, internal control reviews, internal audits, and ongoing compliance monitoring.

Physical Security Requirements

Relevant if you operate physical offices or data centers: badge/access control at entry points, visitor logs, CCTV coverage, secure equipment disposal, and environmental controls (fire suppression, climate control) for server rooms.

SOC 2 Type I vs. Type II Requirements  

Most companies use Type I as a fast first step to unblock an urgent deal, then move to Type II once they have a track record of controls actually running. Enterprise buyers increasingly ask for Type II by default, so treat Type I as a bridge, not a destination.

Common Evidence Auditors Request

Security policies, employee training completion records, documented risk assessments, access review logs, MFA configuration screenshots, backup success reports, vulnerability scan reports, penetration test reports, change management tickets, incident records, vendor security reviews, audit/system logs, asset inventory exports, and HR onboarding/offboarding records.

SOC 2 Compliance Checklist

1. Define audit scope and select applicable Trust Services Criteria
2. Perform a formal risk assessment
3. Develop and publish security policies
4. Implement technical controls (MFA, encryption, monitoring, EDR)
5. Configure and document access management
6. Enable centralized logging and alerting
7. Roll out employee security awareness training
8. Conduct an internal readiness assessment (gap analysis)
9. Collect and organize audit evidence
10. Complete the independent SOC 2 audit
11. Remediate any findings
12. Maintain continuous compliance between audit cycles

Common Challenges Organizations Face

In our experience running SOC 2 readiness assessments, the same handful of gaps show up repeatedly: incomplete or scattered documentation, no centralized place to store evidence, weak or inconsistent access reviews, missing or outdated risk assessments, inconsistent change management records, limited security monitoring coverage, thin vendor oversight, and low employee awareness of the policies that technically exist.

The most common single point of failure we see in first-time Type II audits is access review evidence — companies have the control in place but can’t produce a consistent, dated log proving it ran every quarter.