SOC 2 Audit Checklist: 12 Controls Auditors Check First
Most SaaS companies spend six to nine months preparing for SOC 2 Type II — and still get surprised on day one. The reason is almost always the same: they built controls without understanding what auditors actually test.
This checklist covers the 12 areas auditors examine first. Get these right before your audit window opens, and everything else follows.
What Auditors Are Actually Looking For
A SOC 2 audit tests whether your controls operated effectively over a defined period — typically 6 or 12 months. It's not a snapshot. Evidence must show consistent operation, not a one-time cleanup.
The framework is defined by the AICPA Trust Services Criteria — the authoritative source for what SOC 2 actually requires.
Before testing individual controls, auditors establish:
- That policies exist, are approved, and are communicated to staff
- That your control environment (org structure, risk assessment process) is documented
- That there's a defined scope: what systems, what people, what data
If any of these is missing, the audit doesn't proceed — it gets scoped down or the opinion is qualified.
The SOC 2 Audit Checklist
1. Security Policy Documentation
You need a formal Information Security Policy, reviewed and approved within the last 12 months, and evidence it was communicated to all employees (email distribution, intranet posting, or training acknowledgment records).
Common gap: Policy exists as a PDF on Google Drive with no proof anyone has seen it.
2. Access Control — Least Privilege
Every user account — employee, contractor, service account — should be provisioned with the minimum access required for their role. Auditors will sample 10–25 accounts and check whether each access grant was formally requested and approved.
Common gap: Engineers with admin access to production they haven't touched in 18 months.
3. Access Reviews
Quarterly (at minimum) access reviews for all systems in scope. Each review must be documented: who reviewed, what systems, which accounts were removed or changed.
Common gap: Reviews that happened verbally with no record.
4. Offboarding Procedures
Documented, timed evidence that terminated employees had access revoked. Auditors typically look for same-day or next-business-day revocation across all systems — not just active directory.
Common gap: SSO deprovisioned immediately, but legacy SaaS tools (GitHub, AWS IAM, Jira) missed.
5. Multi-Factor Authentication
MFA enforced on all systems in scope, for all users. "Enforced" means no way to bypass it — policy documents saying MFA is required are not sufficient without enforcement at the system level.
Common gap: MFA enabled but not enforced, or admin accounts exempted.
6. Vulnerability Management
A documented process for identifying, prioritizing, and remediating vulnerabilities. Auditors want to see scan results, severity classifications, remediation timelines, and evidence that critical findings were addressed within your stated SLA. Many teams align severity classifications to the NIST Common Vulnerability Scoring System (CVSS).
Common gap: Scans run but findings sit untracked. No defined SLA for remediation.
7. Change Management
All production changes go through a documented approval process: ticket created, peer review completed, approval recorded, deployment logged. Auditors will sample production deployments and check each one.
Common gap: Hotfixes pushed directly to production with no ticket or review.
8. Incident Response
A documented Incident Response Plan, tested within the last 12 months (tabletop exercise counts), and evidence that actual security incidents were handled according to the plan.
Common gap: Plan drafted but never tested. No incident log showing the process was followed for real events.
9. Backups and Recovery
Backups configured, tested, and documented. Auditors want to see: backup frequency, retention policy, and a recovery test showing backups are restorable. RPO and RTO targets should be documented.
Common gap: Backups configured but never tested. No recovery documentation.
10. Encryption in Transit and at Rest
All data classified as sensitive must be encrypted in transit (TLS 1.2 minimum) and at rest. Auditors will check your encryption configuration documentation and may inspect specific system settings.
Common gap: Encryption in transit enforced, but encryption at rest undocumented or inconsistent across data stores.
11. Vendor Risk Management
A process for evaluating third-party vendors who handle in-scope data. At minimum: a vendor inventory, a risk classification for each, and evidence that high-risk vendors were assessed (SOC 2 report reviewed, questionnaire completed).
Common gap: AWS and Stripe are in scope but no one has pulled their SOC 2 reports or documented the review.
12. Security Awareness Training
Annual (or more frequent) security training for all employees, with completion records. Phishing simulations count toward evidence if results are documented.
Common gap: Training completed but no completion records saved. Or training completed once two years ago with no recurrence.
How Long Does SOC 2 Preparation Take?
The honest answer: 3–6 months for Phase 1 (building controls from scratch), then a 6–12 month audit observation window before you have a Type II report.
If controls are already in place, Phase 1 compresses significantly — sometimes to 4–8 weeks of gap closure and documentation.
The variables that matter most:
- How many systems are in scope
- Whether you have existing documentation
- Team bandwidth to implement controls alongside product work
Frequently Asked Questions
Do I need SOC 2 Type I before Type II? No. Type I is a point-in-time snapshot; Type II covers a period of operation. Most companies skip Type I and go directly to Type II, which is what enterprise buyers actually require.
Which SOC 2 trust service criteria are required? Only Security (CC criteria) is required. Availability, Confidentiality, Processing Integrity, and Privacy are optional — include them only if customer contracts or your market require it. The full criteria are published by the AICPA in TSC 2017.
How much does a SOC 2 audit cost? Auditor fees typically range from $15,000–$40,000 for a Type II, depending on scope and auditor firm. Preparation costs — consultant time, tooling, team hours — often exceed the audit fee itself.
Can we fail a SOC 2 audit? There is no pass/fail. Auditors issue an opinion: unqualified (clean), qualified (exceptions noted), or adverse. A qualified opinion with minor exceptions is common for first-time audits. The goal is an unqualified opinion.
Ready to Start?
ShieldKey runs managed SOC 2 programs for SaaS and HealthTech companies — from gap assessment through audit support. We handle the documentation, evidence collection, and auditor coordination so your engineering team stays focused on the product.