What your first SOC 2 audit really requires

A compliance platform collects evidence. It doesn't configure your cloud or write your access review.

Every first-time SOC 2 conversation starts the same way: a founder or CTO has heard that a platform like Vanta, Drata, or Secureframe will "get us SOC 2 compliant," signs up, connects a few integrations, and watches a dashboard fill up with green checkmarks. Then, four to six weeks before the audit, the checkmarks stop being enough, and the actual work — the work the platform was never going to do — is suddenly compressed into a panic sprint.

This isn't a knock on those platforms. They're genuinely useful for what they do. The problem is what people assume they do, versus what SOC 2 actually requires.

What SOC 2 actually is

SOC 2 is an attestation, not a certification. An independent auditor examines your controls against the Trust Service Criteria you've chosen to be evaluated on — Security is mandatory, and most companies add Availability and Confidentiality, with Processing Integrity and Privacy added when relevant to the business — and issues a report describing whether those controls are designed appropriately (Type I, a point-in-time snapshot) and, for Type II, whether they operated effectively over an observation period, typically three to twelve months.

That distinction matters more than most first-timers realize. Type I answers "do you have the right controls on paper." Type II answers "did you actually follow them, consistently, for months." Most enterprise customers asking for SOC 2 as a vendor requirement want Type II — which means the clock on evidence collection has to start months before the audit itself, not the week before.

What a compliance platform actually does well

To be fair to the tooling: automated evidence collection is genuinely valuable. These platforms pull continuous evidence from your cloud provider, your identity provider, and your device management tooling — confirming MFA is enabled, tracking whether laptops are encrypted, monitoring for new admin grants — and they come with policy templates that save weeks of writing information security policies from a blank page. For a team with no compliance program at all, that's a real head start.

What it doesn't do

This is the part that catches teams off guard.

It doesn't configure your infrastructure. The platform can tell you that MFA isn't enforced organization-wide, that S3 buckets are publicly readable, or that your production database has no encryption at rest. It cannot enforce MFA, lock down the bucket, or turn on encryption. Every infrastructure gap the platform surfaces is still your engineering team's work to close, and for a company that's never done a security-focused infra review, that list is usually longer than expected.

It doesn't write your access review process. SOC 2 auditors want to see evidence that someone, on a defined cadence, actually reviewed who has access to what and removed access that's no longer needed. A platform can generate the access list. It can't decide who should still have production database access, assign that decision to a human owner, or prove the review actually happened with sign-off — that's a process your team has to build and run.

It doesn't do vendor risk management with any real substance. Most platforms include a vendor tracking feature. Auditors want evidence that you actually assessed the security posture of vendors who touch customer data — not just a spreadsheet with vendor names in it.

It doesn't produce a Type II observation period retroactively. This is the one that surprises people most. If your controls have only been "on" for three weeks when the audit window opens, no platform can manufacture the other five months of evidence a Type II report needs. Waiting to start until the tooling is fully wired up is the single most common reason first-time SOC 2 timelines slip by a quarter or more.

The work that actually has to happen

Underneath the dashboard, a real SOC 2 program requires:

• A readiness assessment / gap analysis — an honest audit of where your actual practices diverge from what the Trust Service Criteria require, done before the auditor engagement starts, not during it.
• Policies that match reality, not aspirational documents. An information security policy that says access is reviewed quarterly, when no quarterly review has ever happened, is worse than no policy — it's a documented control failure waiting for the auditor to find it.
• Named control owners. Every control needs a human accountable for it — who reviews access, who owns incident response, who signs off on vendor assessments — because "the platform handles it" is not an answer an auditor accepts.
• Infrastructure remediation, closing the gaps the platform correctly identifies but can't fix itself: enforced MFA and SSO, least-privilege IAM, encryption at rest and in transit, centralized logging, tested backup and disaster recovery.
• An incident response plan that's actually been tested, not just written — auditors increasingly ask for evidence of a tabletop exercise, not just a PDF.
• Time. For Type II specifically, the evidence period is not negotiable. Starting the clock is a decision to make deliberately, once the controls it's measuring are actually in place — not a deadline to back into.

A realistic first-time timeline

For a company starting with genuinely no program: a gap analysis and remediation phase typically runs six to ten weeks, closing the infrastructure and process gaps the assessment surfaces. Type I can follow shortly after, once controls are demonstrably in place. Type II requires committing to an observation period — commonly three months for a first report, extending to six or twelve in later cycles — during which the controls need to actually run, not just exist in a policy document.

Compressing this by throwing more platform integrations at it doesn't work, because the bottleneck was never evidence collection. It was always the underlying infrastructure and process work the platform was never built to do.

The actual takeaway

Buy the compliance platform. It's a legitimate and useful part of the stack. Just budget the engineering time, the process design, and the calendar months separately — because that's where the audit is actually won or lost, and it's the part no dashboard does for you.

OneHorn helps small B2B technology companies prepare for SOC 2 by closing infrastructure, process, and evidence gaps before the audit starts.