A compliance gap analysis compares what your organization does today with what a regulation, framework or contract requires, then lists every place the two don't match. The output is a documented inventory of gaps, each with an owner and a fix. You run one before an audit, a certification or a new customer contract, so the surprises surface on your schedule instead of an auditor's.
This guide explains what the analysis covers, how it differs from a risk assessment, how to run it in seven steps, and how to handle ISO 27001, SOC 2, HIPAA and PCI DSS. It also shows how to map overlapping frameworks so you don't fix the same problem three times.
TL;DR
- A compliance gap analysis measures your policies, controls and evidence against one named standard. A risk assessment asks what could go wrong. Most organizations need both.
- Define scope first: the framework and its version, the systems, the locations and the evidence period.
- Rate every requirement as met, partially met, not met or not yet assessed, and back each rating with evidence rather than a questionnaire answer.
- Turn findings into a gap register with an owner, a deadline and a priority for every item, then reassess after the fixes.
- If you face several frameworks, map them to one shared control set so each control is built and tested once.
Table of Contents
- What a compliance gap analysis is
- Common compliance gaps, with examples
- Gap analysis, risk assessment and audit: how they differ
- When to run one
- How to perform a compliance gap analysis: seven steps
- Framework-specific notes
- Mapping overlapping frameworks to shared controls
- Our perspective
- Get the gaps found and closed by one team
- FAQ
- Sources
What a compliance gap analysis is
The idea is simple. You take a target, such as a law, a standard or a customer's security addendum, and compare it with your current state: policies, technical controls, records and training. The gap is the difference.
US government cybersecurity guidance uses the same logic. In the CISA implementation guide for the NIST Cybersecurity Framework, a gap exists when a desired outcome isn't satisfied by current practices, or when those practices don't reach the degree your risk strategy requires. That second half matters. A control can exist and still be a gap if it is too weak, too informal or covers too little of the environment.
The result is not a pass or a fail. It is an inventory in which every requirement is met, partially met or not met, and some teams add a fourth status, not yet assessed, so nothing is silently skipped. A requirement can also be technically met but undocumented, which is still a gap, because an auditor can only accept what you can show.
Common compliance gaps, with examples
Gaps tend to cluster in the same places. Practical Law's guidance on common gaps in US information security compliance groups them into weak information security policies, gaps in technical and physical safeguards, and gaps in administrative protocols. It stresses the need for a comprehensive written information security program and regular self-assessments under laws such as GLBA, HIPAA and CCPA/CPRA.
In practice, the examples we see most often look like this:
- Policies that exist but are out of date. The access control policy names a system you retired two years ago.
- Missing or incomplete documentation. The control works, but there is no record of who approved the last change or reviewed the last access list.
- Untested incident response plans. The plan is written, yet nobody has run a tabletop exercise.
- Incomplete training records. Staff were trained, but you can't show who, when or on what.
- Unencrypted portable devices. Laptops or phones reach sensitive data without full-disk encryption.
- Weak access governance. A terminated employee's account stays active past the deadline in your own policy.
- Third-party blind spots. Vendors handle regulated data and there is no current agreement or review on file.
- Missing logging. Systems produce logs, but nobody reviews them and nothing shows that they were reviewed.
Technology environments add their own patterns. Teams that deploy automated assistants or other customer-facing software need the same discipline around access, change management and evidence, and a walkthrough of SOC 2 engineering controls shows how those controls turn into things an auditor can inspect.
Gap analysis, risk assessment and audit: how they differ
These three get mixed up constantly, and mixing them leads to the wrong work being done. Foley & Lardner describes the compliance gap analysis as the step that completes a risk assessment: the risk assessment identifies the risks, and the gap analysis checks whether your policies and internal controls address them.
CSO Online makes a related point: a gap analysis measures how well a company follows a specific set of controls tied to a framework such as ISO or NIST, while a risk assessment can be customized to look at any threat.
| Compliance gap analysis | Risk assessment | Internal audit | |
|---|---|---|---|
| Starting point | A specific standard, law or contract | The business or system | Your own documented system |
| Question it answers | Are the requirements met? | What can go wrong, how likely, how severe? | Do we follow what we wrote down? |
| Output | Gap inventory with status per requirement | Ranked risks | Findings on conformance |
| Best used | Before certification or an audit | Continuously, and after major change | On a regular cycle once a system exists |
The practical rule: run the risk assessment to learn what matters most, run the gap analysis to learn what the standard demands that you haven't done, and use audits to confirm the controls keep working afterwards.
When to run one
Three situations justify a gap analysis almost every time.
- Before a first certification or attestation. If you are heading toward SOC 2, ISO 27001 or a similar goal, the analysis shows how far you are and what the project will take. Our guide to running a SOC 2 gap analysis walks through that case.
- When a customer, regulator or insurer sets a new requirement. Contract security schedules, cyber insurance questionnaires and rules for defense contractors all arrive with specific control lists. Our pieces on cyber insurance requirements and CMMC 2.0 obligations for DoD contractors show what those lists contain.
- After a major change. CSO Online notes that new technologies, mergers, regulatory changes and AI adoption should each trigger a fresh assessment. A migration to a new cloud platform is the classic example, because controls that worked on premises may not translate.
If your program is mature and stable, a full gap analysis adds less than a targeted review of how well the controls perform. If you are early, it is the most useful document you can commission.
How to perform a compliance gap analysis: seven steps
Generic business guides describe gap analysis in four moves: define the current state, clarify your goals, identify the gaps and prepare an action plan. That works as a skeleton. For compliance work, expand it like this.
1. Set the scope
Write down the framework and its exact version, the business units, systems and locations in scope, and the evidence period you will examine. Record every exclusion with a reason. A vague scope is the most common reason a gap analysis has to be repeated.
2. Break the standard into requirements
Split the framework into control-level requirements you can test individually. "Manage access" is not testable. "Remove access for leavers within the period your policy states" is. For ISO 27001, remember that the Annex A controls are not a flat checklist, a point we cover in why Annex A's 93 controls aren't a checklist.
3. Collect operating evidence
Ask for artifacts, not opinions: configuration exports, access review records, training logs, ticket histories, signed policies, vendor agreements. Questionnaires tell you what people believe. Evidence tells you what is true. Controls that exist only on paper are the gaps that hurt in an audit. It also helps to know where that evidence lives. A software subscription audit makes it easier to find every tool that holds logs, records or approvals, and to retire the ones nobody owns.
4. Rate each requirement
Use four statuses and apply them consistently:
- Met: the control works and the evidence proves it.
- Partially met: the control exists but is incomplete, inconsistent or undocumented.
- Not met: no control, or one that doesn't address the requirement.
- Not yet assessed: you haven't had access to the evidence. Don't guess.
Also ask whether each control is formalized or lives in one person's head. A process that only one engineer understands is a gap even if it runs well today.
5. Build the gap register
For each gap, record the requirement, the evidence you found, what is missing, the risk it creates, and a named owner. This register is the deliverable. Everything else supports it.
6. Prioritize
CISA's guidance suggests ranking mitigation by legal and regulatory requirements, business objectives and the current risk environment. In practice, group related gaps into workstreams (for example identity, logging, vendor management, documentation) and order them by audit impact and effort. Quick wins, such as updating stale policies, go first because they clear noise from the register.
7. Plan, fix and reassess
Foreley & Lardner advises that once gaps are identified, you should develop an action plan with specific tasks, timelines, responsible parties and resource requirements. Then close the loop: after fixes land, retest the same requirements and update their status. A gap analysis that is never revisited is only a snapshot.
Framework-specific notes
ISO 27001 gap analysis
An ISO gap analysis compares your management system with the clause-by-clause requirements of the standard. It reviews documented information, processes and operating evidence, and it is diagnostic: it doesn't certify you, and a nonconformance is not a failure but a task. Keep it separate from an internal audit. The gap analysis asks whether you have a compliant system. The internal audit asks whether you follow it. For the sequence of work that follows, see our ISO 27001 implementation steps for US teams.
SOC 2 gap analysis
SOC 2 is built on criteria you scope yourself, so the first decision is which trust services categories apply. Evidence over time matters as much as design, which is why a readiness review before the audit window opens saves so much rework.
HIPAA gap analysis
For healthcare organizations and their vendors, typical findings include missing business associate agreements, no documented risk analysis, untested incident response, incomplete workforce training records and unencrypted portable devices. The cybersecurity side of connected equipment has its own requirements, covered in our medical device cybersecurity guide.
PCI DSS gap analysis
The PCI Security Standards Council describes compliance as three ongoing steps: assess, repair and report, in its PCI DSS quick reference guide. A PCI gap analysis is the assess step done with care: you identify which systems store, process or transmit cardholder data, test each applicable requirement, and fix what fails before you report. Always work from the current version of the standard published by the Council, and let your acquirer or card brand tell you which validation level applies to you.
Mapping overlapping frameworks to shared controls
If you answer to SOC 2, ISO 27001, HIPAA and a customer questionnaire, running four separate gap analyses wastes time. Most of these frameworks ask for the same things in different words: access control, change management, logging, incident response, vendor oversight, encryption, training.
The approach that works is a master control matrix:
- List your own controls once, each with one owner and one evidence source.
- Map each framework requirement to the control that satisfies it.
- Mark the relationships: one requirement to one control, one control satisfying many requirements, and requirements unique to a single framework.
- Collect evidence once and reuse it across frameworks wherever the wording allows.
- Handle the framework-specific extras separately, so they don't get lost inside the shared set.
Then run the gap analysis against the matrix instead of against each framework in turn. When a control fails, you see at once which frameworks it affects, and that tells you where to start.
Our perspective
Most gap analyses we see fail for the same reason: the findings land in a document and nobody owns the fix. The report is accurate, the register is tidy, and six months later the same items are still open because remediation sits with three different vendors who each handle one slice of the environment.
We built Nexus around that problem. Security monitoring, cloud management, network design, managed IT and compliance work sit under one provider, with one SLA and one point of accountability. When a gap analysis finds a missing log review or an unencrypted device fleet, the people who found it are the people who can fix it, because they already work in your environment.
Our approach is to treat the analysis as the start of a remediation plan, not a deliverable. Our methodology ties each finding to a control, an owner and a date, and our senior practitioners cover compliance for SOC 2, HIPAA, PCI-DSS and ISO 27001, so the shared-control mapping described above is something we can build with you instead of leaving you to assemble it alone.
We also price on a predictable flat monthly basis, so closing gaps doesn't turn into a series of surprise invoices.
Nick - Sr. Executive
Get the gaps found and closed by one team
Nexus offers compliance and risk services that include assessments for SOC 2, HIPAA, PCI-DSS and ISO 27001, alongside cybersecurity, cloud, network, managed IT and data protection under a single agreement. If you want a gap analysis that ends in fixes owned by the same team, see our services or start from the Nexus homepage.
We don't publish prices for these services, so talk to us about scope and we will put the terms in writing.
FAQ
What are the four steps of a gap analysis?
The general version is to define your current state, clarify your goals, identify the gaps and prepare an action plan. For compliance work, add explicit scoping up front and a reassessment step at the end. That is the seven-step process above.
What is a PCI gap analysis?
It is the assess stage of PCI DSS compliance. You find where cardholder data is stored, processed or transmitted, test the applicable requirements and list what fails. You then repair those items and report, following the three-step cycle the PCI Security Standards Council describes.
Is a security gap assessment the same as a compliance gap analysis?
They overlap heavily. A security gap assessment compares your operation with a security framework and lists what it takes to close the differences. A compliance gap analysis does the same against a specific law, standard or contract. The method is identical; the target differs.
How long should the results stay valid?
Until something material changes. New systems, a migration, a merger, a regulatory change or a new contract requirement should each prompt a reassessment. Between those events, retest the items you remediated so the register stays accurate.
Sources
- CISA: Commercial Facilities Sector Cybersecurity Framework Implementation Guidance
- Practical Law: Common Gaps in Information Security Compliance (US)
- Foley & Lardner: Five Compliance Best Practices for Conducting a Compliance Gap Analysis
- CSO Online: Beyond the checklist, from compliance frameworks to real-time risk assessments
- Investopedia: Gap Analysis
- PCI Security Standards Council: PCI DSS Quick Reference Guide