SOC 2 in 12 weeks: a realistic timeline for startups.

The first question I ask when a founder says "we need SOC 2" is: which one, and by when? Nine times out of ten the answer is "the one the customer asked for, before the contract renews." That's a Type I, and the deadline is usually closer than anyone wants.

Twelve weeks is enough. Not because SOC 2 is easy, but because most of the time in a typical SOC 2 program isn't spent on controls. It's spent on nobody owning it, on scope arguments, on picking a platform for six weeks, and on policies that get written twice. Remove those and the calendar shrinks.

First, what "SOC 2 in 12 weeks" actually means

SOC 2 comes in two flavours. Type I is a point-in-time opinion: on this date, your controls were designed appropriately and in place. Type II covers an observation window, typically three to twelve months, and tests that the controls operated throughout.

Twelve weeks gets you one of two things: a Type I report in hand, or the day your Type II observation window opens with everything operating. You cannot compress the Type II window by working harder. The calendar is the calendar. What you can do is start it twelve weeks from today instead of nine months from today, and hand the customer a Type I in the meantime. Most enterprise procurement teams accept exactly that: a Type I now, a Type II by a committed date.

The three preconditions

The twelve-week programs I have seen finish on time had all three. The ones that slipped were missing at least one.

1. One accountable owner with authority. Not a committee, not "engineering", not the person who happened to open the auditor's email. Someone who can say "we're enforcing MFA on Friday" and have it happen. A fractional CISO can be that person; so can a CTO who has actually cleared their calendar.
2. Compliance tooling connected in the first two weeks. Vanta, Drata, Secureframe, pick one and move on. The choice matters far less than the connection date. Every week the platform isn't wired to your cloud, identity provider, source control and HR system is a week of evidence you'll collect by hand later.
3. Leadership that makes decisions in days, not quarters. Scope, auditor, policy approvals, budget for a background-check vendor. If each of those waits for the next leadership meeting, you've added a month before anyone touches a control.

Weeks 1–2: scope and gap

Pick your criteria. SOC 2 has five Trust Services Criteria: Security, Availability, Confidentiality, Processing Integrity and Privacy. Security is mandatory. For a first audit, take Security alone, or Security plus Availability if customers ask about uptime. Adding Confidentiality and Privacy on a first pass is the single most common self-inflicted delay I see. You can add criteria next year.

Draw the system boundary. Which products, which environments, which people. Production only. The marketing site and the internal wiki are out unless they touch customer data. Write it down in one page; the auditor will ask for it on day one.

Connect the platform and run the gap. Cloud accounts, identity provider, GitHub or GitLab, HRIS, MDM if you have one. Within 48 hours you'll have a list of failing tests. That list, not a template, is your project plan.

Pick the auditor now. Good firms book six to ten weeks out. If you wait until week 10 to shop for one, you'll finish readiness and then sit idle for two months. Get two quotes, check they've audited companies your size and stack, and hold a fieldwork date in week 12.

Weeks 3–5: policies and owners

You'll need roughly a dozen policies: information security, access control, change management, incident response, vendor management, data classification and retention, business continuity, acceptable use, risk management, and a few others depending on criteria. Every platform ships templates. Do not publish the templates. Rewrite them in your company's voice and, more importantly, to match what you actually do. An auditor testing a policy that says "quarterly access reviews" when you've never done one is a finding you handed them yourself.

Every control gets a named owner. Not a team, a person. The owner is who the auditor interviews and who fixes the failing test. Put the names in the platform.

Complete the risk assessment. A real one, with your top fifteen or so risks, likelihood, impact, and the control that addresses each. Review it with founders. This document does double duty later when investors and enterprise customers ask about risk management.

Start the vendor inventory. Every SaaS tool that touches customer data, its SOC 2 report or equivalent, and a DPA. You will be surprised how many tools nobody remembers signing up for.

Weeks 6–9: controls actually operating

This is the block that separates a real program from a paper one. The auditor doesn't test your policy; they test whether the thing the policy describes happened.

• Identity: SSO and MFA enforced for every human on every in-scope system. Service accounts inventoried. Offboarding tested end to end: someone leaves on a Tuesday, prove their access was gone by Wednesday.
• Access reviews: perform the first one now, with sign-off, so there's evidence before the auditor arrives.
• Change management: protected main branch, required reviews, CI checks, and a way to show a production change traces back to an approved pull request. If your engineers already do this, the control is free.
• Logging and monitoring: centralised logs for production, alerts for the things that matter, and someone who receives them.
• Vulnerability management: scanning in the pipeline, a severity SLA, and a record of findings being closed inside it.
• People: background checks for new hires, security awareness training completed with a record, signed acceptable-use acknowledgements.
• Incident response: a plan people have read and one tabletop exercise, with notes. Thirty minutes in a room counts.
• Vendors: reviews completed for every critical vendor; the inventory from week 4 now has evidence attached.

Work the failing-tests list top down by risk. By the end of week 9 you should be at or near zero failing tests, and the ones that remain should have a documented reason and a date.

Weeks 10–12: readiness review and the audit

Week 10: internal readiness review. Someone who wasn't building the program walks every control as the auditor will: read the policy, look at the evidence, interview the owner. Fix what's thin. This is where a fractional CISO earns their fee if you didn't have one earlier; a fresh, experienced set of eyes finds the gaps you've been staring past.

Week 11: evidence walk-through with the auditor. Most firms will do a short pre-fieldwork session. Use it. Confirm the boundary, the criteria and the report date. Agree how evidence will be shared; platform access for the auditor saves days.

Week 12: Type I fieldwork. Interviews with control owners, evidence sampling, and the point-in-time opinion. Your Type II observation window opens the same day. Set the calendar reminder for the end of it now.

One byproduct nobody plans for: by week 12 you have answers to roughly 80% of any security questionnaire a customer will ever send you. Save them somewhere structured. The next 300-row SIG takes hours, not weeks.

What it costs

Budget three lines, and be honest about the third.

• Platform. Compliance automation is a recurring five-figure annual line for most startups. Negotiate; the market is competitive.
• Auditor. A Type I from a reputable firm is typically a five-figure engagement, with Type II higher. Cheap audits exist and enterprise buyers know which firms produce them.
• People time. This is the line everyone underestimates. Expect meaningful weekly time from an engineering lead for twelve weeks, plus a few hours a week from whoever owns HR and vendors, plus the accountable owner. If that owner is your CTO, that's roadmap you're not shipping. If it's a fractional CISO, that's the fee. Either way it's real money; the question is which is cheaper for you.

Where the twelve weeks slips

• No owner. The program becomes everyone's third priority. Add three months.
• All five criteria on the first audit. Privacy alone can add a quarter of policy and process work. Add two months.
• Auditor chosen in week 10. Readiness finishes, then nothing happens. Add two months.
• Engineering treats it as paperwork. Controls get "documented" instead of implemented; the auditor finds out. Add a remediation cycle and a difficult conversation.
• Template policies nobody read. The policy says one thing, the company does another. Findings, rewrites, another review cycle.

None of these are technical problems. All of them are ownership problems. That's the whole point of the twelve-week plan: it works because someone is accountable for the calendar.

The bottom line

Twelve weeks to a Type I is not aggressive. It's what happens when one accountable person runs the program, the tooling is connected on day one, and leadership makes decisions at the speed of the deadline. The Type II window still takes as long as it takes. But you'll be inside it, with a report in hand, while the six-month version of your company is still arguing about scope.

The audit is not the hard part. Owning the calendar is.