SOC 2 Type II for SaaS Startups: The 90-Day Roadmap

Your enterprise deal just stalled. The security questionnaire asked for a SOC 2 report, and you don’t have one.

That’s how most SaaS founders meet SOC 2 Type II for the first time. Not on a planning offsite, but halfway through a sales cycle they can’t afford to lose. The buyer’s procurement team has a security checklist, SOC 2 Type II is on it, and until you produce a report the contract sits in limbo.

It shows up in funding rounds too. Series B and later investors now ask whether portfolio companies hold a SOC 2 Type II report. They’re not auditing your firewall rules. They’re checking whether you built security into how the company runs, or bolted it on when a customer forced the issue.

One data point puts the pressure in context: 84% of SaaS companies say SOC 2 compliance influenced at least one enterprise deal in the past year (Vanta, 2024). So the real question for a startup isn’t whether to pursue SOC 2. It’s how to get there without burning six months of engineering time and your whole security budget.

This guide walks through what SOC 2 Type II requires, what it costs, what auditors look for, and a month-by-month plan to reach audit readiness in 90 days without freezing your product roadmap.

Figure 1: The 90-day path to SOC 2 Type II audit readiness. (See editor’s notes for spec.)

What SOC 2 Type II Requires, in Plain Terms

SOC 2 is a security standard from the American Institute of CPAs (AICPA). It sets out criteria, called Trust Service Criteria, that a company meets to show it handles customer data securely and reliably.

SOC 2 Type I vs. Type II: The Difference That Matters

Type I is a snapshot. An auditor reviews your controls and confirms they exist at a single moment in time. It runs 4 to 8 weeks and costs noticeably less than Type II. The message to a buyer is “this company has the right controls in place today.”

Type II is the operational version. An auditor reviews your controls across a set observation period, usually 3, 6, or 12 months, and confirms they ran consistently the whole time. The message to a buyer is stronger: “this company doesn’t just have the right controls, it uses them, day after day.”

Enterprise buyers and investors almost always mean Type II. Type I is a fine stepping stone, but it only proves your controls existed on one day, not that the team lives by them. If a customer asks for “your SOC 2 report,” assume Type II unless they tell you otherwise.

The Five Trust Service Criteria

SOC 2 is organised around five Trust Service Criteria. Only Security is mandatory. You add the others when they match your customers’ concerns or contractual requirements.

Criterion	What it covers	Who typically needs it
Security (CC)	Protecting systems from unauthorised access	Every SOC 2 report (mandatory)
Availability (A)	Systems available as committed	SaaS with uptime SLAs; business-critical software
Processing Integrity (PI)	Complete, accurate transaction processing	Fintech, payments, healthcare billing
Confidentiality (C)	Protecting information marked confidential	Platforms handling sensitive client data
Privacy (P)	Handling of personal information	Consumer platforms, HR tech, healthcare, GDPR-adjacent products

For most B2B SaaS startups, Security plus Availability is the right opening scope. Add Confidentiality if you hold sensitive client business data. Add Privacy if you process personal data under GDPR, CCPA, or similar rules.

Start with the minimum your target customers ask for. You can widen scope in later audits. Reaching for all five criteria in a first audit adds cost and delay you don’t need yet.

What the Security Criterion Covers

The Security criterion, formally the Common Criteria (CC), sits at the heart of every SOC 2 report. It spans nine control categories:

1. Control environment: does leadership set the tone on security?
2. Risk assessment: do you formally identify and rank security risks?
3. System operations: do you monitor systems and respond to events?
4. Change management: do you control changes to production?
5. Risk mitigation: do your controls address the risks you found?
6. Logical and physical access: who can reach your systems and data, and how is that managed?
7. System monitoring: are you logging security-relevant activity?
8. Vendor management: do you assess the third parties you rely on?
9. Business continuity: can you recover from incidents and keep operating?

For a typical Series A or B SaaS company, most of the practical work lands in categories 3, 4, 6, and 7: system operations, change management, access control, and monitoring.

Key Takeaways: What SOC 2 Requires

