Gap analysis is the most basic exercise in compliance, and yet the most misunderstood.
There are compliance vendors who will sell you a lot of different checklist reports in the name of gap analysis. You will be handed a 47-page document that listed 200 controls and cost the company $15,000.
But there would be no explanation of how the controls were tested or whether they were tested at all.
A gap analysis is simple. It is a structured evaluation of where your current security controls stand against the requirements of a specific framework or standard.
It is a stepwise process that gives you a good roadmap for compliance, finding the gap between what controls and processes you need and what you don’t have.
Gap analysis is supposed to be the first process in your compliance journey. Once you find the things missing in your system, a risk assessment will tell you which to prioritize.
But, as it turns out, sometimes we confuse gap analysis with risk assessment. You have to understand that the difference in the terminologies matters because organizations that conflate the two tend to spend money on compliance documentation while leaving their actual security posture unchanged.
We are talking about gap analysis today because it remains a misunderstood exercise, and what better way to start than dispelling the confusion between the terms that we use interchangeably with gap analysis.
What Is the Difference Between Gap Analysis, Risk Assessment, & Compliance Assessment?
I have seen the three terms, gap analysis, risk assessment, and compliance assessment, being used interchangeably by SMBs in various conversations. They may seem similar, but, functionally, they are different things with different costs attached.
A gap analysis maps your existing controls against a specific framework. They can be HIPAA Security Rule, SOC 2, ISO 27001, CMMC, or NIST CSF, depending on whether you are working in the healthcare or manufacturing sector.
A gap analysis tells you where you fall short of the standard. It is not, by itself, a risk assessment.
So, what is a risk assessment (or risk analysis, as HIPAA calls it)? It is a process that evaluates the likelihood and potential impact of threats to your systems and data.
Under the HIPAA Security Rule, a risk analysis is not an option but a requirement. Even though both involve reviewing your controls, a risk assessment is more about probabilities, and not synonymous with gap analysis.
Meanwhile, a compliance assessment typically refers to an audit review against a regulatory standard, often conducted by a third party.
For ISO 27001, that’s a Stage 1 and Stage 2 audit by an accredited certification body. For CMMC Level 2 contractors, it’s a formal assessment by a C3PAO (Certified Third-Party Assessment Organization).
The gap analysis comes before compliance assessment. It’s the diagnostic that tells you whether you’re ready for the exam, and what to study before you sit down.
Why does the distinction matter in practice? Because getting it wrong changes the rating on a finding, and that debate can derail an entire engagement.
We had a situation with a healthcare client where our pentest found a JSON response reflecting back a list of usernames. They were not anything exploitable such as names or PHI.
Accordingly, during our assessment, we scored it low severity as that’s where it landed on the CVSS calculator, which measures exploitability, not likelihood. The client pushed back hard. Their position: the likelihood of this being targeted is high and therefore critical.
Both positions were technically correct. But they were measuring different things. VAPT severity is calculated on exploitability: what an attacker can actually do with a finding, right now.
But risk assessment severity is calculated on the likelihood of what could happen over time under realistic threat conditions. They are different metrics that produce different scores.
Neither is wrong, but treating them as equivalent gives you a rating that means nothing in either context.
The confusion cost time and trust on both sides. It’s the kind of thing a brief terminology clarification at the start of an engagement prevents.
Healthcare organizations especially run into this. Buyers searching for HIPAA guidance will use ‘gap analysis,’ ‘risk analysis,’ ‘risk assessment,’ and ‘compliance assessment’ in the same session, often meaning the same thing.
The practical answer: a gap analysis is what you do first, before any formal audit or assessment, to understand where you stand and what needs to change.
How Does KLEAP Run a Security Gap Analysis Through Its Concierge Approach?
Every engagement starts with a scoping conversation, not a questionnaire. Before we look at a single control, we need to understand what we’re protecting, who has access to it, and where it lives. That conversation shapes everything that follows.
Scoping: What We Ask Before We Start
We’re standard-agnostic going in. The client tells us what framework they’re targeting, and we build the checklist from there. We already have these prepared for the frameworks we work in regularly, but if a client comes to us with something newer or more specific, we build it from the standard itself.
The scoping questions focus on the data environment before the controls: What systems touch sensitive data? Where does ePHI, PII, or CUI flow? Which vendors, cloud platforms, or SaaS tools are part of that flow? Which business units are in scope, and which aren’t?
For healthcare clients, that conversation always includes BAAs. The questions are usually about who has them, who’s missing one, and whether the agreements in place actually reflect the data-sharing relationships that exist in practice. For manufacturers pursuing CMMC, it starts with the CUI boundary.
Discovery: Weekly Calls, Segment by Segment
Once scoping is complete, we work through the standard section by section, on weekly calls with the client team.
We take each requirement and convert it from a standard statement into a direct question: how are you doing this? What’s documented? What’s not? Who owns it?
We record both the current practice and the documentation that validates it for every line item in the standard.
The answers tell us two things simultaneously: what the control state actually is, and what evidence exists to prove it. A policy that says ‘all privileged access requires MFA’ is only meaningful if someone can prove it is being enforced.
This segment-by-segment cadence continues until we’ve worked through the entire scope of the assessment. For complex frameworks like ISO 27001 or CMMC, that can take several weeks.
The Maturity Rating: A Scale That Means Something
As discovery progresses, we assign a maturity rating to each control area. We use a five-level model:
- Level 1- Initial / Ad Hoc: At this stage, nothing is formally documented. Controls may exist in practice, but they’re entirely informal and inconsistent.
- Level 2 – Repeatable: We look for something basic in place. Maybe a verbal procedure, an informal policy, or something written on a shared drive. But it hasn’t been formally approved by senior management and isn’t consistently enforced.
- Level 3 – Defined: Here, governance is established. Policies and procedures are documented, approved, and operating. Systems are working as designed. This is the target level for most SMBs, the sweet spot where a compliance audit becomes survivable.
- Level 4 – Managed: At this level, your performance is actively measured. KPIs and KRIs are set, monitored, and used to drive improvement. Controls aren’t just operating, but they are evaluated.
- Level 5 – Optimized: Continuous improvement is embedded in strategy. Leadership actively uses security data to make decisions. This level takes years to reach and is the exception, not the norm.
Most organizations we engage are operating somewhere between Level 1 and Level 2 across different control domains. This we know from the compliance gap analysis we perform.
The remediation roadmap shows the organization how to reach Level 3. Because that’s the baseline where compliance programs become defensible.
What We Actually Find: Documentation and Process Gaps
The most common assumption clients bring into a gap analysis is that their problem is technical such as missing tools, unpatched systems, and unencrypted data.
While those gaps exist, in most SMB environments, the problem is deeper.
Roughly 30 to 40 percent of organizations we work with don’t have cross-functional governance in place at all. No IT steering committee or formal meetings where security and compliance issues get escalated cross-departmentally. Teams operate in silos, making decisions independently, with no shared record of what was decided or why.
That’s not a policy gap, but a process gap. And documentation can’t fix a process that doesn’t exist.
We’ve built governance structures from scratch for clients, defined who sits on the IT committee, what they discuss, what metrics they track, and how decisions get documented. Because without that foundation, the policies we write have no operational ground to stand on.
The other pattern we see consistently are templatized policies.
Compliance automation platforms make it easy to download a generic information security policy, enter your company name, and upload it as evidence. An auditor will see through this immediately.
A templated policy has no relationship to what your organization actually does. Rather, it describes a hypothetical company, not yours. When an auditor asks about a control and the policy doesn’t match the process, that’s a finding.
We write policies from scratch, built on what the client actually does, so the document reflects operational reality rather than a vendor’s generic baseline.
The Output: Maturity Rating, Roadmap, and Evidence Register
The deliverable is a prioritized finding register: each gap documented with the specific requirement it maps to, the current maturity rating, the evidence we reviewed, and the recommended remediation steps.
Alongside that is a phased roadmap sequenced to reach Level 3, with effort estimates and ownership assignments.
The report is written for both the IT team and executive leadership. Technical findings are translated into business risk language, remediation steps are specific enough to act on, and implementation work starts after the assessment is complete.
What a Gap Analysis Actually Finds: An Anonymized Example
In 2024, a healthtech platform serving mid-size physician groups engaged KLEAP ahead of a SOC 2 Type II audit. They had been using a compliance automation platform for eight months and believed they were close to audit-ready. Their readiness score was in the mid-80s.
The gap analysis found a different picture.
The automation platform was measuring policy acknowledgment and control documentation, not its control effectiveness. Four of the most significant findings had nothing to do with what their dashboard was tracking:
- MFA was there but there were also active accounts belonging to former employees.
- Their BAAs covered major cloud infrastructure providers, except a SaaS analytics vendor processing de-identified patient data had no BAA in place.
- Penetration testing was listed as completed in the prior calendar year, but it was for a legacy application that had since been retired.
- Encryption was documented as implemented at rest and in transit. And yet data was being transmitted over HTTP, instead of its secure version HTTPS.
The fifth finding was the one nobody expected.
The organization had no functioning IT governance structure. No documented meeting cadence where security issues were escalated cross-departmentally. The security team and the clinical operations team were making decisions independently, with no shared record of what had been decided or why.
Several controls existed in practice, but there was no evidence trail to prove it, because no one had ever been asked to produce one.
That’s a governance gap, not a documentation gap. And it’s the kind of finding that doesn’t appear in any compliance automation dashboard, because no platform is asking whether your org chart has the right people talking to each other.
The automation platform told them they were 84% ready. The gap analysis told them what the remaining 16% actually looked like. And probably why it mattered more than the 84%.
The remediation timeline was eight weeks for the critical findings. The governance structure took longer as it required building the committee, defining its scope, and running two documented quarterly cycles before there was enough evidence to satisfy an auditor.
The organization completed its SOC 2 Type II audit six months later with no material findings. The audit firm noted that the organization had “well-documented evidence of proactive control testing.”
That’s what a gap analysis is for.
What Does the Gap Analysis for HIPAA, ISO 27001, CMMC, and NIST CSF Look Like?
Each framework has a different scope, different audit mechanisms, and different failure modes. Here’s what a compliance gap analysis actually looks like inside each one.
HIPAA Gap Analysis
HIPAA has no official certification. There is no auditor who will issue a certificate declaring your organization ‘HIPAA certified.’
What exists is a compliance program that either holds up under OCR scrutiny or doesn’t. The difference between those two outcomes usually starts with whether a proper gap analysis was ever conducted.
The HIPAA Security Rule’s required risk analysis mandates that covered entities and business associates identify threats and vulnerabilities to ePHI and assess the likelihood and impact of those risks. A gap analysis maps your current technical, administrative, and physical safeguards against the Security Rule’s required and addressable specifications, giving you a foundation for that risk analysis.
Most common HIPAA gap analysis finds incomplete asset inventories (ePHIs in systems that weren’t scoped), BAAs missing or outdated, absence of formal access management reviews, and encryption that exists on paper but isn’t enforced across all data pathways.
The 2025 HIPAA Security Rule updates are making several previously addressable specifications mandatory, including MFA, encryption at rest and in transit, and annual audits.
ISO 27001 Gap Analysis
ISO 27001 is a certification, issued by an accredited certification body after a Stage 1 (documentation review) and Stage 2 (on-site or remote audit) assessment. The 2022 revision restructured Annex A from 114 controls across 14 domains into 93 controls across four themes: Organizational, People, Physical, and Technological.
A gap analysis against ISO 27001:2022 tells you how far you are from Stage 1 readiness, and what needs to be in place before you engage a certification body.
Organizations still working in ISO 27001:2013 need gap analyses to re-map the numbering changes in ISO 27001:2022 since several controls were consolidated, expanded, or added, including controls for threat intelligence, cloud security, and data masking.
ISO 27001 gap analysis programs find security policies that exist but haven’t been reviewed in over a year, supplier relationships that haven’t been assessed for security risk, and risk treatment plans that describe controls at too high a level to be auditable. Auditors want to see evidence of implementation, not declarations of intent.
CMMC Gap Analysis
If you handle Controlled Unclassified Information (CUI) for the Department of Defense at CMMC Level 2, you will need a C3PAO (Certified Third-Party Assessment Organization) to conduct a formal assessment before contract award.
The CMMC gap analysis is the step that determines whether you’re ready for that assessment or how far away you are.
CMMC Level 2 requires compliance with all 110 practices in NIST SP 800-171. The most dangerous gap in manufacturing environments isn’t a missing technical control, but the documentation gap.
Other than common CMMC Level 2 gaps include CUI present in systems not included in the System Security Plan (SSP), MFA not enforced for all accounts accessing CUI, and incident response plans exist but haven’t been tested.
CMMC implementation timelines are now live. If your organization is pursuing or maintaining DoD contracts, the gap analysis is now a prerequisite.
NIST CSF Gap Analysis
The NIST Cybersecurity Framework 2.0, updated in 2024, added a sixth function (Govern) to the original five (Identify, Protect, Detect, Respond, Recover).
It’s now the most broadly applicable voluntary framework available, and many organizations use it as a baseline gap analysis tool even when a different regulatory standard governs their compliance obligations.
The NIST CSF’s Target Profile approach formalizes what a gap analysis does: document where you are, define where you need to be, analyze the distance between them.
It maps cleanly onto HIPAA, ISO 27001, and CMMC requirements, which makes it useful as a unifying structure for organizations navigating multiple compliance obligations simultaneously.
For organizations that don’t yet have a mandatory framework, a NIST CSF gap analysis is often the right starting point as it creates a shared vocabulary for security posture across technical and non-technical stakeholders.
The Gap Analysis Is the Starting Line, Not the Finish Line
The most underserved part of any gap analysis conversation is what happens after the report is delivered.
Most vendors treat the gap analysis as a deliverable. Find the gaps, document them as a PDF, and close the engagement. The organization is left with a list of things to fix and no structured process for fixing them.
That’s where remediation tracking comes in. Each finding in a gap analysis needs an owner, a timeline, and a mechanism for verifying that the remediation actually worked. Without that, findings get triaged by what can be assigned resources, not by which gaps carry the most risk.
Meanwhile, the high-severity items that require policy changes or vendor negotiations get deprioritized. The low-effort wins get checked off. Six months later, the organization is in roughly the same position it was in when the gap analysis was completed.
A gap analysis that produces a PDF and nothing else has a 90-day shelf life. A gap analysis that feeds into an active remediation program stays relevant until your security posture actually changes.
KLEAP’s concierge model is built around what happens after the gaps are found. We maintain an evidence engine, a living record of control status, remediation progress, and supporting documentation, that keeps your program audit-ready on an ongoing basis rather than scrambling before each assessment cycle.
We track remediation against the original findings, verify that implemented controls actually work, and maintain the evidence trail that auditors and compliance assessors will ask for.
When a new regulation changes what’s required, as is the case with 2025 HIPAA Security Rule updates, we map against your existing control inventory and identify what needs to change.
That’s the difference between a compliance check and a compliance program.
How Can You Tell Where Your Security Program Actually Stands?
Most organizations engaging KLEAP for a gap analysis don’t know exactly what they need.
They know they have an upcoming audit, a new compliance requirement, or a leadership directive to get the program in shape. What they need first is clarity about where they actually are.
That’s what a gap analysis is for. Not a score or a list of controls. It is a clear, prioritized picture of your current security posture against the standard that applies to your business, with a concrete path forward.
If you’re in healthcare or healthtech, the HIPAA and SOC 2 angles on our healthcare cybersecurity page are a good place to start. If you’re a manufacturer navigating CMMC, our compliance team has worked with defense contractors at multiple CMMC levels across the manufacturing sector.
If you’d like to talk through what a gap analysis engagement looks like for your organization, you can reach out to KLEAP. We give no forms or automated sequences. It starts with a conversation with someone who has done this before.
