# SOC 2 Readiness in 90 Days: What Engineering Builds

Canonical: https://kaansystems.com/library/90-day-soc2-readiness-sprint
Topic: Compliance · Published: 2026-07-09 · Updated: 2026-10-12
Summary: Choosing SOC 2 is the easy part. The stall is having no plan. This is the quarter of engineering work: scope, policy, controls, and an evidence pipeline, in that order.

## Key takeaways

- SOC 2 readiness is roughly 90 focused days of building — scope, policy, controls, evidence, in that order — not the year-long project vendors imply; the multi-month observation window that follows is mostly waiting and collecting.
- Scope first, because scope determines everything downstream. Implementing controls before scoping means redoing work when the scope turns out smaller than feared.
- Only the Security criterion is mandatory. Add Availability if you make uptime commitments and Confidentiality if you handle sensitive data; skip Processing Integrity and Privacy unless a specific buyer asks.
- Write policies that describe what your team actually does. An aspirational policy like 'access is reviewed quarterly' when you've never run a review is a finding waiting to happen.
- Implement the control first, then let a compliance platform watch it — the tool automates evidence collection, it does not implement the control.
- Budget a dedicated owner. Ninety days with a designated owner stays ninety days. Squeezed into everyone's spare time, the same work becomes the year-long stall.

**How do you get SOC 2 ready in 90 days?** Run four sequenced phases: scope and gap-assess (weeks 1-2), write policies and stand up processes (weeks 3-5), implement the technical controls (weeks 6-9), then build the evidence pipeline and start your Type II observation window (weeks 10-12). Do them in order, with a dedicated owner.

## Why does SOC 2 readiness stall before it starts?

Once you've decided SOC 2 is the framework you need — see [choosing between SOC 2, HITRUST, and HIPAA](/library/choosing-soc2-hitrust-hipaa) if you haven't — the next question is deceptively hard: what's the actual plan?

[SOC 2](/library/soc2-for-startups-complete-guide) 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.

## What does engineering actually build, week by week?

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.

```mermaid
flowchart LR
  P1["<b>Weeks 1-2</b><br/>Scope + gap<br/><br/>Define the system<br/>Pick trust criteria<br/>Honest gap assessment"]
  P2["<b>Weeks 3-5</b><br/>Policy + process<br/><br/>Write the policies<br/>Stand up the processes<br/>Assign the owners"]
  P3["<b>Weeks 6-9</b><br/>Implement controls<br/><br/>Close the technical gaps<br/>Access reviews, logging<br/>Change management"]
  P4["<b>Weeks 10-12</b><br/>Evidence + kickoff<br/><br/>Evidence pipeline live<br/>Readiness assessment<br/>Start the window"]
  DONE(["Type II observation<br/>window begins"])

  P1 --> P2 --> P3 --> P4 --> DONE

  classDef phase fill:#0d1f1a,stroke:#3FA585,stroke-width:1.5px,color:#E8F5EE
  classDef done  fill:#1F4A3E,stroke:#3FA585,stroke-width:2.5px,color:#E8F5EE
  class P1,P2,P3,P4 phase
  class DONE done
```

### 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 the engineering 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](/library/evidence-pipelines-101) 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 build 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. Ninety days with a designated owner stays ninety days. The same work 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.

## Frequently asked questions

**Q: How long does it take to get SOC 2 ready?**

About 90 focused days to reach readiness — the point where a Type II observation window can start. The window itself then runs three to twelve months, but that part is mostly operating and collecting evidence, not building.

**Q: What are the phases of 90 days of SOC 2 engineering?**

Four, in order: scope and gap assessment (weeks 1-2), policy and process (weeks 3-5), implement controls (weeks 6-9), and evidence plus kickoff (weeks 10-12). Each phase unblocks the next, so don't start one until the prior phase's blocking items are closed.

**Q: Which Trust Services Criteria should I scope for SOC 2?**

Security is mandatory. Add Availability if you make uptime commitments and Confidentiality if you handle sensitive customer data beyond the obvious. Skip Processing Integrity and Privacy unless a specific buyer is asking, because each criterion you add is real additional work.

**Q: Do I need a compliance platform to get SOC 2?**

A platform automates evidence collection but doesn't implement the controls. The teams that finish the controls phase on time are the ones that resisted buying a platform first — implement the control, then let the tool watch it.

**Q: What happens after the 90 days of engineering?**

The Type II observation window begins, and from there it's operate-and-collect, not build. The most common way teams fail their first Type II is treating the window as done and letting controls lapse — the access reviews and evidence pipeline have to keep running on cadence.

**Q: Why do SOC 2 projects stall for a year?**

Because the project has no shape and no owner. Squeezed into the margins of everyone's real job, the 90 days of work becomes the year-long stall; a designated compliance owner is what keeps it to 90 days.

Template: "Week-by-week SOC 2 readiness plan" — branded PDF at https://kaansystems.com/templates/90-day-soc2-readiness-sprint.pdf

Source: https://kaansystems.com/library/90-day-soc2-readiness-sprint · Work with Kaan Systems: https://kaansystems.com/contact