SOC 2 readiness is the work you do before an auditor arrives: define what's in scope, put the required security controls in place, write the policies that describe them, and collect evidence that they work. For most SaaS startups, it's the difference between a clean first report and months of findings. This checklist is the one we use with Series A–C companies whose enterprise deals are stalling on "please send your SOC 2."
Why SaaS companies need SOC 2 (and when)
SOC 2 is an attestation report issued by a licensed CPA firm under the AICPA's Trust Services Criteria. It isn't a law or a certification you "pass". It's an independent opinion on whether your controls are designed well (Type I) and operated effectively over time (Type II). Enterprise procurement and security teams ask for it because it replaces hundreds of questionnaire answers with one trusted document.
The right time to start is usually one or two quarters before you need the report in a sales cycle. If a seven-figure deal is waiting on it, you're already late. A readiness phase plus a Type I can often be done in a quarter, but a Type II needs an observation window on top.
SOC 2 Type I vs Type II
| Type I | Type II | |
|---|---|---|
| What it tests | Control design at a single point in time | Control operating effectiveness over a period |
| Observation period | None | Typically 3–12 months |
| What buyers think | "A good start" | "The real thing": most enterprise buyers eventually require it |
| Best for | Unblocking a deal quickly while the Type II window runs | Ongoing enterprise sales; annual renewals |
The SOC 2 readiness checklist
1. Scope and criteria
- Choose the Trust Services Criteria. Security (the "common criteria") is mandatory. Add Availability or Confidentiality only if customers ask; every extra criterion adds controls and audit cost.
- Define the system boundary: the production application, the cloud accounts (AWS, Azure, GCP), the identity provider, code repositories, CI/CD, the support tools that touch customer data, and the people who operate them.
- List your subservice organisations (your cloud provider, payment processor, email provider) and collect their SOC 2 reports.
2. Governance and policies
- Name an owner for the program: a security lead, or a vCISO if you don't have one.
- Write and approve the core policy set: information security, acceptable use, access control, change management, incident response, business continuity and disaster recovery, vendor management, data classification and retention, and risk assessment.
- Run and document an annual risk assessment and a vendor risk review (see our guide to vendor risk management).
- Make sure employees accept the policies at onboarding and annually.
3. Identity and access
- Single sign-on for every in-scope tool, with MFA enforced everywhere, including the cloud console and code repositories.
- Role-based access with least privilege; separate admin accounts for production.
- Documented joiner–mover–leaver process. Access removed within 24 hours of termination, with a ticket as proof.
- Quarterly access reviews, with the reviewer's sign-off saved as evidence.
4. Infrastructure and endpoints
- EDR on every company laptop, disk encryption on, screen lock enforced, managed by an MDM.
- Encryption of customer data at rest and in transit (TLS 1.2+).
- Centralised logging with alerting on security events, and a defined review cadence.
- Vulnerability scanning on a schedule, with remediation SLAs by severity, plus an annual penetration test of the application.
- Backups tested by an actual restore at least annually.
5. Change management and SDLC
- Pull requests reviewed by someone other than the author before merging to production.
- Branch protection that prevents direct pushes to main.
- Separate development, staging and production environments; no customer data in development.
- Dependency and secret scanning in CI.
6. People
- Background checks where lawful, confidentiality agreements, security awareness training at hire and annually.
- An org chart and job descriptions that show who is responsible for security.
7. Incident response and continuity
- A written incident response plan with roles, severity levels and customer-notification steps.
- One tabletop exercise per year, documented with lessons learned (our tabletop guide shows how).
- A business continuity and disaster recovery plan with recovery objectives, tested.
8. Evidence and audit readiness
- Use a compliance automation platform or a disciplined evidence folder, mapped control by control.
- Run a readiness assessment (a mock audit) before you engage the CPA firm, and fix the gaps first.
- Choose an auditor with SaaS experience. Agree the scope, the period and the report delivery date in writing.
Common SOC 2 mistakes we see
- Scoping too wide. Including every criterion and every internal tool on the first report multiplies the work.
- Policies that don't match reality. Auditors test what you wrote. A policy promising quarterly reviews you don't do is a finding.
- Treating the tool as the program. Automation platforms collect evidence; they don't make decisions, own risk or fix your cloud configuration.
- No owner after the report. Type II needs controls to run all year. Without an owner, year two is harder than year one.
A realistic 90-day readiness plan
| Weeks | Work | Output |
|---|---|---|
| 1–2 | Scoping workshop; pick criteria; inventory systems, vendors and people in scope | Scope statement and system description draft |
| 3–4 | Gap assessment against the common criteria; risk assessment | Gap register with owners and dates |
| 5–8 | Write and approve policies; implement missing controls (SSO/MFA, MDM, logging, branch protection, vendor reviews) | Approved policy set; controls live |
| 9–10 | Evidence collection; access review; tabletop exercise; backup restore test | Evidence mapped to each control |
| 11–12 | Mock audit; fix findings; auditor selection and kickoff | Audit-ready; Type I fieldwork or Type II window starts |
The plan compresses when SSO, MDM and logging already exist, and stretches when the production environment was built quickly by a few engineers with broad access, which is the norm at Series A.
Frequently Asked Questions
How long does SOC 2 take for a startup?
Readiness typically takes 2–4 months, depending on how many controls already exist. A Type I report can follow straight away. A Type II adds an observation period, commonly 3–12 months, before the report is issued.
Is SOC 2 required by law?
No. SOC 2 is voluntary, but many enterprise customers require it contractually before they share data or sign.
Can we get SOC 2 without a full-time security hire?
Yes. Many startups use a vCISO or fractional security lead to own the program, with engineering implementing the controls.
Which Trust Services Criteria should we include?
Start with Security, which is mandatory. Add Availability or Confidentiality only when customer contracts require them.
Do we need a penetration test for SOC 2?
SOC 2 doesn't prescribe one, but most auditors and enterprise buyers expect an annual application penetration test as evidence of vulnerability management.
Need SOC 2 for a deal this year? Defensible runs SOC 2 readiness end to end, from scoping and policies to control implementation and auditor handoff, led by former Stroz Friedberg security leaders. Get SOC 2 Ready.
