SOC 2 Readiness Timeline: 6-Month Preparation Plan

I met Dana Okonkwo on a Tuesday afternoon call that she'd scheduled with the subject line "URGENT — need SOC 2 by Q3." Dana was Head of Security & IT at Parcel Metrics, a 65-person supply-chain analytics startup, and three weeks earlier her VP of Sales had come back from a customer visit with good news and bad news in the same sentence: a national retailer wanted to sign a $2.4M annual contract, but procurement wouldn't release the purchase order without a SOC 2 report on file. Dana had never scoped an audit in her life. She had a login to a project management tool, a half-finished password policy from 2022, and six months until the retailer's budget window closed.

I've spent more than fifteen years consulting on security and compliance programs — SOC 2, ISO 27001, PCI DSS, HIPAA — across more than 200 organizations, from three-person startups to public companies with distributed engineering teams. Dana's situation is close to the median case I see: a company that needs a report by a hard deadline, has some security hygiene in place but nothing documented or tested, and has heard "six months" thrown around without anyone explaining what actually happens inside those six months. This article is the plan I would have handed Dana on that first call — the month-by-month sequence, the owners, the deliverables, and the places where six months quietly becomes nine.

Who This Is For / What You'll Walk Away With

This is for founders, engineering leaders, and first security hires who have been told "we need SOC 2" and are staring at a blank calendar. You'll get a realistic six-month, month-by-month plan with named milestones, owners, and deliverables; the difference between what six months buys you for a Type I report versus a Type II report; a RACI breakdown of who does what; a monthly budget shape; and the specific things — in my experience across dozens of these engagements — that make timelines slip by six, ten, or sixteen weeks. What you won't get is a promise that six months works for every company; I'll show you exactly when it doesn't and what to do instead.

Why "Six Months" Is a Starting Point, Not a Promise

Six months is a workable, commonly cited target for a company that starts with reasonable technical hygiene — centralized identity, some form of change control, a cloud environment rather than a colocated data center — and commits real people-hours to the project every week. It is not a universal constant. I've run readiness programs that closed in ten weeks and others that took fourteen months, and the variable was almost never the framework itself; it was organizational readiness: how mature the environment already was, how much of the work was delegated to one overworked person versus a real cross-functional team, and how quickly leadership made scope decisions instead of relitigating them every month.

The table below reflects the ranges I actually see, illustratively, across company profiles. Treat "six months" as the number for a reasonably typical, moderately mature SaaS company with dedicated ownership — not as a guarantee.

Table: Illustrative Readiness Timelines by Company Profile

"The question I ask every prospective client isn't 'can you get SOC 2 in six months.' It's 'do you have someone whose job it is to make decisions every single week, or is this the fourth priority on someone's list?' That answer predicts the timeline better than company size does." — Sanjay Bhatt, Audit Partner, Bhatt & Cole CPAs

The Readiness Journey at a Glance

Before the month-by-month detail, here is the shape of the six months as a single picture. Each month builds on the one before it — you cannot skip gap analysis and go straight to evidence collection, and you cannot collect meaningful evidence before controls have actually been operating for a period of time.

Table: The Six-Month Plan at a Glance

Before Month 1: Getting Executive Buy-In and a Budget

The clock I'm describing starts the day real work begins, not the day someone says "we should probably look into SOC 2." Before Month 1 can start, three things need to happen, usually in a single week: an executive sponsor needs to be named (ideally the CEO, CTO, or COO — someone who can unblock cross-team requests), a rough budget needs to be approved covering tooling, an auditor, and possibly outside advisory help, and the company needs to decide whether this is a Type I report first or a straight run at Type II. Skipping this step is the single most common reason I see six-month plans become nine-month plans — not because the technical work was hard, but because in Month 3 someone in Engineering asks "wait, who approved this project?" and momentum stalls for two weeks while that gets sorted out retroactively.

For Dana, this meant a 30-minute meeting with Parcel Metrics' CEO where she left with three things: a named executive sponsor (the CTO), a $45,000 budget line for the first year (tooling, auditor fees, and a part-time compliance consultant), and agreement that Parcel Metrics would target a Type I report at the six-month mark rather than promising the retailer a full Type II report, which — because Type II requires an observation window of operating effectiveness after the controls are in place, commonly three to twelve months — simply was not achievable in six months no matter how hard anyone worked. That distinction, made in week zero, is what kept the plan honest for the rest of the engagement. If you want the deeper case for treating this as a first-time program end to end, our complete first-time SOC 2 implementation guide walks through the full lifecycle beyond just the six-month window.

