SOC 2 for first-timers: the exact order of operations

Ask ten companies going through SOC 2 for the first time what order they did things in, and you'll hear the same story with the steps scrambled: bought the platform first, wrote policies that didn't match reality, discovered the infrastructure gaps too late to fix before the audit window opened, and scrambled for the last six weeks. The audit itself rarely fails. The sequencing before it does.

Here's the order that actually works, and why each step depends on the one before it.

Step 1: Choose your scope before anything else

Decide which Trust Service Criteria apply — Security is mandatory for every SOC 2 report; most companies add Availability and Confidentiality, and add Processing Integrity or Privacy only if the business specifically requires it (payment processing, health data, and similar). Adding criteria you don't need adds audit scope and evidence burden without adding much credibility with the customers actually asking for the report.

Decide Type I vs Type II at the same time. Type I is a point-in-time snapshot of control design — achievable faster, useful as an interim deliverable if a customer needs something sooner. Type II is evidence that controls operated effectively over an observation period, commonly three months for a first report. Most enterprise buyers ultimately want Type II. Many first-time companies do a Type I first as a milestone, then roll straight into the Type II observation window — a reasonable sequencing decision, but it needs to be made deliberately, not defaulted into.

Step 2: Run a gap analysis before buying anything

This is the step most commonly skipped, and skipping it is the single biggest predictor of a rough audit experience. A gap analysis is an honest internal (or consultant-led) review of where current practice diverges from what your chosen Trust Service Criteria require — before you've bought a platform, before you've written a policy, before an auditor is involved.

Done properly, this produces a concrete list: MFA not enforced organization-wide, no formal access review process, production database unencrypted at rest, no documented incident response plan, no vendor risk assessment process. This list is the actual project plan for everything that follows. Skipping straight to a compliance platform without this step means discovering these gaps piecemeal, often during the audit itself.

Step 3: Pick your compliance platform — now, not before

Once you know what you're actually dealing with, a platform like Vanta, Drata, or Secureframe earns its cost: automated evidence collection from your cloud provider and identity provider, policy templates that save weeks of writing from scratch, and continuous monitoring that flags drift after your controls are live. Buying it before Step 2 just means paying for a dashboard that confirms, slowly, what a gap analysis would have told you in a week.

Step 4: Assign named control owners

Every control in scope needs a specific person accountable for it — not "the engineering team," not "IT." Who reviews access quarterly. Who owns incident response. Who signs off on new vendor risk assessments. Auditors ask for this explicitly, and "the platform handles it" is not an answer that satisfies them — platforms collect evidence that a human process happened; they don't substitute for the process.

Step 5: Close the infrastructure gaps first

This is usually the longest step, and it needs to happen before policies are finalized, not after — a policy describing practices you haven't implemented yet is a documented control failure waiting to be found. Common first-time gaps, roughly in order of how often we see them:

• MFA and SSO not enforced organization-wide
• IAM permissions broader than least-privilege requires
• No centralized logging or log retention policy
• Databases or storage without encryption at rest
• No tested backup and disaster recovery process
• No formal change management process for production deployments

Step 6: Write policies that match what you actually do

Once the infrastructure work is underway or complete, write information security policy, access control policy, incident response policy, and the rest to describe your actual practice — not an aspirational version of it. If quarterly access reviews aren't happening yet, don't write a policy claiming they are; get the review actually running first, then document it.

Step 7: Run and document your first access review

This needs to happen for real, with evidence — who has access to what, reviewed by named owners, with access removed where it's no longer needed, and a record showing the review happened. This is one of the most commonly requested pieces of evidence in any SOC 2 audit and one of the most commonly faked-in-appearance-only by first-time companies. Auditors are good at spotting the difference between a review that happened and a screenshot taken to look like one did.

Step 8: Assess vendor risk for anything touching customer data

For every vendor with access to customer data — your cloud provider, your database provider, any SaaS tool that processes customer information — collect their own compliance evidence (SOC 2 report, security documentation) and document that someone actually reviewed it. A vendor list with no assessment attached doesn't satisfy this requirement.

Step 9: Test your incident response plan

Not just write it — run a tabletop exercise, walk through a plausible scenario with the people who'd actually be involved, and document that it happened. Auditors increasingly ask for evidence of a test, not just a policy document sitting unused since the day it was written.

Step 10: Engage your audit firm and start the clock

Only now — with infrastructure gaps closed, policies matching practice, and named owners running actual processes — does it make sense to engage an audit firm and, for Type II, start the observation window. Starting this clock before the controls it's measuring are actually in place just means the evidence period documents a program that wasn't real yet.

The realistic timeline

For a company starting from genuinely nothing: Steps 1-2 take one to two weeks. Steps 3-6, the infrastructure and policy work, typically run six to ten weeks depending on how many gaps the analysis surfaced. Steps 7-9 run in parallel with the tail end of that remediation. Type I can follow shortly after everything is in place. Type II requires committing to the observation window on top of that — commonly three months for a first report — during which the controls need to keep running, not just exist.

Compressing this by starting the clock early, or by assuming the platform handles the steps it doesn't, is the most common reason first-time SOC 2 timelines run a full quarter longer than expected.

OneHorn runs SOC 2 and ISO 27001 readiness engagements for companies doing this for the first time — gap analysis, infrastructure remediation, and control ownership, in the order that actually holds up under audit.