A SOC 2 readiness checklist is only useful if it reflects what an examiner will actually ask for. Most published checklists are inventories of policies, which is the easiest part of the work and the part that fails least often.
What actually causes delay is narrower: controls that exist informally and have never produced evidence, a scope drawn too wide, and periodic controls that have not operated once inside the observation window. This is a checklist built around those.
Before anything else: three scoping decisions
These determine the cost of the entire programme and they are made before a single control is written.
1. The system boundary. Which product, which infrastructure, which supporting processes. Companies routinely draw this around the whole organisation when the customer commitment concerns one product. Every additional system inside the boundary means more controls, more evidence and more fieldwork, permanently.
2. Which Trust Services Categories. Security is mandatory. Availability, confidentiality, processing integrity and privacy are elective, and each one added expands the examination. Before adding any, ask the customer who requested SOC 2 what they actually need to see; the answer is very often security alone.
3. The observation window. Three months is standard for a first Type 2, extending to six or twelve on renewal. Shorter reaches a report sooner; longer is what mature enterprise buyers eventually expect.
The gaps that appear in almost every first engagement
After enough readiness assessments the list stops varying much:
- No documented risk assessment. The criteria require one. Most companies have sensible security practices and nothing recording the risk analysis that drove them.
- Access reviews never performed, or performed without evidence. The review happened; nothing records that it happened, who did it, or what they concluded.
- Vendor management as a list of names. No risk tiering, no subservice organisation SOC reports obtained, and (the item nobody reads) no mapping of the complementary user entity controls those reports specify.
- Onboarding and offboarding with no artefact. The process is followed reliably. Nothing evidences that it was followed for a named person on a named date.
- An incident response plan nobody has exercised. A plan that has never been walked through is a document, not a control.
- Change management bypassed for hotfixes. Legitimate under pressure, undocumented afterwards, and the first thing an examiner samples.
- Policies written and never acknowledged. Without an acknowledgement record there is no evidence anyone was informed.
None of these are technically difficult. They take longer to fix than companies expect because most require a control to operate for a period before it can be tested; which is why finding them during readiness rather than during fieldwork matters so much.
The SOC 2 readiness checklist itself
Governance and risk
- Documented risk assessment, refreshed at a defined interval, with identified risks mapped to controls
- Information security policy set, approved by someone with the authority to approve it, and acknowledged by staff with a retained record
- Defined security ownership, a named individual, not a committee
- Board or leadership oversight of the security programme, evidenced in minutes
Access management
- Provisioning tied to a documented approval
- Offboarding tied to a trigger that fires reliably, with evidence per departure
- Periodic access review with evidence of what was reviewed and what changed as a result
- Privileged accounts inventoried and individually justified
- Multi-factor authentication enforced, with exceptions documented and approved
- No shared or generic accounts, or, where genuinely unavoidable, compensating controls that attribute activity
Change management
- Changes authorised, tested and approved before production release
- Separation between whoever writes a change and whoever deploys it
- Emergency change process with retrospective review that actually occurs
- Infrastructure changes under the same control as application changes
Operations and resilience
- Monitoring and alerting on the events that matter, routed to someone who acts on them
- Backups running, and a restore tested within the period; configuration is not evidence
- Incident response plan exercised, with the exercise documented
- Vulnerability management with defined remediation timeframes by severity
- Penetration test performed within the period, with findings tracked to closure
Vendor and third party
- Inventory built from expense data and SSO logs rather than from memory
- Risk tiering by data sensitivity and business dependency
- SOC 2 or equivalent obtained for material vendors, and requested at the start of the window, since this is the delay you cannot control
- Complementary user entity controls extracted and assigned to named owners
Cost and timeline, without the optimism
Published 2026 market data puts specialist-firm SOC 2 Type 2 audit fees broadly in the $15,000,$50,000 range, with national firms materially higher. Total first-year programme cost (audit plus readiness plus tooling plus internal time) commonly lands between $30,000 and $80,000 for a small or mid-sized company.
The line items most often missing from a first budget: penetration testing, the annual compliance platform subscription, and remediation itself, which is unknowable until readiness is complete. That last point is the actual argument for doing readiness first, it converts an open-ended number into a budget.
On timeline, plan nine to twelve months from a standing start, or around six if you are organised and use a three-month window with an automation platform. The window itself cannot be compressed. That period is the evidence.
Two things worth deciding early
Skip Type 1 unless a deal requires it. A large share of companies go straight to Type 2, and if controls are genuinely operating there is little reason to spend on a point-in-time design report most enterprise buyers do not want. Type 1 earns its place when a live deal needs visible progress inside weeks.
Do not let a platform choose your scope. Compliance automation genuinely reduces cost through automated evidence collection and continuous monitoring. It does not decide your system boundary, judge whether a compensating control is adequate, or remove the auditor's fee. Scope first, select the tool second, the reverse produces a tool configured against a boundary nobody agreed.
Where to go next
If a customer deadline is already attached to this, the sequence that works is a readiness assessment first, remediation second, and the observation window opened only once controls are actually running.
If you also have financial statement audit or SOX obligations, scope the ITGC work alongside it. The control sets overlap by a wide margin and testing once to report twice removes a substantial amount of duplicated effort.