Why Most Companies Fail Their First Compliance Gap Analysis (And What It Actually Reveals)
Authored by Peter Briel, Founder, Privaxi
After 25 years in cybersecurity and compliance, I can tell you the most dangerous sentence in this industry: “We’re pretty much ready for the audit.”
I hear it from nearly every new client, and nearly every time the first gap analysis tells a different story. That’s not because these companies are careless — it’s because frameworks measure things most organizations have never had a reason to look at until a contract, a customer, or a regulator demands proof.
The biggest reason companies fail is that they confuse activity with readiness. They have tools, policies, meetings, and spreadsheets — but not an engineered control environment. Here’s what that looks like in practice, and why a failed gap analysis is the most valuable thing that can happen to your security program.
Mistake #1: Confusing “secure” with “audit-ready”
A healthcare technology client came to us believing they were largely ready. They had policies in place, MFA enabled, endpoint protection deployed, and a ticketing process for security issues. On paper, they felt mature.
What we found was that the controls existed but weren’t consistently implemented, evidenced, or governed. Access reviews happened informally but weren’t documented. Logging was enabled in some systems, but not centrally reviewed or retained. Vendor risk sat with procurement, with security and compliance often out of the loop. They had pieces of a program, but not a defensible compliance operating model.
Being “secure” and being “audit-ready” are not the same thing. A company can have safeguards in place, but if it can’t prove the control operates consistently, the gap still exists. Auditors don’t grade intentions. They grade evidence.
Mistake #2: Treating the framework as a checklist instead of a system
We see this constantly when organizations divide framework requirements across departments without a central control owner. One group answers access control, another handles logging, another covers vendor management — and every team believes it’s completing its portion correctly.
The problem is that controls overlap. HR may define onboarding and termination one way, IT may manage access provisioning another, and compliance may write the policy a third way. Each department checks its own box, but across the full control environment the process is inconsistent — and inconsistency is exactly what an auditor is trained to find.
This is why we emphasize engineering controls, not just answering framework questions. You need one integrated control design that works operationally and maps across requirements. CMMC is a good example: companies fixate on answering the 110 NIST 800-171 requirements, but the real question is whether each control is implemented, owned, monitored, and evidenced across the actual environment where CUI lives.
Mistake #3: Scoping wrong before the work even starts
The most expensive mistakes happen before anyone touches a control — when you draw the boundary in the wrong place.
One client assumed only its main production platform was in scope. During discovery, we found sensitive data also living in support tickets, file shares, email workflows, reporting exports, and vendor systems — a far broader environment than the original scope. We’ve also seen the opposite: companies that include every system, department, and location because they’ve never mapped their data flows, inflating cost, evidence burden, and audit complexity.
The better approach is to start with the data, not the systems. Where does regulated data enter? Where is it stored? Who can access it? Where does it move, and which third parties touch it? Once you understand the data flow, scope becomes defensible instead of a guess.
What a failed gap analysis actually tells you
Here’s the reframe I give every client: a gap analysis full of red isn’t a failure. It’s the first honest map of your organization you’ve ever had.
In many first assessments, roughly 60–70% of the gaps aren’t completely missing safeguards — they’re missing documentation, ownership, consistency, or evidence that proves the safeguard is operating. That distinction matters, because a gap analysis shouldn’t just identify problems. It should help you engineer a program that can actually be proven.
Three takeaways from two and a half decades of running these:
- Do the gap analysis before you commit to an audit timeline, not after. The companies that struggle book the auditor first and discover their gaps with a deadline already bearing down.
- Engineer controls once, map them to many frameworks. If HIPAA is on your roadmap and ISO 27001 is behind it, build each control to satisfy both. Most organizations remediate the same control three times for three frameworks because nobody connected the dots.
- The report is the beginning, not the deliverable. A gap analysis that ends with a PDF and a handshake is worth very little. Compliance drifts the moment the assessor leaves — people change, systems change, evidence goes stale. The question to ask any partner isn’t “what will the report say?” but “who closes the gaps, and who keeps them closed?”
Our philosophy is simple: assess, engineer, validate, and sustain. Understand the current state, implement the right controls, validate that they work, then sustain them continuously — so compliance never becomes an annual scramble.
Your first gap analysis will probably humble you. Good. The companies that get certified — and stay certified — are the ones that wanted the truth early, while it was still cheap to fix.—
Peter Briel (Founder, CISM, CISA, HITRUST CCSFP) leads Privaxi, a cybersecurity and compliance firm that helps organizations achieve and sustain readiness across frameworks including HIPAA, HITRUST, CMMC, ISO 27001, and PCI-DSS through a combination of hands-on expertise and AI-enhanced tooling.