The short answer
SOC 2 Type I readiness typically takes 10–14 weeks for an organisation with reasonable engineering hygiene. Type II requires an additional observation period of three to twelve months during which controls must operate continuously. Most of the effort is evidence collection rather than implementing new controls.
Key takeaways
- Type I proves design at a point in time; Type II proves operation over a period
- Most engineering teams already satisfy 60–70% of the control set
- Automating evidence collection is the difference between painful and routine
- Choose your Trust Services Criteria deliberately — do not take all five by default
SOC 2 has a reputation for being an ordeal. For companies with reasonable engineering practice it usually is not — but the effort lands somewhere different from where people expect.
Type I versus Type II
Type I is a point-in-time assessment: on this date, were the controls designed appropriately? Type II covers a period — commonly three to twelve months — and asks whether they operated effectively throughout. Type II is what enterprise customers actually want. Type I is a reasonable stepping stone that lets you answer "we are in progress" credibly.
Choose your criteria
Security is mandatory. Availability, Confidentiality, Processing Integrity and Privacy are optional, and each adds scope. Take only what your customers are actually asking for. Organisations that take all five by default create months of work nobody requested.
A realistic timeline
Weeks 1–3: gap assessment. Map the applicable criteria to what you already do. This is where most of the relief happens — teams that deploy through a reviewed pipeline, enforce MFA, encrypt at rest and log access typically already satisfy 60–70% of the control set without having called it compliance.
Weeks 3–8: close the gaps. The recurring ones are formal access reviews, documented change management, a vendor risk process, an incident response plan that has actually been exercised, and security awareness training. Wherever a control can be enforced by the platform — policy-as-code, pipeline gates, SSO enforcement — implement it that way, because a control the system enforces cannot quietly lapse and produces its own evidence.
Weeks 6–10: policies. You need a documented policy set. Write policies that describe what you actually do; auditors test against your own documents, so an aspirational policy is a finding waiting to happen.
Weeks 8–12: evidence automation. This is the part that determines whether the next audit is routine or repeats the whole exercise. Access reviews, change approvals, vulnerability scans, backup restore tests — scheduled, executed and archived automatically.
Weeks 12–14: readiness assessment and auditor selection. A dry run against the control set, then engage the auditor.
Then the observation period. For Type II, three to twelve months during which controls must operate continuously and produce evidence. Three months is the usual starting point; twelve is more persuasive to enterprise buyers.
Where the real cost sits
Not in the controls. In evidence. An organisation collecting evidence manually spends days per quarter assembling screenshots and will do it again before every audit, forever. An organisation collecting it automatically exports a folder. That difference compounds across every year you remain certified.
SOC 2 and ISO 27001 together
The control sets overlap substantially. If you expect to need both — common for companies selling into both the US and Europe — plan them together from the start. Doing SOC 2 first and ISO 27001 eighteen months later means repeating much of the same work with different documentation.
