How to Get SOC 2 Ready: A Step-by-Step Roadmap
Getting SOC 2 ready follows a predictable sequence: scope the right Trust Services Categories, close gaps, document and operate controls, and collect evidence. The report itself comes only from a licensed CPA firm — here is the honest end-to-end roadmap.
Step 1: Decide your scope — categories and report type
Before any documentation, settle two scoping questions, because everything downstream depends on them. The first is which Trust Services Categories you will be examined against. There are five — Security, Availability, Processing Integrity, Confidentiality, and Privacy — and Security, the Common Criteria, is always in scope for a SOC 2 examination. The other four are optional and should be included only when they are genuinely relevant to the service you provide. A SaaS platform that makes uptime commitments often adds Availability; a service handling sensitive customer data might add Confidentiality. Each added category brings its own criteria, controls, and evidence, so scope tightly: including a category you do not need adds work and cost without satisfying any buyer.
The second question is Type I versus Type II. A Type I report assesses whether your controls are suitably designed as of a single date — a snapshot. A Type II report goes further, testing whether those controls actually operated effectively across an observation period, commonly three to twelve months. Most security-conscious enterprise buyers ultimately want a Type II, because it shows durability rather than a single good day. Many organizations sequence a Type I first to validate design relatively quickly, then a Type II once controls have been running long enough to test — but a Type I is not a prerequisite, and teams with mature controls sometimes go straight to Type II.
Get these two decisions right and the rest of the roadmap is largely execution. Get them wrong — over-scoping categories, or committing to a Type II before controls exist — and you pay in wasted effort and delay.
Step 2: Run a gap assessment against the criteria
Once scope is set, measure where you stand. A gap assessment (often called a readiness assessment) compares your current practices against the Trust Services Criteria you have chosen, control by control, and produces a list of what is missing, what exists but is undocumented, and what is documented but not actually operating. Unlike a framework with a fixed, prescriptive control list, SOC 2 lets you design controls that fit your business against the criteria — which makes a clear-eyed gap assessment especially valuable, because there is no single checklist handed to you.
You can run this yourself against the criteria, or bring in a consultant or fractional CISO to facilitate it. Either way, the output is a remediation plan: the specific policies to write, controls to stand up, and evidence routines to start. This is the moment to be honest about effort. The gap assessment usually reveals that you already do many of the right things informally — access reviews, backups, onboarding checks — but have never documented them or made them consistent. That informal practice is an asset; it just needs to be formalized and evidenced before an auditor will credit it.
Step 3: Write and map your policies and procedures
With gaps identified, build the documentation layer: the policies and procedures that describe how your controls work, each mapped to the Trust Services Criteria in scope. This typically includes an information security policy, access control, risk assessment, vendor management, change management, incident response, encryption, logging and monitoring, business continuity, and data retention, among others. The mapping matters as much as the writing — an auditor needs to trace each criterion to the policy and control that satisfies it, and a clean crosswalk reduces back-and-forth during the examination.
This is the stage where editable documentation makes the biggest difference, and where the ComplianceDocs SOC 2 toolkits fit. The SOC 2 Policy Pack — Core ($59) provides 15 editable policies plus a control-mapping workbook that maps them to the SOC 2 Trust Services Criteria; the SOC 2 Complete Toolkit ($99) adds more policies plus a risk register and an audit evidence checklist. Bundles that pair SOC 2 with AI governance or ISO 27001 are also available (current list prices; a launch discount code may apply at checkout). To be clear about what they do and do not do: a toolkit gives you the documentation layer as an editable starting point so you tailor rather than draft from a blank page, which can turn weeks of writing into days. It does not produce the SOC 2 report and does not make you compliant or attested. The policies still have to describe how you genuinely operate, and you still have to operate the controls.
Step 4: Implement and operate the controls
Documentation describes controls; this step makes them real. Implementing controls means configuring the technical and procedural safeguards your policies promise — enforcing multi-factor authentication, restricting and reviewing access, running vulnerability scans, capturing logs, training staff, managing vendors, and following your change and incident processes in practice rather than on paper. A policy that says you perform quarterly access reviews is worthless to an auditor unless the reviews actually happen and leave a trail.
For a Type I, the controls need to be designed and in place as of the report date. For a Type II, they need to be operating from the first day of the observation window, because you cannot retroactively manufacture months of evidence. This is why the documentation has to be real and followed early — not assembled the week before fieldwork. Assign each control an owner so there is always someone accountable for keeping it running and producing the records that prove it ran.
Step 5: Collect evidence and run the observation window
Evidence is the proof that your controls operate as documented: access-review records, completed vulnerability scans, training completion logs, change tickets, incident reports, vendor assessments, and the like. For a Type I, the auditor reviews evidence of design as of the report date. For a Type II, the defining feature is the observation window — typically three to twelve months — across which the auditor samples evidence to confirm controls operated continuously, not just once.
This window is gated by calendar, not effort: a six-month Type II requires six months of operating records, and no amount of money compresses that. Plan for it. Some teams adopt compliance-automation tooling (such as Vanta, Drata, or Secureframe) to continuously collect evidence, which can help most when the Type II evidence burden becomes continuous; it is an optional accelerator, not a requirement, and it is not a substitute for the CPA examination. As illustrative planning context, a small first-timer might spend a few months on Steps 2 through 4, then run a three-to-six-month Type II window — but actual timelines vary widely by scope and starting maturity, so treat any figure here as an estimate, not a quote.
Step 6: Select a CPA firm and complete the examination
The final steps produce the actual report — and they are the part you cannot do yourself. A SOC 2 report is an independent attestation that only a licensed CPA firm can issue, after examining your controls against the AICPA Trust Services Criteria. Choose the firm deliberately: get written proposals for your specific scope, since examination fees vary considerably by firm, report type, and complexity, and confirm the firm is licensed to perform SOC 2 attestation work. Doing this selection in parallel with your readiness work, rather than at the very end, helps you align the examination date with the close of your observation window.
During the examination, the firm reviews your documentation, tests your controls, and samples your evidence across the window for a Type II. The deliverable is the SOC 2 report containing the auditor's independent opinion — not a pass/fail grade and not a certificate. This is the honest division of labor that runs through the whole roadmap: the documentation, the controls, and the evidence are your work, and editable toolkits and automation can speed them; but the report comes only from the CPA firm. No toolkit, template, or platform makes an organization SOC 2 compliant or attested. Plan for SOC 2 as recurring, too — because a report covers a defined period and buyers want a current one, most organizations renew their Type II annually.
Frequently asked questions
- How long does it take to get SOC 2 ready?
- It depends mostly on how mature your controls already are and which report type you pursue. As an illustrative pattern, a small first-timer might spend a few months on the gap assessment, documentation, and control implementation, then — for a Type II — run an observation window of typically three to twelve months on top of that. A Type I is faster because it is a point-in-time review with no observation window. These are estimates, not quotes; actual timelines vary widely by scope, headcount, and starting point, so plan against your own situation.
- Which Trust Services Categories should I include in scope?
- Security, the Common Criteria, is always in scope for a SOC 2 examination, so every report includes it. The other four — Availability, Processing Integrity, Confidentiality, and Privacy — are optional and should be included only when they are genuinely relevant to the service you provide. A platform with uptime commitments often adds Availability; a service handling sensitive data might add Confidentiality. Scope tightly, because each added category brings its own criteria, controls, and evidence, increasing effort and cost without value if it does not match what your buyers need.
- Should I do a Type I or a Type II first?
- There is no rule requiring a Type I first. Many organizations sequence a Type I to validate that controls are designed correctly — relatively quickly and cheaply — before committing to the longer observation window of a Type II, and a Type I gives you something to show buyers in the meantime. Others, particularly those with reasonably mature controls already running, go straight to a Type II to avoid paying for two engagements. Choose based on your control maturity, timeline pressure, and what your buyers will actually accept, and ask your CPA firm to advise on the trade-off for your scope.
- Can a SOC 2 toolkit make my company compliant or attested?
- No. No template or toolkit makes an organization SOC 2 compliant or attested. A SOC 2 report is an independent attestation that only a licensed CPA firm can issue after examining the controls you actually operate, for either a Type I or a Type II. A toolkit is the documentation layer of readiness: it gives you editable policies and procedures mapped to the Trust Services Criteria so you tailor rather than draft from scratch, which cuts readiness time. You still have to operate the controls, generate the evidence, and undergo the CPA examination to get the report.
- What evidence do I need to collect for a SOC 2 Type II?
- You need records that prove each control actually operated throughout the observation window, not just that it was designed. Common examples include access-review records, vulnerability scan results, security training completion logs, change-management tickets, incident reports, backup and monitoring logs, and vendor risk assessments. For a Type II the auditor samples this evidence across the full period — typically three to twelve months — so the controls must be running and producing records from the first day of the window. You cannot retroactively create evidence for time that has already passed, which is why operating controls early is essential.
Related guides: SOC 2
Toolkits that help
SOC 2 Policy Pack — Core
15 editable SOC 2 policies mapped to the Trust Services Criteria — the document set your auditor asks for first.
SOC 2 Complete Toolkit
22 policies plus the risk register, full Trust Services Criteria mapping and audit evidence checklist — built for startups facing their first SOC 2.
