Most SOC 2 content online is a sales funnel in disguise. The “timeline” is six bullet points, the “project plan” is a call-to-action to book a demo, and the “guidance” is whatever flatters the vendor’s product. If you’ve been hunting for an actual phased schedule with honest durations, you’ve probably noticed by now that almost nobody publishes one.
This article is the Gantt. A realistic six-month plan for a first SOC 2 Type II audit, written for the compliance lead or security engineer who already understands what an audit is and just needs someone to tell the truth about how long each phase takes, what goes wrong, and which tooling is actually worth paying for.
What SOC 2 Type II actually is
SOC 2 is an attestation report, not a certification. An independent CPA firm — the auditor — examines your controls against the AICPA’s Trust Services Criteria and issues an opinion on whether those controls are both designed appropriately (Type I) and operated effectively over a defined period (Type II). That period is the observation window, and it’s the most commonly misunderstood part of the whole exercise.
Type II is the one customers actually ask for. Type I is a point-in-time snapshot and is sometimes useful as a stepping-stone, but enterprise buyers with any sophistication will ask for Type II and your sales cycle will tell you which one you need.
Five Trust Services Criteria categories exist: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security (also called the Common Criteria) is always in scope. The other four are optional and you choose them based on what your customers require and what your product does. Most first-audit SaaS companies ship with just Security. That’s fine.
The full 6-month timeline at a glance
Six months is a realistic end-to-end duration for a company that starts with moderate security maturity, commits proper executive attention, and doesn’t make any of the common mistakes in Section 7. If you’re starting from scratch — no policies, no access reviews, no vendor inventory, no formal change management — add one to three months to the front.
Phase 1: Readiness assessment Weeks 1–4
Phase 2: Control implementation Weeks 5–12
Phase 3: Observation period Weeks 13–22
Phase 4: Audit fieldwork Weeks 23–26The thing to notice about this shape is how much of the calendar is the observation period. You can’t compress it. The auditor needs to see controls operating over time, and “over time” means a minimum of three months for AICPA attestation but more realistically six for a first Type II. Everything else in the plan exists to get you to a clean observation period.
Phase 1: Readiness assessment (weeks 1–4)
The readiness phase is where you figure out what you’re actually auditing and how far off you are from being able to pass.
Scope definition. Which of your services, systems, and data stores fall inside the audit boundary? The instinct is to scope narrowly — just the production API, say — and this is almost always wrong. Narrow scope tends to balloon during fieldwork when the auditor finds dependencies you ignored. Slightly broader scope defined up front is cheaper than retroactive scope expansion three weeks before the report ships.
Gap assessment. Compare your current controls to the Trust Services Criteria you’ve chosen. Write down where the gaps are. Be honest. The auditor is going to find them in Phase 4 whether you find them now or not, and finding them now is the cheap option.
Auditor selection. Pick your auditor in Phase 1, not Phase 4. Good auditors book out a quarter or more in advance, especially between January and June when everyone is trying to get a report finalised for renewal season. Interview two or three. Ask what their revision cycle looks like, how they handle exceptions, and whether they’ll commit to a fieldwork start date in writing.
Trust Services Criteria selection. If you’re unsure which criteria to include beyond Security, ask your top five customers what they expect. If none of them have asked for Availability or Confidentiality, you don’t need them yet. Scope creep on the TSCs is a common way to blow the timeline without improving the commercial outcome.
On the question of whether to run this phase with a consultant or in-house: a good compliance consultant can save you 2–4 weeks of learning curve in a first audit and their fee is usually less than the engineering time you’d spend figuring it out yourselves. A bad consultant will sell you a platform subscription you don’t need and call it a deliverable. If you hire one, hire them for scoping and gap assessment specifically, not for the whole programme.
Phase 2: Control implementation (weeks 5–12)
This is where the actual work happens. Eight weeks to close the gaps identified in Phase 1 and stand up the controls you’ll then run for three to six months.
Work falls into roughly five clusters:
Access management. Joiner/mover/leaver processes, access reviews on a quarterly cadence, MFA everywhere that matters, SSO integration, privileged account separation. Automate what you can — if your access reviews require someone to pull a spreadsheet from every SaaS tool and cross-reference with the HR system, you’ve got a process that will break under audit scrutiny.
Change management. Pull request approvals, deployment pipelines with audit trails, separation of duties between people who write code and people who deploy it. This is where engineering-led organisations tend to fare well — the infrastructure already exists, it just needs formalising in policy.
Incident response. A documented process, a communication plan, a tested tabletop exercise, evidence that you actually ran the tabletop. The auditor will ask. Most first-time audits get an exception here not because the incident response is bad but because nobody wrote any of it down.
Vendor management. An inventory of every third-party service that touches customer data, an assessment of each vendor’s security posture, contracts with appropriate data processing terms, a review cadence. This is usually the messiest cluster for SaaS companies that have grown fast.
HR controls. Background checks for new hires, security awareness training on a documented cadence, acknowledgements of the acceptable use policy, secure offboarding. Engineering leaders are routinely surprised by how much HR surface area sits inside SOC 2. If your People team doesn’t know there’s an audit coming, tell them now.
The position worth taking: treat controls as code where you can. Automated access reviews, automated evidence collection in CI/CD pipelines, automated vendor risk scoring. Manual controls are fine for the audit but expensive to maintain at scale. The engineering you do in Phase 2 is the thing you’ll still be paying for in five years.
Phase 3: Observation period (weeks 13–22)
This phase looks like nothing is happening. It isn’t nothing — it’s the audit. The auditor is going to ask, at the end of the observation window, whether your controls operated effectively throughout. If you implemented an access review process in week 12 and then nobody ran one in weeks 13 through 22, you will fail.
What actually matters in the observation period:
- Evidence is generated and preserved as controls operate. A control that ran but produced no evidence didn’t run as far as the auditor is concerned. Log it, timestamp it, store it somewhere central.
- The cadence you specified in policy is the cadence you actually follow. Said quarterly access reviews in the policy? Do quarterly access reviews. Said monthly vulnerability scans? Do monthly vulnerability scans. Exceptions here are the single most common source of audit findings.
- New exceptions get documented as exceptions. Not papered over. If a control failed in week 16, your response to that failure is evidence — evidence of a working incident response process, a working change management process, or both. Hiding exceptions is far worse than having them.
On duration: the AICPA attestation standard permits an observation period as short as three months. Auditors will accept three. Customers increasingly won’t. If your commercial requirement is a SOC 2 Type II report that a Series C or enterprise buyer treats as credible, six months is the practical floor. Three-month reports are often read as “didn’t plan ahead” rather than “efficient,” and that perception — fair or not — costs deals.
For a first audit, I’d recommend six months of observation every time. For annual renewals, twelve months is the norm and is what your existing customers will compare against next year’s report anyway.
Phase 4: Audit fieldwork (weeks 23–26)
Four weeks of audit fieldwork is realistic for a first audit of a mid-sized SaaS company. The auditor will request evidence against each control, sample-test populations of tickets, access reviews, and deployments, interview personnel about process, and work through any exceptions they identify.
Fieldwork goes faster when the evidence is already organised. It goes slower when someone has to go hunt each artefact down as it’s requested, which is what happens when evidence collection has been left to the last week of the observation period (see Section 7). A well-prepared team makes this phase boring. That’s the target.
After fieldwork, the auditor drafts the report, you review it, they finalise it. Total elapsed time from the start of fieldwork to a signed report is usually four to six weeks. Build that into your customer-facing timeline — if your sales team is promising the report by a specific date, back up from that date with at least eight weeks of buffer.
What actually delays SOC 2 projects
Every SOC 2 project I’ve seen run late has lost time to some combination of the following. None of them are the technical controls. All of them are management.
Scope wobble. The team scoped narrowly in Phase 1, the auditor found scope dependencies in Phase 4, and now there are controls to implement and evidence to collect that nobody planned for. Mitigation: scope slightly broader than feels comfortable in Phase 1, and get the auditor to sign off on the scope boundary before control implementation begins.
Evidence collection left to the last fortnight. Teams run controls for the whole observation period, produce evidence each time, and then don’t store any of it centrally. In week 22 someone starts pulling it all together and discovers that 40% of it is either missing or in an inconsistent format. Mitigation: build evidence collection into the control itself, from week 13. Automated where possible. A shared drive with a deterministic folder structure if manual.
HR controls as an afterthought. Engineering-led teams routinely forget that background checks, onboarding security training, and offboarding access revocation are auditable controls. The People team finds out about SOC 2 three weeks before fieldwork and cannot retroactively document four months of compliance. Mitigation: involve the People function in Phase 1. Give them their own workstream.
Vendor management as a spreadsheet that nobody owns. By Phase 4 the auditor wants a current vendor inventory, evidence of vendor risk assessments, and contracts that include data processing terms. The spreadsheet has three owners and none of them have updated it since Phase 2. Mitigation: assign vendor management to a single named person. Not a committee.
Auditor availability. You scoped, implemented, ran the observation period, and now the auditor can’t start fieldwork for six weeks because they’re backed up with quarter-end work. Mitigation: book the auditor’s calendar in Phase 1, not Phase 3. Q1 and Q2 are the crunch quarters; a December fieldwork start is much easier to book.
The underlying pattern is simple. SOC 2 fails as a project management problem, not a security problem. Teams with solid security posture miss the date because nobody owns the schedule. Teams with mediocre security posture hit the date because someone holds a weekly fifteen-minute status meeting and chases slippage the day it happens. Pick the management you want before you buy the tooling.
Three tool categories
You do not need a GRC platform to get through a first SOC 2 audit. You probably do want one, and there’s a reasonable argument that you should buy one, but the decision is more nuanced than vendor sales teams will tell you. Three categories of tooling are worth considering.
Spreadsheet-only. A shared drive, a control matrix spreadsheet, an evidence folder with a sensible structure, a calendar with recurring reminders for the controls that run on a cadence. Completely viable for a first audit at a company under about 50 people. Low cost, high effort, and the effort compounds every year. Good for companies where the compliance lead is technically comfortable and wants full control over the process.
Lightweight compliance automation. Tools in this category (a growing middle market of newer GRC platforms) integrate with your cloud providers, HR system, and ticketing tools and automatically pull evidence for a significant chunk of controls. They usually come with a pre-built SOC 2 control framework and a policy template library. Good for companies in the 50–300 headcount range where the time saved on evidence collection justifies the subscription cost. This is the right category for most first-time SOC 2 SaaS companies.
Full GRC platform. The enterprise tier with workflow engines, advanced integrations, multi-framework support (SOC 2 plus ISO 27001 plus PCI plus whatever else), customer-facing trust portals, risk management modules. Worth the money for companies running multiple frameworks in parallel, for regulated industries, or where the customer-facing trust portal is a commercial asset in itself.
The test I’d apply: if you are running only SOC 2 and have fewer than 200 employees, the lightweight automation tier is almost always the right call. If you’re running two or more frameworks or have security engineering headcount dedicated to compliance, the full platform starts to pay for itself. If you’re a five-person team doing your first audit because a single big customer asked for one, the spreadsheet is fine and nobody will judge you.
FAQ
How long does SOC 2 really take?
Six months is the realistic minimum for a first Type II audit, from project kickoff to signed report. Four is possible if you start from strong security maturity and take a three-month observation window. Nine to twelve months is common for teams that underestimate the HR and vendor management workstreams.
What’s the difference between Type I and Type II?
Type I tests whether your controls are designed appropriately at a point in time. Type II tests whether those same controls operated effectively over a defined period — usually between three and twelve months. Type II is the one enterprise buyers treat as real evidence.
Can I do SOC 2 without a consultant?
Yes. Whether you should depends on your time budget and how much compliance muscle already exists on the team. A good consultant compresses the readiness and scoping phases by two to four weeks. That’s often worth their fee, but it isn’t mandatory.
How much does SOC 2 cost?
Auditor fees typically land in the $15,000–$50,000 range for a first Type II at a small-to-mid SaaS company, with larger and more complex scopes pushing higher. Add tooling (between zero and $50,000+ depending on category above), consultant fees if you use one, and the internal engineering and process time, and the all-in first-year cost for a 50-person SaaS company is usually $50,000–$150,000.
Do I need Type I before Type II?
Not strictly. Many companies go straight to Type II. A Type I can be useful as an interim customer-facing artefact while the observation period for Type II is running, but it isn’t required.
How long should the observation period be?
Minimum three months per AICPA standard; practical minimum six months for a first audit that you want customers to take seriously; twelve months is the norm for annual renewals.
When should I start looking for an auditor?
Phase 1. Auditor availability is the single most common external blocker on the schedule, and good auditors book out 8–12 weeks ahead during peak periods.
Does SOC 2 expire?
The report covers a defined observation period. Customers typically expect a fresh report every twelve months covering the previous year. If you let more than 15 months elapse without a new report, expect commercial consequences.
Is SOC 2 the same as ISO 27001?
No, but the controls overlap substantially. If you’re running both, do them as an integrated programme — see our dual-track guide for how to sequence the two audits without doing the work twice.
What happens if I fail the audit?
SOC 2 doesn’t work like a pass/fail exam. The auditor issues an opinion; the opinion can be unqualified (clean), qualified (some controls didn’t operate effectively), adverse (material failures), or a disclaimer (insufficient evidence to issue an opinion). A qualified report is recoverable, is honestly far more common than vendors admit, and is better than no report at all for most customers — but you’ll want to remediate for the next cycle. A genuinely bad audit result, the kind that damages a customer relationship, is almost always the result of Phase 1 scoping problems and Phase 2 implementation gaps that were known and not addressed. It’s preventable.