The SOC 2 Readiness Checklist: Step-by-Step
A step-by-step SOC 2 readiness checklist: scope your Trust Services Criteria, run a risk assessment, harden access, and collect evidence before the audit.
What “readiness” actually means
SOC 2 readiness is everything you do before a CPA firm starts the audit: picking your scope, standing up controls, and gathering the proof those controls actually run. A SOC 2 report is an AICPA attestation performed under SSAE 18, issued by a licensed CPA firm against the Trust Services Criteria. It is not a certification you buy, and it is not a checkbox you tick. A Type I engagement opines on whether your controls are suitably designed at a point in time; a Type II adds a test of whether they operated effectively across a period. Readiness is how you make sure the auditor finds what they need.
Skip readiness and you get the result every rushed startup gets: a report full of exceptions, or an auditor who tells you three months in that you have no evidence for half your controls. Do it deliberately and the audit becomes a formality.
This SOC 2 readiness checklist walks the ten phases in the order they actually depend on each other. Each step explains why it matters, because a checklist you follow without understanding is a checklist you’ll implement wrong.
The 10-step SOC 2 readiness checklist
1. Define your scope and select Trust Services Criteria
Decide which systems, products, and data are in scope, then choose your criteria. Security (the Common Criteria) is mandatory for every SOC 2. Availability, Processing Integrity, Confidentiality, and Privacy are optional and scope-driven — add them only when a customer contract or your product genuinely demands it. A SaaS platform with an uptime SLA usually adds Availability; a payments processor may add Processing Integrity; most early-stage startups start with Security alone.
Why it matters: scope determines cost, timeline, and evidence volume. Every extra criterion adds controls and testing. See the 5 Trust Services Criteria to decide what belongs in your first report, and Type I vs Type II to pick the report type.
2. Run a risk assessment
Document the risks to the systems in scope — threats, vulnerabilities, and the likelihood and impact of each — then map your controls to those risks. This is not busywork: the Common Criteria (CC3 series) explicitly require a risk-assessment process, and auditors will ask to see it as evidence.
Why it matters: it is a required control and it tells you which of the following steps to prioritize. A risk assessment that surfaces “no MFA on the production database” tells you where to spend the next two weeks.
3. Write your policies
You need a written policy set: information security, access control, change management, incident response, business continuity, vendor management, data classification, and acceptable use, among others. Policies must reflect what you actually do — an auditor tests operating effectiveness against the policy, so an aspirational policy you don’t follow generates exceptions.
Why it matters: policies are the design layer of your controls. If the policy says access is reviewed quarterly, you now owe four quarters of review evidence in a Type II window.
4. Lock down access control and enforce MFA
Implement least-privilege access, role-based permissions, and MFA everywhere it can go — SSO, cloud consoles, production infrastructure, code repositories, and admin panels. Build a joiner/mover/leaver process so access is provisioned on hire and revoked the day someone leaves. Run and log periodic access reviews.
Why it matters: access control is the densest cluster of Common Criteria controls (the CC6 series) and the most common source of audit exceptions. Deprovisioning gaps — a former contractor who still has GitHub access — are exactly what auditors look for.
5. Stand up logging and monitoring
Centralize logs from your infrastructure, applications, and security tooling. Configure alerting for security-relevant events, retain logs for a defined period, and make sure someone actually reviews the alerts. Vulnerability scanning and endpoint protection live here too.
Why it matters: you cannot prove detection without logs, and the observation period (step 10) requires continuous evidence that monitoring ran the whole time — not a screenshot from the week before the audit.
6. Manage vendors and third parties
Inventory every subprocessor and vendor that touches customer data. Collect their SOC 2 reports (or equivalent), assess their risk, and set a review cadence. Your report inherits risk from your vendors, so the auditor expects a real vendor-management process, not a spreadsheet you assembled the night before.
Why it matters: a breach at a critical vendor is your incident too. This is also one of the mistakes startups make most often — underestimating how much evidence third-party oversight requires.
7. Formalize change management
Every production change should go through version control, peer review (pull-request approval), CI/CD checks, and a documented deploy path. Separate the person who writes the code from the person who approves the merge where you can, and ticket the change so there’s a trail.
Why it matters: change management proves you don’t ship unreviewed code to production. Auditors sample deploys from your observation window and trace each back to an approval, so the control has to be enforced by tooling, not the honor system.
8. Collect evidence continuously
This is where readiness lives or dies. For every control you need artifacts that prove it operated: access-review records, deploy logs, alert tickets, onboarding checklists, policy acknowledgments, scan results. Type I evidence is a point-in-time snapshot; Type II evidence must span the entire observation period.
Why it matters: manual, once-a-quarter evidence collection is where teams sink the most time and still show up short. This is the single biggest argument for automation — a platform like avow connects to your cloud, identity provider, and code host to pull evidence continuously, so nothing has to be reconstructed from memory. If you’re doing it by hand, start the collection habit now, not the month before fieldwork.
9. Pick an auditor
Engage a licensed CPA firm early — good ones book out. Compare on price, industry experience, turnaround time, and whether they’ll run a readiness assessment first. Get the engagement letter signed before your observation window starts so the auditor can confirm your scope and control set up front.
Why it matters: only a licensed CPA firm can issue a SOC 2 report. The wrong firm shows up as a slow, painful audit and a report your customers’ security teams don’t respect. Budget realistically — see how much SOC 2 costs.
10. Run the observation period
For a Type II, controls must operate effectively over a defined period, commonly 3 to 12 months (first-timers often choose 3). During this window your controls run in production and your evidence accumulates. When it closes, the auditor performs fieldwork — sampling and testing — and issues the report.
Why it matters: the observation period is non-negotiable calendar time. No amount of money compresses a 3-month window. Plan backward from the date you promised a customer the report — see how long SOC 2 actually takes.
Which controls map to which evidence
| Readiness area | Primary criteria | Example evidence an auditor samples |
|---|---|---|
| Access control + MFA | CC6 (Security) | Access reviews, MFA config, offboarding tickets |
| Change management | CC8 (Security) | PR approvals, deploy logs, CI results |
| Logging + monitoring | CC7 (Security) | Alert tickets, log-retention config, scan reports |
| Risk assessment | CC3 (Security) | Risk register, treatment plan, review dates |
| Vendor management | CC9 (Security) | Vendor inventory, subprocessor SOC 2 reports |
| Availability (optional) | A1 | Backups, DR tests, uptime monitoring |
Type I vs Type II: how readiness differs
If you’re going straight to Type II, readiness is heavier — you need controls running for the whole observation window, not just designed. A Type I is a point-in-time design opinion, so readiness can be shorter, and many teams use it as a stepping stone to a Type II a few months later. The controls are the same; the difference is how long you have to prove they work. Read the full Type I vs Type II breakdown before you commit, and if you’re new to the framework, start with what SOC 2 is.
A realistic sequence
- Weeks 1-2: scope, TSC selection, risk assessment.
- Weeks 2-6: policies, access control, MFA, logging, change management.
- Weeks 4-8: vendor inventory, evidence pipeline, auditor engagement.
- Observation period opens once controls are live and generating evidence.
The mistake is treating these as sequential quarters. Steps 1-9 overlap heavily; the goal is to have every control operating and producing evidence on the day your observation window opens. Automating evidence collection from the start is the difference between a calm audit and a scramble.
Next steps
Work this list top to bottom, fix the gaps your risk assessment surfaces first, and get your evidence pipeline running before the clock starts. When you’re ready to see what fieldwork actually looks like, read your first SOC 2 Type II audit.