Month 1: Scope, Trust Services Criteria, and Gap Analysis

Month 1 answers two questions: what exactly is being examined, and how far away from ready is it. This is not a month for building anything — it's a month for decisions and honest measurement. The scope decision (which systems, which products, which locations, which subservice organizations) drives every downstream decision, so rushing it to "feel productive" is one of the most expensive mistakes I see. Our dedicated piece on defining what's in and out of scope goes deeper on the mechanics of this decision if your environment includes multiple products or business units.

Every SOC 2 report includes the Security criteria — the Common Criteria, aligned to the COSO framework's internal-control principles — because Security is mandatory in every SOC 2 examination. Availability, Processing Integrity, Confidentiality, and Privacy are added based on what your organization actually commits to its customers, not based on which ones sound impressive. Adding criteria you don't need adds real audit scope, evidence burden, and cost without adding sales value.

Once scope and TSCs are set, the gap analysis measures current-state controls against the criteria. This should be brutally honest — a consultant, internal auditor, or experienced hire walking through each criterion and marking it "exists and documented," "exists but undocumented," or "doesn't exist." I have never seen a first-time gap analysis come back clean, and a company that reports zero gaps in Month 1 usually just hasn't looked hard enough.

Table: Month 1 Milestones, Owners, and Deliverables

Table: Trust Services Criteria Selection Matrix

"Every prospect asks Dana's company the same question procurement always asks: what does your report actually cover? Companies that add every criterion 'to look thorough' usually regret it — more scope means more evidence, more cost, and a longer audit, for criteria nobody asked about." — Lena Forsythe, Director of GRC, Northfield Payments

Month 2: Policies, Governance, and the First Wave of Remediation

Month 2 turns the gap analysis into paper and into action. Policies are not busywork — auditors test whether your organization does what its policies say, so a policy that doesn't match reality is worse than no policy at all. This is also the month remediation actually starts on the highest-severity gaps identified in Month 1, because some fixes (rolling out multi-factor authentication organization-wide, for instance) take weeks to fully propagate and need runway before evidence collection begins in Month 4.

Our dedicated article on building the required policy documentation covers policy content in depth; here the point is sequencing — get policies drafted and formally approved by leadership early enough that the practice described in them has time to become routine before an auditor ever samples it.

Table: Month 2 Milestones, Owners, and Deliverables

Table: Core Policy Set Mapped to the Common Criteria

"The policies aren't the hard part — writing eight documents in two weeks is achievable for any team. The hard part is that a policy written in Month 2 has to be true by Month 4, when evidence collection starts. That's why remediation can't wait until Month 3." — Dana Okonkwo, Head of Security & IT, Parcel Metrics

Month 3: Building and Configuring Controls

Month 3 is where technical remediation converts into operating controls. If Month 1 found that the company lacked centralized identity and access management, enforced least privilege, or had no vulnerability scanning program, Month 3 is when those tools get selected, procured, and configured — not perfectly, but functionally enough that they can start generating real operating history in Month 4.

This is also typically the most expensive month in the six-month plan, because tooling procurement and configuration work concentrates here. A GRC platform, if the company chooses to use one, is usually stood up in Month 3 as well, since it becomes the evidence repository for everything that follows.

Table: Month 3 Milestones, Owners, and Deliverables

Table: Tooling Categories Typically Stood Up in Month 3

"Buying the GRC platform in Month 1 out of anxiety is a mistake I still see constantly. It just sits there empty because there's no evidence to feed it yet. Month 3, once controls exist to generate evidence, is when that tool earns its subscription fee." — Marco Delgado, CTO, Brightloop Analytics

Month 4: Operating the Controls and Collecting Evidence

Month 4 is the pivot from "building" to "operating and proving." Controls that were configured in Month 3 now need to run in production, generating the artifacts — access review logs, change approval records, vulnerability scan reports, training completion records — that an auditor will eventually sample. This is also, not coincidentally, roughly when the observation window for a future Type II report would need to start if the company intends to pursue one on a normal timeline, since Type II requires controls to have operated for a period before an auditor can test their effectiveness.

The discipline required in Month 4 is consistency, not heroics. A control that ran perfectly once, the week before the auditor showed up, is not what "operating effectiveness" means. A monthly access review that happened in April and then got skipped in May is a finding waiting to happen. Our detailed guide on what documentation and testing evidence collection actually requires is worth reading closely before this month starts, since retrofitting evidence after the fact is far more painful than capturing it as controls run.

