Most SaaS companies don't fail a SOC 2 audit because their security is terrible. They fail — or bleed time and money — because they started the audit before they were ready. Readiness is the unglamorous work that happens before the auditor shows up: choosing what you're auditing, finding the gaps, writing the policies, and actually operating the controls long enough to prove they work. This SOC 2 readiness checklist walks through every phase of that work, in the order you'd actually do it.
SOC 2 is an AICPA attestation framework. An independent licensed CPA firm examines whether your controls satisfy the Trust Services Criteria and issues a report your customers can rely on. Your job during readiness is to make sure that when they look, there's something solid to look at.
1. Choose your Trust Services Criteria
The Trust Services Criteria are the backbone of every SOC 2 audit. Security is mandatory — it's the Common Criteria that applies to every engagement. The other four are optional, but enterprise customers routinely ask for them, and adding one later costs almost as much as including it from the start.
- Security (required) — protecting systems and data against unauthorized access. This is the foundation: access controls, network security, change management, risk assessment.
- Availability — systems are available for operation and use as committed. Think uptime SLAs, backup and recovery, capacity monitoring, incident response.
- Processing Integrity — system processing is complete, valid, accurate, timely, and authorized. Relevant if your product processes customer transactions or data where errors would be costly.
- Confidentiality — information designated as confidential is protected as committed. Covers encryption, data classification, and restricted disclosure.
- Privacy — personal information is collected, used, retained, disclosed, and disposed of in line with your commitments. This is the heaviest lift of the four; include it only if your customers' security questionnaires demand it.
Practical advice: for most B2B SaaS companies, Security plus Availability plus Confidentiality covers what buyers ask for. Don't add Privacy "just in case" — it roughly doubles the evidence burden.
2. Define your audit scope
Before anything else, you need to answer: what exactly is being audited? The scope defines the systems, people, processes, and data included in the audit boundary. Scope creep is the number one cause of delayed audits, so get this crisp early.
- In-scope systems — your production application, cloud infrastructure (AWS/GCP/Azure accounts), CI/CD pipelines, logging and monitoring tools, and the corporate devices and identity provider (e.g., Okta, Google Workspace) your team uses to reach production.
- In-scope people — everyone with access to the system: employees, contractors, and vendors with production access.
- In-scope data — the customer data your controls protect, and where it flows.
- System description — the narrative section of the final report describing your company, infrastructure, and controls. Start drafting it during readiness; it's much easier than writing it under audit pressure.
3. Run a gap assessment
A gap assessment maps each applicable Trust Services Criterion against your current state and produces a prioritized remediation list. Most companies either do this internally against the criteria or hire a consultant for an independent readiness assessment. Either way, the output should be the same: a spreadsheet of controls, a pass/fail/partial rating for each, and an owner and deadline for every gap.
The gaps that show up at nearly every first-time company are depressingly consistent: no formal risk assessment, policies that exist only in someone's head, access reviews nobody does, vendor reviews nobody documents, and incident response that's never been tested. Expect to find all of them. Finding them now is the entire point — an auditor finding them later is an exception in your report.
4. Write the policies (and actually approve them)
Auditors don't accept "everyone knows the policy" as a control. Policies must be written, approved by management, communicated to employees, and reviewed annually. The core policy set for a first SOC 2 audit:
- Information security policy — the master policy that defines roles, responsibilities, and the control framework.
- Access control policy — how accounts are provisioned, reviewed, and deprovisioned, including least-privilege and MFA requirements.
- Change management policy — how code moves to production: peer review, testing, approval, and rollback.
- Incident response plan — roles, escalation paths, communication templates, and post-incident review requirements.
- Business continuity and disaster recovery plan — backup procedures, recovery objectives, and how you'll test them.
- Vendor management policy — how you evaluate, onboard, and periodically review third-party services.
- Data classification and retention policy — how data is labeled, encrypted, retained, and destroyed.
- Risk assessment methodology — how you identify, score, and treat security risks.
- Acceptable use policy — signed by every employee and contractor during onboarding.
Buy templates rather than writing from scratch, but tailor them to what you actually do. An auditor will notice a policy that describes processes your company doesn't have — and that mismatch is worse than a shorter, honest policy.
5. Lock down access controls
Access control exceptions are the most common findings in first-time audits. The full checklist:
- MFA everywhere — production, cloud console, CI/CD, version control, the identity provider itself, and every SaaS app that touches customer data. No exceptions for founders.
- Least privilege — access grants match job function; admin rights are rare and documented.
- Joiner/mover/leaver process — provisioning tied to HR onboarding, role changes trigger access updates, and terminations revoke access the same day (this is the single most-tested control in Type 2 audits).
- Quarterly access reviews — a named reviewer certifies each system's user list every quarter, with sign-off evidence retained.
- Password and authentication standards — enforced via the identity provider, not via a policy document nobody enforces.
6. Build your vendor management program
Every subservice organization in your stack — your cloud provider, your payment processor, your monitoring tools — inherits into your control environment. Auditors will ask how you evaluate them.
- Maintain a vendor inventory listing every service that touches customer data or the production environment.
- Perform a risk assessment per vendor before onboarding and annually thereafter, with the risk tier documented.
- Collect SOC 2 reports (or equivalent) from critical vendors and review them — not just file them. Note any exceptions and how you address them.
- Ensure contracts include security commitments — data protection clauses, breach notification terms, and right-to-audit language where appropriate.
7. Put monitoring in place
For Type 2, you must show controls operated consistently across the observation window. That requires real monitoring infrastructure:
- Centralized logging — authentication events, admin actions, and production access, retained for at least the length of your observation window.
- Vulnerability management — scheduled scans, a defined SLA for remediation by severity, and evidence both happened.
- Change management evidence — every production change tied to a ticket with peer review and approval.
- Backup and recovery testing — backups run on schedule and restores are actually tested, with results documented.
- Penetration testing — at least annually, by a qualified third party, with findings tracked to closure.
- Security awareness training — completed by all staff at onboarding and annually, with completion records.
8. Run a formal risk assessment
This is the step first-timers skip most often, and auditors notice immediately. Once a year, management must identify the risks that could prevent your objectives from being met, assess their likelihood and impact, and document how you treat them. It doesn't need to be a 200-page document — a structured workshop with a risk register is enough — but it must exist, be signed off by leadership, and be revisited when your environment changes materially.
9. Collect evidence like an auditor
During the Type 2 observation window (typically 3–12 months, most commonly 6), you're not just operating controls — you're collecting proof. Set up evidence collection from day one of the window:
- Access review sign-offs with dates and reviewer names.
- Onboarding and termination tickets with timestamps.
- Change tickets showing peer review and approval.
- Incident tickets, even for minor events, showing the process was followed.
- Vendor review records and collected SOC 2 reports.
- Training completion exports and policy acknowledgment records.
- Pen test reports and vulnerability scan results with remediation tracking.
- Backup logs and restore test results.
The rule of thumb: if a control operated but you can't prove it, the auditor treats it as if it didn't happen. Automate evidence collection where you can — screenshots taken by hand in week 26 of the window are where audits go to die.
10. Common audit failure points to eliminate first
These are the findings that appear in first-time SOC 2 reports with depressing regularity. Clear them before the auditor arrives:
| Failure point | What the auditor sees | The fix |
|---|---|---|
| Missed access reviews | Quarterly review skipped or unsigned | Calendar the reviews; assign a named owner |
| No risk assessment | No documented annual assessment | Run one before the window starts |
| Stale policies | Policies never approved or reviewed | Approval signatures + annual review cycle |
| Vendor reports missing | Critical vendor's SOC 2 never collected | Vendor inventory + annual collection cadence |
| MFA gaps | Even one admin account without MFA | Enforce via IdP; audit the exception list to zero |
| Change control theater | Production deploys without tickets | Branch protection + required reviews in CI/CD |
| Untested incident response | Plan exists but never exercised | Tabletop exercise with documented participants |
Realistic readiness timeline
For a SaaS company of 10–50 people starting from a typical state (some policies, decent engineering hygiene, no formal program), expect:
- Weeks 1–2: Choose criteria, define scope, select your auditor.
- Weeks 3–4: Gap assessment; prioritized remediation plan with owners.
- Weeks 5–10: Remediation — write and approve policies, implement access reviews, stand up logging and monitoring, run the risk assessment, start vendor reviews.
- Weeks 11–12: Readiness dry run — an independent consultant or your auditor walks through the evidence and tells you what's still missing.
- Then: Type 1 point-in-time audit (if needed for a deal), or the Type 2 observation window begins — only once controls are actually operating.
That's roughly 8–12 weeks of readiness before a Type 1, and the same 8–12 weeks plus a 3–12 month observation window before a Type 2 report. If someone promises you a Type 2 report in six weeks from a standing start, they're selling you something else. For the full picture of what each phase costs and how long it takes, see our guides on SOC 2 compliance cost and how long SOC 2 takes.
How to know you're ready
Readiness isn't a feeling. Before you sign the audit engagement letter, you should be able to answer yes to all of these:
- Every control in scope has a named owner who knows they're the owner.
- Policies are written, approved by management, and acknowledged by employees.
- Access reviews have run at least once with signed evidence.
- A risk assessment is documented and signed off by leadership.
- Vendor inventory exists, critical vendor SOC 2 reports are collected and reviewed.
- Logging covers the full observation window with no gaps.
- An independent readiness assessment found no material gaps — or every gap found has been closed with evidence.
If you can't say yes to all seven, you're not ready — and starting the audit anyway just means paying auditor rates to discover what a readiness assessment would have told you for less.
Bottom line
- Readiness is a 10-step program: criteria → scope → gap assessment → policies → access controls → vendors → monitoring → risk assessment → evidence → dry run.
- The Type 2 observation window can't start until controls are operating — readiness comes first.
- The most common failures are boring and preventable: missed access reviews, no risk assessment, stale policies, missing vendor reports.
- An independent dry run before the real audit is the cheapest insurance you can buy.