A 90-day SOC 2 readiness plan that survives contact with the auditor
The reality of SOC 2 is that the 'compliance-in-a-box' approach often crumbles the moment a seasoned auditor begins a forensic walkthrough of your production environment. To achieve a clean report without derailing your product roadmap, you need a pragmatic, 90-day execution plan that prioritises operational evidence over mere policy documentation. This guide outlines how to build a defensible security posture that satisfies the Big Four and boutique firms alike.
Michael McCarroll— Founder · 20+ yrs GRC, ISO 27001 lead implementer 16 min read Updated June 2026
Days 1-30: Scoping and Gap Analysis with Surgical Precision
The most common mistake founders make is selecting too many Trust Services Criteria (TSC) too early. For your first audit, focus almost exclusively on the Security criteria, known as the Common Criteria. This covers the fundamentals: risk assessment, logical access, change management, and incident response. Adding Availability or Confidentiality sounds good for marketing but adds significant overhead to your evidence collection requirements.
Begin by defining your 'System Boundary' with clinical precision. This isn't just a list of your AWS resources; it is a description of the people, processes, and technology that handle customer data. If you can move certain non-critical functions outside this boundary, you reduce the audit surface area and the cost of the engagement. An over-scoped audit is the primary cause of 90-day plans turning into 180-day nightmares.
Once the scope is set, perform a gap analysis against the TSC. Don't rely on generic templates; instead, map your existing technical workflows to the criteria. You likely already do 60% of what is required, such as using GitHub PRs for code reviews or SSO for access. The goal of Day 1 to 30 is not to reinvent your business but to document how your current business satisfies the requirements.
Days 31-60: Policy Formalisation and Control Implementation
The second month is where the heavy lifting happens: moving from 'we do this' to 'here is the policy that says we do this.' Policies should be short, readable, and functional. An 80-page Information Security Policy that no one reads is a liability, not an asset. Aim for modular policies—one for Access Control, one for Incident Response, and one for Change Management—that are easy to update and distribute to the team.
You must also establish your 'tone at the top.' Auditors look for evidence that leadership takes security seriously. This means holding a formal risk assessment meeting and documenting the minutes. You need to assign a formal Security Officer role; even if it's the CTO, the designation matters for the audit trail. This is the period to institutionalise the rituals that generate the evidence you will later provide.
Implement a formal 'Joiners, Movers, Leavers' (JML) process with verifiable logs.
Enforce Multi-Factor Authentication (MFA) across every single production and administrative system.
Draft a Risk Assessment that identifies specific threats to visibility, integrity, and availability.
Establish a Vendor Management policy to review the SOC 2 reports of your own sub-processors.
Record a 'Management Assertion' that takes responsibility for the system description.
Days 61-90: Evidence Collection and the 'Dry Run' Walkthrough
An audit is not an exam you pass; it is an attestation you support with data. By Day 61, you should be collecting 'samples' of your controls in action. If you claim to perform quarterly access reviews, you need the spreadsheet or Jira ticket that proves the review happened and that access was revoked for those who no longer needed it. This is where most firms fail—they have the policy but no proof of execution.
I recommend performing a 'dry run' walkthrough for your most critical controls: Change Management and Logical Access. Ask your lead engineer to show you, on screen, how a change moves from a local machine to production. If they can't show the link between a Jira ticket, a GitHub Pull Request, and a CI/CD deployment log, then neither will the auditor. Fix these visibility gaps now, before the formal fieldwork begins.
Automated screenshots of your AWS/Azure configuration (e.g., S3 buckets not public).
HR records showing background checks performed prior to the start date for new hires.
Sample tickets showing that a code change was requested, tested, and approved by someone other than the author.
Logs from your last business continuity test or database restore exercise.
The Auditor Perspective: Selecting and Managing the Engagement
The CPA firm you choose is your partner, not your adversary, but they are bound by strict professional standards. When choosing an auditor, look for firms that understand the 'cloud-native' stack. A firm that expects to see physical server room logs for an AWS-hosted startup is going to cause unnecessary friction. Ask for a sample report and a clear list of their evidence requests (the 'PBC' or Provided By Client list) upfront.
During the audit, your goal is to be responsive but concise. Answer the question asked and provide only the evidence requested. Over-sharing can lead to 'scope creep,' where an auditor sees an unrelated issue and feels compelled to investigate further. Designate a single point of contact for the auditor to ensure that communication is consistent and that evidence is vetted before it is uploaded to the audit portal.
Beyond Day 90: Scaling from Type 1 to Type 2 Maturity
A SOC 2 Type 1 report is a point-in-time assessment. It is a fantastic milestone, but it is effectively a 'learner's permit.' The real value lies in the Type 2, which proves you maintained these standards over a period of months. Do not let your controls lapse the moment the Type 1 audit concludes. The day after your Type 1 'as-of' date is Day 1 of your Type 2 observation period.
Scaling security requires moving away from manual checks toward automated monitoring. Use platforms that integrate with your stack to provide real-time alerts when a control fails (e.g., a user disables MFA or a database becomes publicly accessible). This move from 'periodic' to 'continuous' compliance is what separates mature organisations from those who scramble every year for their audit renewal. This maturity is exactly what enterprise buyers look for.
Turn Compliance into a Competitive Advantage
Stop drowning in spreadsheets and fragmented evidence. ISO-STANDARD.app provides the single source of truth for your controls, automated evidence collection, and a clear path to audit-readiness that builds trust with your biggest customers.
ISO-STANDARD.app ships a ready-to-adopt SOC 2 workspace with the risk register, controls catalogue, policies and audit-ready exports already wired together — no spreadsheet sprawl, no consultant lock-in.
Prefer a conversation? Email hello@iso-standard.app — a real human responds within one business day.
Frequently asked questions
What is the difference between SOC 2 Type 1 and Type 2?
A Type 1 audit provides a snapshot of your control design at a specific point in time, whereas Type 2 evaluates the operational effectiveness of those controls over a period (usually 6-12 months). Most founders start with a Type 1 to get a report quickly, then transition immediately into their Type 2 observation period. Type 1 is about 'do you have a plan?', while Type 2 is about 'did you actually follow it?'
Is SOC 2 mandatory for SaaS startups?
While there is no legal requirement to have a SOC 2, it has become a de facto requirement for doing business with enterprise companies in North America. If you are selling SaaS to a firm with a procurement or risk department, they will likely demand a SOC 2 report to verify your security posture. Without it, you are effectively blocked from moving up-market.
How much does a SOC 2 audit actually cost?
The total cost usually involves three components: the readiness software, the consultant (if used), and the CPA firm performing the audit. Expect to pay anywhere from £15,000 to £40,000 for a reputable audit, depending on your size and scope. Be wary of 'cut-price' audits; enterprise procurement teams often maintain a list of approved auditors and may reject reports from firms they don't recognise.
Which Trust Services Criteria (TSC) should I choose?
Security is the only mandatory category. You should only add Availability, Confidentiality, Processing Integrity, or Privacy if your customers specifically ask for them or if they are core to your value proposition. Adding more criteria increases the audit surface area and the risk of a 'qualified' opinion (a fail). Start small and expand in year two.
Action checklist PDF
Mirrors this guide with owners, artefacts & a 30/60/90-day plan.