Table: Month 4 Milestones, Owners, and Deliverables

Table: Evidence Types by Control Area

Month 5: Internal Self-Assessment and the Mock Audit

Month 5 exists so the real auditor is never the first person to find your gaps. This month is a structured internal audit — sometimes run by the same person who did the Month 1 gap analysis, sometimes by an independent internal function or outside firm — that walks through every control as if it were the actual examination: pulling samples, asking control owners to demonstrate the evidence, and checking whether the story matches the paper trail. Our piece on running a self-assessment and internal audit program covers how to structure this function on an ongoing basis, but for a first-time six-month plan, even a lightweight version of it here changes outcomes dramatically.

In my experience, the mock audit reliably finds three to eight issues even in well-run programs — inconsistent evidence retention, a policy that says quarterly but practice that happened twice, an offboarding step that got missed for one departing contractor. None of these are catastrophic if caught in Month 5. Caught by the actual auditor in Month 6, the same issues become findings in the report.

Table: Month 5 Milestones, Owners, and Deliverables

Table: Common Mock-Audit Findings and Fixes

"The mock audit is the cheapest insurance policy in the whole six months. An hour of an internal reviewer's time in Month 5 can prevent a finding that costs weeks of back-and-forth with the actual auditor in Month 6." — Priya Ramaswami, Head of Internal Audit, Vantage Health

Month 6: Choosing and Engaging Your Auditor

Month 6 is when the internal work meets an external, independent party. SOC 2 examinations are performed exclusively by licensed CPA firms — this is an attestation, governed by SSAE 18 under AICPA standards, not a certification body audit, and choosing the right firm matters as much as the readiness work itself. Our dedicated guide on choosing the right CPA firm covers selection criteria in depth; the short version is that price is a poor primary filter — industry familiarity, communication style, and realistic scheduling matter more.

Ideally, auditor selection actually starts in parallel back in Month 3 or 4, not Month 6 — many firms book out eight to twelve weeks in advance, and waiting until Month 6 to start the conversation is one of the most common causes of an otherwise on-track plan slipping by four to six weeks. The kickoff meeting formally opens the examination: scope confirmation, the PBC list (the evidence and documentation the auditor will request), timeline agreement, and introductions between the audit team and control owners.

Table: Month 6 Milestones, Owners, and Deliverables

Table: What "Ready" Looks Like Going Into Auditor Fieldwork

Type I Now or Type II Later? What the Six-Month Mark Really Means

This is the distinction that trips up more companies than any other part of the plan, and it's the one I made sure Dana understood in week zero: six months of disciplined work gets you to the point where controls are designed appropriately and you can demonstrate that design to an auditor. That's a Type I report — suitability of design at a point in time. A Type II report requires demonstrating that controls operated effectively over a period, commonly three to twelve months, and that period cannot be compressed by working harder; it can only be shortened by starting the clock earlier. Our detailed comparison of choosing between Type I and Type II is worth reading in full before you commit to either path with a customer.

Practically, this means a six-month plan produces one of two outcomes: a completed Type I report in hand at month six, or — if the company skips Type I and commits straight to Type II — a confirmed start of the observation period at month six, with the actual Type II report landing three to twelve months later depending on the negotiated period length. Our piece on the observation period and review timeframe explains how that window is typically negotiated with the auditor.

Table: Two Paths Out of Month 6

For Parcel Metrics, this meant Dana's retailer prospect received a signed Type I report at the six-month mark along with a written commitment and observation-period start date for a Type II report six months after that. It wasn't the full Type II the retailer originally asked for, but it was enough — combined with the observation-period commitment — to get procurement to release the purchase order.

RACI: Who Owns What Across Six Months

A six-month SOC 2 plan fails almost as often from unclear ownership as from technical gaps. The table below is the RACI structure I use as a starting template — Responsible, Accountable, Consulted, Informed — adjusted to each company's org chart, but the shape holds across most first-time programs.

Table: RACI Across the Six-Month Plan

Budgeting the Six Months

Budget conversations derail more plans than technical difficulty does, largely because companies budget for the audit fee and forget everything that comes before it. Our dedicated guide on budgeting for compliance and audits breaks this down in full detail; here is the shape specific to a six-month first-time program, illustratively.

Table: Illustrative Budget Shape Across Six Months

