What Does a First-Time SOC 2 Audit Actually Find?

Why first-timers have gaps (and why that's normal)

I spent five years doing SOC 2 fieldwork at a Big 4 firm before I started my own. In that time I sat across the table from a lot of companies opening their first audit, and the pattern almost never changes. You built a product. You shipped fast. You hired for engineering, not for an audit program. So when the auditor shows up, the controls a SOC 2 cares about either live in someone's head or haven't made it onto paper yet.

That's not a failing. It's the default state of a company that's been busy building the thing customers actually pay for. In my experience, the typical gap rate on a first-time SOC 2 runs 40-60% of the control areas we look at, and most first-timers would not pass a Type I cold, which is the whole reason a readiness pass exists. (A Type I is the version of the report that checks whether your controls are designed properly at a single point in time.) So if your review comes back with half your controls flagged, you are not an outlier. You are right in the middle of the pack.

What trips people up is that the controls usually aren't *missing* in spirit. You probably do review who has access. You probably do patch things. The gap is that SOC 2 is graded on evidence and consistency, not on good intentions. A control that exists in practice but was never written down, never assigned an owner, and never run on a schedule is, to an auditor, a gap. There's simply nothing to point to that proves it happens.

The five gaps I find almost every time

These five show up in nearly every first-time engagement I've worked. Each one maps to a specific AICPA Common Criterion, so this isn't a hunch. The Common Criteria are the security standards your report is graded against (the formal name is the Trust Services Criteria, or TSC), and these are the spots where they reliably catch new companies.

If you've ever read the Common Criteria (they're built on the COSO internal-control framework, the same backbone large companies use), these won't surprise you. CC3, CC7, CC8, and CC9 are exactly the areas where a young company has the least paper. That's no accident. The framework is testing operational discipline, and discipline is the last thing a 12-person team gets around to writing down.

Finding issues is the sign of a real audit

Here's the part nobody tells founders. If your auditor finds nothing on a first-time engagement, that's the thing to worry about, not the clean report.

Look at what the Delve situation surfaced in early 2026. An anonymous investigation alleged that 493 of 494 SOC 2 reports the firm issued were nearly identical, down to the same grammatical errors, and that all 259 Type II reports carried word-for-word identical auditor conclusions. The investigation alleged that reports were pre-populated before clients had submitted a single piece of evidence, and that risk assessments came pre-filled with defaults. Delve has denied the allegations, which remain contested. Set the specific company aside, because the pattern is the lesson on its own. That is the shape of a rubber-stamp audit at scale, and zero findings was the tell.

A real audit follows the standard called AT-C 205, which says just asking is never enough on its own. "Inquiry" is the audit word for asking you a question, and every control needs at least one corroborating procedure on top of it, meaning the auditor has to inspect something, watch it happen, or re-perform it to confirm your answer holds up. When someone actually tests your controls against the criteria, they will find the same first-timer gaps everyone has. Finding them is the work. A report with no exceptions on a first audit isn't proof you're secure. It's a sign that nobody looked very hard.

What a real finding actually reads like

Here is the difference in one control. A termination control (the process for cutting off access when someone leaves) on a rubber-stamp audit reads: "no exceptions noted." That sentence tells you nothing, because you can't see what was tested. A real finding reads more like this: we inspected 8 employee terminations during the period and found 1 where system access wasn't revoked within the 24 hours your own policy requires, so we tested the backup control and confirmed that no login was recorded for that account during the gap. One of those is a checkbox. The other is evidence that someone pulled the full list, sampled it, found the exception, and chased down whether it actually mattered.

The second version is more useful to you, and to the customer reading your report, and it's the version you only get when a real auditor does the work. The way to surface those findings before they cost you a deal is a mock exam run by an actual auditor, rather than a dashboard that only checks whether a policy file exists.

What this means for you

A 40-60% gap rate sounds alarming until you see how fast most of it closes. The gaps above are paperwork and process, not re-architecting your stack. In my experience the common ones get fixed in weeks, not months. Industry timelines put minor gaps at 1-2 weeks to audit-ready and a heavier load at 8-16 weeks, depending on how much you're starting from scratch.

So the move isn't to panic when the findings come back. It's to get the findings *early*, from someone who'll tell you the truth, and fix them before the observation window starts. That's the whole idea behind stress-testing first and verifying after.