SOC 2 Readiness Checklist: 12 Things to Have Before the Auditor Arrives

A SOC 2 engagement goes badly for one reason far more than any other: the company starts collecting evidence before it has decided what the report will cover. Here is the order that avoids the rework, drawn from the SOC 2 programs we have run for SaaS companies and service providers.

1. Decide what system the report describes

The "system" in a SOC 2 report is your defined service — the application, the infrastructure it runs on, the people who operate it and the data it handles. Draw the boundary first. Everything inside it is in scope; everything outside is not. A boundary drawn around one product is far cheaper to evidence than one drawn around the whole company.

2. Pick the Trust Services Criteria your customers actually ask for

Security is mandatory. Availability, Confidentiality, Processing Integrity and Privacy are optional and each adds criteria to evidence. Pull the last ten security questionnaires you received and count which criteria they map to. Most SaaS companies land on Security plus Availability and Confidentiality.

3. Choose Type I or Type II — and plan the window

A Type I attests that controls are designed properly at a point in time. A Type II attests they operated over a period, usually six to twelve months. If a customer contract requires a Type II by a date, work backwards: the observation window has to start at least six months before you need the report, and readiness has to finish before the window opens.

4. Write the policies for how you actually work

Auditors test whether you follow your policies. A policy that says access is reviewed monthly, when it is reviewed quarterly, is a finding. Write the policy to match the practice you can sustain, then tighten the practice over time.

5. Put a named owner on every control

A control matrix with an owner, a frequency and an evidence type for each control is the backbone of the program. When the auditor asks who approves production changes, there should be a name, not a team.

6. Enforce MFA and single sign-on everywhere in scope

This is the control auditors test first and the one most often found incomplete. Every system in the boundary — cloud console, code repository, CI/CD, ticketing, email — needs MFA, and joiner/mover/leaver access needs to run through one identity provider so provisioning and deprovisioning leave a record.

7. Ticket every production change

Change management evidence is a sample of changes with a request, an approval and a deployment record. If deploys happen from a laptop with no ticket, start ticketing now; the auditor will sample from the whole observation window.

8. Turn on logging and prove someone looks at it

Centralized logs are necessary but not sufficient. The control is that alerts are defined and reviewed. Keep a record of alert triage, even when the answer is "false positive."

9. Run and document a vendor review

Every subservice organization inside your boundary — your cloud provider, your payment processor, your email vendor — needs a documented risk review, typically by collecting their own SOC 2 report and noting the complementary user entity controls you are responsible for.

10. Test backups and the incident response plan

A backup that has never been restored is not evidence of availability. Do one documented restore test and one tabletop incident exercise before the window opens; both are near-universal auditor requests.

11. Complete background checks and security training

For everyone inside the boundary: a background check at hire and annual security awareness training with completion records. These are simple, and they are among the most commonly missing artifacts.

12. Select the audit firm before readiness ends

Only a licensed CPA firm can issue the report. Engage them before the observation window starts so their control list and yours are the same list. Ask how they handle exceptions, what their sampling approach is and whether they issue a bridge letter between reports.

Where companies get stuck

The pattern is nearly always the same: strong engineering controls, weak documentation, and no evidence for the first two months of the window because nobody was collecting it. The fix is to treat evidence collection as an operating rhythm — a calendar of what is captured weekly, monthly and quarterly — and to start it the day the window opens.

If you want an outside read on where you stand, a scoped gap assessment scores every criterion in your intended report and tells you how far you are from opening the window.