"The number that surprises founders isn't the audit fee — it's the tooling spend in Month 3. That's where the real money goes for a first-time program, and it's recurring, not one-time." — Tom Reyes, Founder, Coastal DevOps

Case Study: The Enterprise Deal Deadline

Parcel Metrics' six-month plan, described throughout this article, closed almost exactly as scoped. Dana's team defined scope to include only the core analytics platform and its supporting AWS infrastructure — deliberately excluding two side products that weren't part of the retailer deal, which kept audit scope (and cost) contained. The gap analysis in Month 1 surfaced eleven findings, four of them high-severity, including no centralized MFA enforcement and no documented incident response plan. By Month 3, MFA was enforced across all critical systems and a GRC platform was tracking evidence against all in-scope criteria. The Month 5 mock audit found six smaller issues — mostly inconsistent evidence retention — all closed within nine days. Parcel Metrics received a signed Type I report in week 24, exactly on the original timeline, and the retailer's procurement team released the purchase order eleven days later. The Type II observation period began the same week the Type I report was issued; the resulting Type II report was issued roughly seven months after that, once the negotiated six-month observation window closed and fieldwork concluded. Total elapsed time from Dana's first call to a completed Type II report: just over thirteen months — with a usable Type I report in hand at month six that unlocked the deal well before that.

Case Study: The Scale-Up With Messy IT

Brightloop Analytics, a 140-person fintech led by CTO Marco Delgado, is a useful contrast because it shows how prior maturity — not company size — compresses a timeline. Brightloop had let a previous SOC 2 program lapse eighteen months earlier after an acquisition shuffled priorities; policies existed but were stale, and tooling was partially configured but unmonitored. Because the documentation skeleton and institutional knowledge already existed, Brightloop's "Month 1" gap analysis took nine days instead of four weeks, and the company reached auditor engagement in seventeen weeks rather than twenty-four. The lesson Marco took from it, and one I repeat to every client who asks whether they can go faster than six months: the fastest timelines belong to companies redoing the work, not companies doing it cleanly the first time. First-time programs should plan for the full six months and treat anything faster as a pleasant surprise, not a target.

What Compresses or Stretches the Timeline

Table: Timeline Accelerators and Decelerators

Common Ways Six-Month Plans Slip

Table: Where Timelines Actually Break Down

Tooling Stack for a Six-Month Sprint

Table: Illustrative Tooling Investment by Priority

Keeping Momentum After Month 6

Reaching Month 6 is not the finish line — it's the point where "readiness" becomes "operations." Whether the company received a Type I report or is now inside a Type II observation window, the controls built over the previous five months need to keep running, and the evidence needs to keep accumulating, without the same intensity of oversight that got the program here. This is where continuous monitoring becomes the operating model rather than a project — automated evidence collection, periodic internal reviews, and a standing cadence for policy review replace the sprint mentality of the six-month build. Companies that treat Month 6 as "done" instead of "operationalized" are the ones who show up eleven months later scrambling to reconstruct evidence for their Type II report the same way Dana scrambled in Month 1.

SOC 2 Readiness as a Growth Lever, Not Just a Deadline

It's easy to treat a six-month SOC 2 plan as a compliance chore — a box procurement is forcing you to check before releasing budget. I'd push back on that framing. Every control built during these six months — centralized identity, tested incident response, documented change management — is infrastructure the company needed anyway, deadline or not. The companies I've watched get the most value from this process are the ones that stop asking "what's the minimum to pass" and start asking "what would make our security program genuinely defensible," because that second question produces a program that survives past the first report, supports the next enterprise deal without another fire drill, and gives the executive team an honest picture of organizational risk. Dana's team didn't just unlock a $2.4M contract — they walked away from the six months with an access review process, an incident response plan, and a vendor risk program that didn't exist before, all of which made the next enterprise conversation shorter, not longer.

Where to Go From Here

If you're standing where Dana stood — a deadline, a blank calendar, and a vague sense that "SOC 2" means a lot of work — start with an honest readiness assessment before committing to a public timeline with a customer or investor. PentesterWorld's SOC 2 Readiness Checklist gives you a structured way to run that first gap analysis, and the SOC 2 Cost Calculator can turn the budget table above into numbers specific to your environment. If you want an outside, experienced set of eyes on your scope decisions, gap analysis, or mock audit before you engage a CPA firm, that's exactly the kind of engagement our team runs regularly — reach out and we'll help you build a plan as specific as the one Dana got, tailored to your actual environment instead of a generic six-month template.