SOC 2 requirements for SaaS companies: a practical guide

If an enterprise prospect has ever sent you a security questionnaire asking for your SOC 2 report, you already understand the stakes. SOC 2 has become the de facto trust signal for SaaS companies selling to business customers — particularly in North America and increasingly across Europe. But for compliance officers and security leads who haven't been through the process before, the requirements can feel unclear.

This guide cuts through the noise and explains exactly what SOC 2 demands, how the audit works, and what your team needs to do before the auditor arrives.

What SOC 2 actually is

SOC 2 (System and Organisation Controls 2) is an attestation framework developed by the American Institute of CPAs (AICPA). Unlike ISO 27001, which is a certification standard, SOC 2 produces an auditor's report — a document issued by an independent CPA firm that attests to whether your controls meet the relevant Trust Services Criteria (TSC). Customers request the report as part of due diligence; you can't "pass" SOC 2 in the same way you pass an exam, but a clean report carries significant commercial weight.

For SaaS companies, the relevance is direct: you store, process, or transmit customer data on behalf of clients, making you a service organisation under the AICPA's definition. That's the threshold that makes SOC 2 applicable to you.

If you're also exploring how SOC 2 compares to other European standards, the ISO 27001, SOC 2, ISAE 3000, and NIS2 compliance comparison is a useful starting point.

The five Trust Services Criteria

SOC 2 is organised around five criteria. Only one is mandatory:

Security (the Common Criteria) — required for every SOC 2 audit. It covers protection of systems and data against unauthorised access, both logical and physical. Auditors will look for access controls, multi-factor authentication, encryption at rest and in transit, network monitoring, and vulnerability management.

Availability — relevant if you have uptime SLAs. Auditors check disaster recovery plans, incident response procedures, system monitoring, and backup processes. Most SaaS vendors include this criterion because customers care deeply about uptime.

Processing Integrity — applies when the accuracy and completeness of data processing is material to your service. Think fintech or data analytics platforms where errors in processing could cause real harm.

Confidentiality — governs protection of information designated as confidential, such as intellectual property, business plans, or contractual data. Evidence includes data classification policies, NDAs, and network segmentation.

Privacy — covers how personal information is collected, used, retained, and disclosed in line with your privacy notice. It aligns closely with GDPR obligations, making it particularly relevant for European SaaS teams.

Most SaaS companies scope their first audit to Security plus Availability, then layer in Confidentiality or Privacy as customer demands grow. You don't have to include all five — choosing the right scope is itself a strategic decision worth discussing with an advisory firm early. Securance's compliance services team regularly helps SaaS organisations work through this scoping exercise before committing to an audit.

Type 1 vs Type 2: what the difference means in practice

This is the question that trips up most first-timers.

SOC 2 Type 1 assesses whether your controls are designed appropriately at a single point in time. The auditor reviews your documentation, policies, and configurations on a given date and forms an opinion on whether the controls look right. There's no observation period. A Type 1 report typically takes 2–6 months to prepare and complete.

SOC 2 Type 2 goes further. The auditor evaluates whether your controls actually operated effectively over a defined period — usually 3 to 12 months. They'll sample your access review logs, incident tickets, change management records, and backup test results across the entire window. 

Most enterprise buyers now expect Type 2, because it proves your controls aren't just theoretical. A useful way to think about it: Type 1 unlocks early-stage enterprise conversations; Type 2 closes them. Many SaaS teams complete Type 1 to unblock an immediate deal, then immediately begin their Type 2 observation window so both reports can be issued within 12–15 months of starting.

For a deeper dive on whether Type 2 is right for your stage, see Is a Type 2 Certification essential for your SaaS Company?

The controls auditors actually test

Knowing the criteria is one thing; knowing what evidence auditors collect is what determines whether you're genuinely ready.

For Security, expect auditors to sample:

• Access provisioning and deprovisioning tickets (was access removed promptly when someone left?)
• Periodic access review logs showing managers certified user permissions at required intervals
• MFA enforcement screenshots across production systems
• Vulnerability scan reports and evidence that findings were remediated within your defined SLA
• Background check records for employees with access to production data

For Availability, auditors typically want:

• Disaster recovery test results with documented outcomes
• Incident response logs from the observation period
• Uptime data against committed SLAs

For Processing Integrity, look at data reconciliation reports, error logs, and change management tickets showing QA gates were followed.

The most common failure mode isn't a lack of controls — it's a lack of evidence that controls ran consistently. Some of the most frequent exceptions stem from untracked offboarding (access left active after employees leave), skipped periodic access reviews, and missing MFA on administrative accounts. These are operational discipline issues, not technology gaps.

Our SOC 2 Type II Readiness Checklist walks through the eight steps SaaS teams need to complete before engaging an auditor.

How to prepare: the practical path

1. Define your scope. Identify which systems process customer data, which TSCs apply, and which sub-processors are in scope. Narrow scope means faster, cheaper audits — but under-scoping can damage credibility if customers discover material systems were excluded.

2. Run a gap assessment. Compare your current controls against the AICPA's Common Criteria point by point. This surfaces the remediation work needed before you can enter an observation window without accumulating exceptions.

3. Implement and document controls. Write policies that reflect what you actually do, not what you aspire to do. Assign a named owner to each control. Auditors will ask who is responsible for running each procedure.

4. Collect evidence continuously. For Type 2, this is the discipline that separates passing from failing. Set up automated log retention, schedule access reviews in your calendar, and document every DR test result. Don't sprint to collect evidence in the final weeks, auditors sample across the full observation period.

5. Run a penetration test. SOC 2 doesn't mandate a pentest, but auditors increasingly expect to see one as evidence of security testing under the Security criterion. Penetration testing also surfaces misconfigurations that could otherwise appear as findings in your report.

6. Engage your auditor early. The CPA firm conducting your audit is not your enemy. Engaging them before fieldwork begins clarifies exactly what evidence they'll request and avoids last-minute scrambles.

Why SOC 2 is a commercial advantage, not just a compliance box

A clean SOC 2 Type 2 report does more than satisfy procurement checklists. It signals operational maturity to investors, reduces the length of security questionnaires you need to answer, and builds the governance foundation that makes ISO 27001 or NIS2 compliance faster to achieve down the line.

Securance has helped over 800 professional firms and SMEs across Europe navigate exactly this journey, combining advisory, assurance, and technical security services under one roof. The Single Audit, Multiple Standards approach means that the controls you implement for SOC 2 can be mapped directly to ISO 27001 or ISAE 3402 requirements, reducing duplication and letting your team focus on building the product rather than managing separate audit programmes.

SOC 2 readiness is a 6–15 month project depending on your starting point. The teams that get there fastest are the ones that treat evidence collection as an operational habit from day one - not a final sprint before the auditor calls.