• Type II certifies that controls ran consistently over a set period. That’s what enterprise buyers and investors want.
• Only the Security criterion is mandatory. For most B2B SaaS, start with Security plus Availability.
• The observation period runs 3 to 12 months, and the clock starts once your controls are in place.
• 84% of SaaS companies say SOC 2 influenced at least one enterprise deal (Vanta, 2024).
• Scope creep is the top cost driver. Skip criteria your customers aren’t asking for.

Want proof it works in practice? Browse our security and compliance case studies to see how we’ve built controls into real client operations.

The 90-Day Roadmap to SOC 2 Type II Readiness

This plan assumes a startup with engineers but no dedicated security team, running on AWS, GCP, or Azure, using standard B2B tooling (GitHub, Slack, Google Workspace or Microsoft 365, a product analytics platform). It targets a 3-month observation period leading to a 6-month Type II report, the most common starting setup.

One thing to set expectations on: this roadmap gets you to audit readiness in 90 days. The observation period then runs 3 to 6 months, and the audit itself takes another 4 to 8 weeks after that. Your first report lands roughly 6 to 9 months after you start, depending on how long your observation window is.

Month 1: Foundation and Scoping

Month 1 is about understanding what you need to build, making the decisions that define the work, and putting the foundational controls in place.

Weeks 1 to 2: Readiness assessment and gap analysis. Before you write a single policy, take an honest look at where you stand. For each of the nine control categories, note what you already have, what evidence you could hand an auditor today, and what’s missing. Most startups find 30 to 40% of the required controls are already partly there. You’ve been doing access reviews informally; you have some monitoring running. The real gap is usually documentation, consistency, and coverage. This assessment also sets your scope: which criteria you’re pursuing, which systems are in, and which vendors you’ll need to review.

Weeks 2 to 4: Policies and foundational controls. Auditors will want written policies for information security, access control, change management, incident response, business continuity, and vendor management. These don’t need to be 50-page tomes. They need to be written, current, signed off by leadership, and followed. Alongside them, put the technical controls in place:

• MFA enforced on every in-scope system: cloud provider, code repository, production access, email, and collaboration tools.
• Access reviews started, with a documented process run at least quarterly.
• Centralised logging turned on across in-scope systems: cloud audit logs, application logs, access logs.
• Vulnerability scanning running automatically against production.

Lean on a compliance automation platform here (Vanta, Drata, Secureframe, or Tugboat Logic). These connect to the tools you already use, collect evidence automatically, map it against SOC 2 criteria, and show you in real time which controls pass and which fail. For a team without dedicated security staff, that cuts manual evidence work by around 70% and usually pays for itself inside the first audit cycle.

Month 2: Control Implementation and Evidence Collection

Month 2 is where the operational work happens. The goal is to get every required control implemented, running consistently, and producing evidence an auditor can review.

Access control. Roll out role-based access so each person has exactly what their role needs and nothing more. Manage admin and production access separately from regular accounts, with requests that need approval and a reason. Clear out stale access: people who changed roles, contractors who wrapped up, service accounts nobody uses. Document your onboarding and offboarding steps, because auditors will check that departing staff are removed from every system quickly. Tightening who can reach production is the core idea behind a zero-trust approach to access, and it pays off well beyond the audit.

Change management. Every production code change goes through a pull request reviewed by at least one other engineer. Keep production separate from development and staging, with deployments controlled and logged. Maintain a change log: what shipped, when, by whom, and whether it was approved.

Incident response. Write an incident response plan and share it: who gets called, how issues escalate, how you communicate with affected customers. Run a tabletop exercise to walk the team through a simulated incident and prove the plan holds up. Set up alerting so that when monitoring fires, someone sees it and knows what to do. This matters more every year, as ransomware has turned into a subscription business that increasingly targets smaller and mid-market companies.

Vendor management. List your critical vendors (cloud provider, database, CDN, payment processor, support tooling) and note their own certifications. Most major cloud providers are SOC 2 certified themselves. For vendors that touch your customers’ data, review their data processing terms and security docs.

Month 3: Audit Readiness and Remediation

