Understanding SOC 2 Compliance Requirements

SOC 2 Compliance Requirements: What Auditors Actually Test For

SOC 2 doesn't require specific tools, technologies, or a rigid checklist of named controls. What it requires is that your organization implement four things — documented policies, enforced operational controls, technical controls, and auditable evidence — across whichever Trust Services Criteria apply to your business. This guide breaks down what each of those actually looks like in practice, not just in theory.

A Principles-Based Framework

Unlike prescriptive regulations that name specific required controls, SOC 2 is intentionally flexible. It evaluates whether your systems and processes meet the objectives of up to five criteria:

• Security (mandatory for every SOC 2 report)

• Availability

• Processing Integrity

• Confidentiality

• Privacy

These are defined by the Trust Services Criteria (TSC), supplemented by Common Criteria covering governance, risk management, monitoring, and communication that apply regardless of which of the five criteria you pursue.

The flexibility is a genuine strength — a 15-person startup and a 2,000-person enterprise can both be SOC 2 compliant with very different tools and processes, as long as each one's controls provide reasonable assurance the criteria are met. But that same flexibility means "what do I actually need to build" isn't obvious from reading the criteria alone. Here's what it looks like in practice.

Requirement 1: Formal Policies

Your organization needs documented policies covering key risk areas, at minimum:

• Information security policy

• Access control / access management policy

• Incident response plan

• Vendor risk management policy

• Data retention and disposal policy

These aren't meant to be generic templates — an auditor will expect a policy to name specific, checkable commitments. For example, a real access control policy states something like: "Production system access requires manager approval and is reviewed quarterly, with access revoked within 5 business days of a review flag." A policy that just says "access is reviewed periodically" gives the auditor nothing concrete to test.

Requirement 2: Operational Controls That Enforce the Policies

A policy is only as good as what actually happens day to day. If your access control policy states quarterly reviews, you need to show — with dates and documented outcomes — that those reviews happened on schedule, every quarter, for every system in scope. A policy that exists on paper but isn't followed consistently is one of the most common sources of audit exceptions, not because the policy was wrong, but because practice didn't match it.

Requirement 3: Technical Controls

Auditors will expect to see specific, working technical controls, typically including:

• Authentication and access control — SSO, MFA, role-based access

• Encryption — data encrypted at rest and in transit for anything classified as sensitive

• System monitoring and alerting — centralized logging (e.g., via a SIEM tool like Splunk or Datadog) with defined alert thresholds

• Backup and recovery — automated backups with a documented, tested restoration cadence (quarterly, at minimum)

• Change management — required code review and deployment approval before production changes

• Vulnerability management — regular scanning (e.g., via Snyk, Tenable, or Qualys) and a defined remediation timeline based on severity

Ongoing monitoring of these controls matters more than a one-time implementation — SOC 2, like GDPR and HIPAA, expects continuous validation, not a control you set up once and never revisit.

Requirement 4: Audit Evidence

The requirement that trips up the most first-time SOC 2 candidates isn't building the controls — it's proving they operated. This means:

• Retaining documentation of key process decisions (why a policy says what it says, not just the policy itself)

• Storing logs that demonstrate control operation over time, not just point-in-time snapshots

• Tracking control testing and remediation with dates and named owners

• Maintaining clear records of security incidents and how they were resolved

During the audit, your auditor samples this evidence directly and evaluates whether it demonstrates the control operated as described — a control with no supporting evidence is treated the same as a control that doesn't exist, regardless of how well it actually functioned. Automation platforms like DSALTA address this by collecting evidence continuously as your systems generate it, rather than requiring a manual scramble to reconstruct months of history right before the audit.

The Underlying Requirement: Continuous Operation, Not a One-Time Pass

The most important requirement of SOC 2 isn't any single control — it's the expectation that your program operates continuously, not just during the weeks before an audit. A Type II report specifically tests whether controls worked consistently over a 3-12 month period, which means a program that's only "on" right before the auditor arrives will show gaps the moment testing samples an earlier month.

This is also why many organizations build SOC 2 as part of a broader compliance program aligned with ISO 27001 or PCI DSS — the underlying discipline (documented policies, enforced practice, technical controls, retained evidence) transfers directly across frameworks, so building it well once pays off beyond SOC 2 alone.

FAQ

Does SOC 2 require specific tools or software? No. SOC 2 doesn't mandate any particular vendor or technology — it requires that whatever tools and processes you use provide reasonable assurance the relevant criteria are met, and that you can produce evidence of that.

How many controls does SOC 2 require? There's no fixed number. The count depends on your scope and which Trust Services Criteria apply — a Security-only report typically involves fewer controls than one that also covers Availability, Confidentiality, and Privacy.

Do all five Trust Services Criteria apply to every company? No — Security is the only mandatory criterion. Companies add the others based on what's relevant to their business and what customers expect (e.g., a payment processor is more likely to include Processing Integrity).

What's the single most common requirement companies underestimate? Evidence and auditability. Many organizations build reasonably strong controls but don't retain enough documentation to prove those controls operated consistently — which produces exceptions even when the underlying security posture is sound.