The 90-Day SOC 2 Readiness Sprint

Choosing SOC 2 is the easy part. The next question — what's the actual plan to get there — is where teams stall for a year. Here is the 90-day version: scope, policy, controls, evidence, in that order.

Template included

Week-by-week SOC 2 readiness plan

Copy as markdown to paste into your repo, or download a branded PDF for sharing with non-technical stakeholders.

Download PDF

The Problem

Once you’ve decided SOC 2 is the framework you need — see choosing between SOC 2, HITRUST, and HIPAA if you haven’t — the next question is deceptively hard: what’s the actual plan?

SOC 2 feels enormous and vague. There’s no single checklist, the criteria are written for auditors, and every vendor selling you a tool has an incentive to make it sound like a year-long transformation. So teams do the thing that guarantees failure: they don’t start. The project sits on the roadmap for three quarters while deals get lost on “you don’t have SOC 2.”

The work isn’t a year. The work is roughly 90 focused days to get ready — to the point where a Type II observation window can start. The observation window itself then runs its course (three to twelve months of the controls operating), but that part is mostly waiting and collecting, not building. The 90 days is the build.

The Approach

Four phases, sequenced so each one unblocks the next. Do them in order. The most common way this goes wrong is teams implementing controls before they’ve scoped, then re-doing work when the scope turns out to be smaller than they feared.

Weeks 1-2

Scope + gap



Define the system

Pick trust criteria

Honest gap assessment

Weeks 3-5

Policy + process



Write the policies

Stand up the processes

Assign the owners

Weeks 6-9

Implement controls



Close the technical gaps

Access reviews, logging

Change management

Weeks 10-12

Evidence + kickoff



Evidence pipeline live

Readiness assessment

Start the window

Type II observation

window begins

Weeks 1-2: Scope and gap assessment

Scope first, because scope determines everything downstream. SOC 2 covers “the system” — you decide what that system is. Narrow it honestly to the production environment and the people and processes that touch customer data. A tighter scope is fewer controls, fewer policies, and less evidence, without weakening the report for the buyers who’ll read it.

Pick your Trust Services Criteria. Security is mandatory. Add Availability if you make uptime commitments, Confidentiality if you handle sensitive customer data beyond the obvious. Skip Processing Integrity and Privacy unless a specific buyer is asking — each one you add is real additional work.

Then run an honest gap assessment against the criteria. Not “what do we wish we had” — what actually exists today, in writing, with evidence. Most teams discover the gaps cluster: the controls exist informally but aren’t documented, or the logging is on but nobody reviews it. Name every gap. That list is your sprint backlog.

Weeks 3-5: Policy and process

Auditors assess your controls against your documented policies. No policy, no control, regardless of what you actually do. This phase writes the documents and stands up the processes they describe.

The core policy set is smaller than it looks: information security, access control, change management, incident response, vendor management, risk assessment, business continuity, and a few supporting ones. Don’t write them from scratch and don’t copy a template you won’t follow — write the version that describes what your team will actually do, then do that.

The trap here is writing aspirational policies. A policy that says “access is reviewed quarterly” when you’ve never done a review is a finding waiting to happen. Write what’s true, or make it true this week.

Weeks 6-9: Implement controls

Now close the technical gaps from Week 1. This is the longest phase because it’s the real work. The controls that show up in almost every SOC 2:

  • MFA and SSO across every system that touches customer data
  • Quarterly access reviews, with the review actually performed and recorded
  • Centralized logging with retention, and alerting that routes to a human
  • Change management: every production change tied to a reviewed PR or ticket
  • Encryption at rest and in transit, verified not assumed
  • Vendor management: the sub-processor list and annual reviews
  • Onboarding/offboarding with a documented, followed checklist

The teams that finish this phase on time are the ones that resisted buying a compliance platform first. The tool automates evidence collection; it does not implement the control. Implement the control, then let the tool watch it.

Weeks 10-12: Evidence and kickoff

The observation window measures whether your controls operated over time, so you need the evidence to generate itself continuously. Stand up the evidence pipeline now, before the window starts, so month one of the window is already producing clean artifacts.

Run a readiness assessment — internal, or with your eventual auditor’s readiness service. It surfaces the gaps you’ll otherwise discover three months into the window, when they’re expensive to fix. Close them.

Then start the window. From here it’s operate-and-collect, not build. The sprint is done.

The Template

The week-by-week checklist. Each item has a clear done state. Run it in order; don’t start a phase until the prior one’s blocking items are closed.

Weeks 1-2: Scope + gap assessment

  • System boundary defined in writing (what’s in scope, what’s explicitly out)
  • Trust Services Criteria selected (Security + only what buyers require)
  • Gap assessment complete: every gap named, owner assigned
  • Report type decided (Type I as a stepping stone, or straight to Type II)

Weeks 3-5: Policy + process

  • Core policy set drafted and approved (8-10 policies)
  • Each policy describes what the team will actually do (no aspirational controls)
  • Process owners assigned for every recurring control
  • Policies published where employees can find them, acknowledgement tracked

Weeks 6-9: Implement controls

  • MFA + SSO enforced across in-scope systems
  • First access review performed and recorded
  • Centralized logging + alerting live, routes to on-call
  • Change management enforced: prod changes tied to reviewed PRs
  • Encryption at rest + in transit verified across in-scope stores
  • Vendor / sub-processor list built, annual review scheduled
  • Onboarding + offboarding checklists documented and in use

Weeks 10-12: Evidence + kickoff

  • Evidence pipeline generating artifacts automatically
  • Readiness assessment complete, findings closed
  • Auditor engaged, observation window start date set
  • Observation window started

Operating Notes

The window is not a break. The single most common way teams fail their first Type II is treating the observation window as “done” and letting the controls lapse. The access review you performed in Week 6 has to happen again next quarter, on time, recorded. The evidence pipeline has to keep running. Compliance is a continuous practice, and the window is where that practice gets measured.

Budget for a dedicated owner. A 90-day sprint with a designated compliance owner is 90 days. The same sprint squeezed into the margins of everyone’s real job is the year-long stall this article opened with. The work isn’t hard. It’s just work, and work needs an owner.

The second framework is cheaper than the first. Almost everything you build here — the policies, the evidence pipeline, the access review cadence — carries directly into HITRUST, ISO 27001, or a HIPAA assessment later. The 90 days buys you SOC 2 and most of the readiness for whatever comes after it.

SOC 2 on the roadmap?

The sprint is 90 days. The stall is a year.

Most teams don't fail SOC 2 on the controls. They fail on never starting, because the project has no shape. When you need the plan run alongside the team — scoped, sequenced, and evidenced — talk to us. It's the exact engagement this article describes.

Open a conversation