Month 3 is about finding the gaps you missed and closing them before the auditor does.

Internal readiness review. Go control by control and ask: if an auditor wanted proof this ran consistently over the past 60 days, what would I show them? Flag anything where the answer is “I’m not sure.”

Evidence organisation. Auditors request specific evidence for each control, and it needs to be organised, not scattered across email, Slack, and personal drives. Your automation platform should handle most of this. Do a final sweep and fill any gaps by hand.

Auditor selection and kickoff. Pick a CPA firm licensed for SOC 2 work. Prices vary a lot: big-four firms run £30,000 to £80,000 for a startup’s first Type II, while startup-focused specialists usually charge £8,000 to £20,000 for the same scope. Firms that plug into compliance platforms often turn things around faster because the evidence is already structured. Book the kickoff, hand over your system description and scope docs from Month 1, and treat that as the start of your observation period. From here, your controls need to run consistently for the full window.

Key Takeaways: The 90-Day Roadmap

• Month 1: assess gaps, write policies, put in foundational controls (MFA, logging, vulnerability scanning).
• Month 2: harden access control, formalise change management, stand up incident response, review vendors.
• Month 3: run an internal readiness review, organise evidence, choose an auditor and kick off.
• Compliance automation platforms cut evidence work by about 70%.
• Startup-focused audit firms charge £8,000 to £20,000, well below big-four pricing for the same scope.

Figure 2: A compliance automation dashboard tracking SOC 2 controls in real time. (See editor’s notes for spec.)

What Auditors Look For

Knowing where auditors focus helps you prioritise during the build and skip surprises during the audit.

Consistency over perfection. Auditors aren’t grading a perfect security programme. They want evidence that the controls you described ran consistently across the observation period. An access review that happened every quarter is stronger evidence than one that happened flawlessly a single time.

A deep look at access control. Every auditor spends real time here. Expect them to ask for the list of users with production access at several points during the period, proof that access was reviewed at least quarterly, proof that departed staff were removed promptly (24 hours is the bar they’ll expect), and proof that admin access was managed separately with extra controls.

Change management traces. Auditors will pull specific production changes from your deployment history and follow each one through your process. Can you show it was reviewed and approved before it shipped? Is there a pull request with a second engineer’s sign-off? Is there a deployment log confirming when it went live?

Separation of environments. Can you show that developers can’t reach production data or deploy to production without going through change management? Plenty of early-stage startups don’t have this fully locked down, because moving fast meant handing out production access. Auditors look for it specifically.

Common Failure Points, and How to Avoid Them

Policies nobody follows. Write short, practical policies that describe what you already do, then do them. A two-page access policy your team follows beats a 20-page one gathering dust on a shared drive.

Manual evidence that doesn’t scale. Put a compliance platform in place in Month 1, not Month 3. Starting by hand and switching later means doing the work twice.

Scope creep from sales enthusiasm. Keep the first audit to Security plus Availability unless a specific customer demands more. Adding Privacy or Processing Integrity early drives up both cost and time. Win the deal on Security plus Availability, then expand in year two.

Forgotten vendor management. Document your critical vendors and their security posture in Month 1. Many teams hit Month 3 and realise they never assessed a single vendor. Auditors will ask, so keep a simple vendor risk register ready.

The Bottom Line

A SOC 2 Type II report isn’t a formality you clear once. It’s evidence that security is part of how engineering, operations, and leadership work every day.

It’s also a commercial asset. The enterprise deals it unlocks, the confidence it gives investors, and the edge it gives you over less mature competitors are real, measurable returns.

You can reach readiness in 90 days without a dedicated security team and without stalling your roadmap. Start the gap assessment now, use a compliance platform instead of collecting evidence by hand, scope the first audit conservatively, and take the observation period seriously. The audit only reviews what happened, and what happened comes down to how your team operates when nobody’s watching. If you’d rather not run it alone, our AI security and compliance team can help you map controls and evidence from day one.

Not sure where your gaps are? Book a free readiness call and we’ll map your fastest path to a report your buyers will accept.

Frequently Asked Questions