22 May 2026

Preparing for a SOC 2 Audit: A Practical Checklist

A SOC 2 audit isn’t a test you cram for — it’s a period of time your auditor observes, and the outcome depends almost entirely on what happened before the auditor walked in. Here are the phases, in order, with what to do in each.

First, know which kind you’re running: - Type I — a point-in-time assessment of your control design. Faster, cheaper, weaker signal. - Type II — the observation window is typically 3–12 months; the auditor tests that controls operated throughout. This is what customers actually want.

Phase 1 — Scoping (weeks 1–2)

• Write/refine the system description: what the service is, the boundaries, in-scope entities and systems, exclusions.
• Choose your Trust Service Criteria: Security (always) + any of Availability, Processing Integrity, Confidentiality, Privacy. More categories = more evidence.
• Pick your auditor and get their engagement letter signed.
• Set the observation window (Type II) — start collecting evidence on day one of it, not after the auditor arrives.

Phase 2 — Control design (weeks 2–4)

• Map every applicable CC criterion to a control you can evidence (e.g., CC6.1 → MFA enforcement on all admin and production access).
• Assign an owner per control.
• Write or update the policy set — information security, access control, change management, incident response, vendor management, acceptable use. Policies should match what you actually do; auditors spot fiction fast.
• Document the control environment: org chart, roles, reporting lines.

Phase 3 — Evidence collection (ongoing, entire window)

This is the phase where audits are won or lost. Per control, collect:

• Configuration proof — MFA enforcement, encryption at rest/in transit, SSO settings (dated screenshots or exports).
• Access review records — quarterly user access reviews with sign-off.
• Offboarding records — access removal within X days of termination.
• Change records — change requests, approvals, deployments for the window.
• Incident log — incidents, near-misses, triage, remediation (an empty log is fine; an unexplained gap is not).
• Risk assessment — dated, with treatment decisions.
• Vendor inventory — with security reviews / SOC 2 reports / BAAs as applicable.
• Training records — security awareness completion for the window.
• Penetration test report (or equivalent) — with findings addressed.

Keep each control’s evidence on one page, dated, with a “last verified” line. If your evidence lives in Confluence, the auditor can review it live instead of chasing your zips.

Phase 4 — Pre-assessment / gap review (2–4 weeks before the audit)

• Run (or commission) a gap assessment: for each control, “can I show design + operation for the whole window?”
• Fix the gaps before the auditor finds them — remediation after fieldwork is slow and sometimes too late for the window.
• Assemble the PBC list (prepared-by-client documents). The standard set: system description, policy set, org chart, user access list, MFA/encryption configs, risk assessment, change records, incident log, vendor inventory, training records, pen test report.

Phase 5 — The audit

• Give the auditor one door — a shared space where controls and evidence live, not a folder of emailed files.
• Assign one internal point of contact who answers fast.
• Track every auditor question to closure.

Phase 6 — After the report

• Read the report; note any exceptions (control failures in the window).
• Remediate exceptions with a dated plan.
• For Type II, the window is rolling — your next audit starts collecting evidence the day this one ends. Start the calendar now.

Where teams blow it

The three most common failure modes: (1) starting evidence collection after signing with the auditor, (2) policies that describe a process nobody follows, and (3) evidence scattered across drives so the auditor sees version drift. All three are scheduling and structure problems — not security problems.

TinyGRC keeps the whole checklist alive in Confluence: SOC 2 controls tracked per criterion, evidence attached and dated, a pre-assessment progress view, and a live auditor collaboration space. Free trial on the Atlassian Marketplace.

FAQ

How long does a SOC 2 audit take? Type I: a few weeks of auditor time plus your prep. Type II: 3–12 months of observation window + a few weeks of fieldwork. The prep (phases 1–4) typically takes 2–3 months for a small team doing it for the first time.

What does a SOC 2 pre-assessment include? A control-by-control gap review against your chosen Trust Service Criteria: what you claim, what evidence you can show, and where the gaps are — with a remediation plan and timeline. It’s the difference between entering fieldwork with surprises and entering it with a list you’ve already mostly cleared.

How much does SOC 2 cost for a small business? Auditor fees commonly range from a few thousand to $20k+ depending on scope and criteria, plus internal staff time — and the cost of whatever tooling you use. The internal time is usually the bigger number, which is why keeping evidence organized from day one matters more than the tool’s price tag.

Previous: SOC 2 vs HIPAA vs ISO 27001: Which Do You Actually Need?