The SOC 2 Readiness Checklist We Run Before Every Audit

The gap-assessment checklist we walk every client through before they spend a dollar on an auditor.

Damien Blue
June 5, 2026 · 5 min read

The fastest way to waste money on SOC 2 is to call an auditor before you're ready. The CPA shows up, finds a pile of gaps, and you spend the next three months fixing things you could have caught yourself — while the engagement clock runs. So before any client of mine talks to an auditor, we run the same gap assessment. It's not glamorous. It's a list of questions, organized by control area, that surfaces the holes while they're still cheap to fix.

This is that list. Walk it honestly, mark each line, and the items you can't check are your roadmap. Every "no" is a gap to close before you pay anyone to find it for you.

Access control and MFA

This is where most audits start and where the most "no"s tend to land.

[ ] MFA is enforced on every system that supports it — email, cloud console, identity provider, code host, production.
[ ] You have a single identity provider (SSO) wherever possible, so access is centrally managed.
[ ] User access follows least privilege: people have only the permissions their role needs.
[ ] You run access reviews on a defined schedule (quarterly is typical) and keep evidence that they happened.
[ ] Admin and production access is restricted to a named, minimal group.
[ ] Terminated employees lose access promptly, and you can prove the timeline.

Change management

[ ] Code changes go through pull requests with required peer review before merge.
[ ] Production deploys are tracked, with a clear record of what shipped and when.
[ ] You separate, or at least monitor, who can write code from who can push to production.
[ ] Infrastructure changes are version-controlled or otherwise documented.
[ ] You can show an auditor a sample of changes with their approvals and review trail.

Logging and monitoring

[ ] Production systems generate logs, and those logs are centralized and retained.
[ ] You have alerting on security-relevant events (failed logins, privilege changes, new admin grants).
[ ] Someone is actually responsible for reviewing alerts — not just collecting them.
[ ] Logs are protected from tampering and retained long enough to cover your audit window.

Vendor and third-party risk

[ ] You maintain a current list of vendors and subprocessors that touch customer data.
[ ] You collect and review each critical vendor's security posture — their SOC 2, ISO 27001, or a completed questionnaire.
[ ] You re-review key vendors on a schedule, not just at onboarding.
[ ] Data processing agreements are in place where they're required.

If this section is a blank stare, start with our vendor risk assessment checklist — auditors will absolutely ask how you vet the companies you depend on.

Advertisement
Your ad-network slot renders here

HR, onboarding, and offboarding

[ ] New hires go through background checks where appropriate and sign your security and acceptable-use policies.
[ ] Onboarding provisions access through a repeatable, documented process.
[ ] Offboarding revokes all access promptly and you can evidence the date.
[ ] Employees complete security awareness training, and you track completion.

Policies and documentation

[ ] You have written policies covering security, access control, change management, incident response, and data handling.
[ ] Policies are version-controlled and reviewed at least annually.
[ ] Employees have acknowledged the policies that apply to them, with a record of it.
[ ] Your policies describe what you actually do — not aspirational language you don't follow. Auditors test the gap between the two.

Incident response

[ ] You have a written incident response plan with defined roles and steps.
[ ] The plan has been tested at least once — a tabletop exercise counts and is far better than nothing.
[ ] You know your breach-notification obligations and timelines.
[ ] Past incidents, if any, are documented with what happened and what you changed.

Data handling and encryption

[ ] Data is encrypted in transit (TLS everywhere) and at rest.
[ ] You know where customer data lives and which systems can reach it.
[ ] Encryption keys and secrets are managed properly — not hardcoded, not in a shared doc.
[ ] You have a data classification and retention approach, even a simple one.
[ ] Backups exist, are encrypted, and you've tested a restore.

Business continuity and availability

[ ] You have a documented backup and disaster-recovery approach.
[ ] Recovery targets (how fast, how much data loss is tolerable) are written down.
[ ] You've actually tested recovery, not just planned for it.

One caveat: if you're scoping to Security only, some availability items here are good practice rather than strict requirements. Don't pull extra Trust Services Criteria into scope just because a checklist line caught your eye — that's how budgets balloon, as I covered in what SOC 2 costs.

What to do with your gaps

Once you've marked every line, you'll have a column of "no"s and "partial"s. That column is your readiness plan. Tackle the three highest-impact areas first — access reviews, change management, and vendor risk are usually the ones that block a clean report — then work down the list. Close the gaps, run the controls for long enough to generate evidence, then call the auditor.

For the bigger picture of how this fits the whole process, the SOC 2 guide lays out the order I'd tackle everything in. Run this checklist first, and your auditor's findings will be a formality instead of a surprise.

Want this as a fill-in tracker — yes/no/partial columns and a gap-summary tab? Drop your email below and we'll send you the downloadable spreadsheet version of this checklist.