How to Run a Framework Gap Analysis (Step by Step)

A gap analysis answers one question: if we already meet framework A, what do we still need for framework B? Here is a method that turns the answer into a plan rather than a spreadsheet nobody opens.

Every second framework starts with the same question: how much of this do we already have? A gap analysis answers it. Done badly, it produces a spreadsheet that says "partially compliant" against everything and is never opened again. Done well, it produces a costed list of tasks with owners. Here is the method we'd use.

Step 1: fix the scope and the direction

A gap analysis has a direction: have a framework (or your current controls), need another. Write both down, with versions, and the organisational scope: which entity, services and locations. Gap analyses go wrong most often because the two scopes don't match, for example an ISO certificate covering one product line compared against a NIS2 obligation for the whole entity.

Step 2: generate the requirement-by-requirement comparison

Start from a mapping, not a blank sheet. ControlMapping's gap analysis lists every requirement of the framework you need, each with its match in the one you have:

mapped: a published crosswalk or our editorial judgement links it to something you have.
loosely related: it only shares an outcome with something you have. Treat it as probably new work.
no mapping in our data: likely new work, unless coverage of that framework is partial.

For example, going from ISO 27001 to NIS2:

Of the 49 NIS2 requirement points, 49 (100%) map to something in ISO 27001, 0 are only loosely related and 0 have no mapping in our data. Open the gap report →

Step 3: validate the matches against reality

A mapping says two requirements are related. It doesn't say your implementation meets both. For each mapped row, ask:

Do we actually do the thing we mapped to? A mapping to ISO A.8.8 helps only if your vulnerability management works.
Is the new requirement more specific? Deadlines, frequencies, named techniques and scope often differ.
Is the link editorial? Check the reason shown and decide whether you agree.

Mark each row met, partly met or not met. Be honest: a generous gap analysis just moves the discovery to the audit.

Photograph of an office whiteboard covered in columns of blank coloured sticky notes with a marker on the tray — A gap analysis is only useful once it becomes a list of owned tasks.

Step 4: export it as a tracker

Press e in the gap view (or the Export CSV button) to download the result. Every row comes with the requirement, its section, the match, the basis and the reason, plus four blank columns ready for the work: owner, implementation status, evidence reference and notes. Open it in your spreadsheet or import it into your GRC tool.

Step 5: turn rows into work

Group by owner and theme, not by requirement number: "supplier contracts" is one task that may close six rows.
Estimate each group and sequence it: governance and policy changes usually unblock technical work.
Fill the evidence column as you go, so the tracker becomes your audit file.
Re-run the analysis when either framework changes; ours updates when the data does.

Key takeaways

Fix the scope and direction first: have A, need B, with versions.
Start from a mapping, then validate every match against what you actually do.
Export the result as a tracker with owners, status and evidence columns, and turn rows into grouped work.

Common mistakes

Comparing against a superseded version (CSF 1.1, ISO 27001:2013, PCI DSS v3.2.1).
Treating "loosely related" as covered.
Ignoring requirements outside the mapping entirely: legal obligations such as incident reporting deadlines often sit outside any control catalogue.

For worked examples, see ISO 27001 vs NIS2 point by point and the comparisons, each of which is a ready-made two-way gap analysis.

Questions

What is a compliance gap analysis?

A requirement-by-requirement comparison of what you already do (or the framework you already meet) against the requirements of a framework you need, identifying what is covered, partly covered and missing.

How long does a gap analysis take?

The mapping can be produced in minutes with a tool like ControlMapping's gap analysis. Validating it against your actual controls and evidence is the real work, typically days to a few weeks depending on scope.

What does 'loosely related' mean in a gap analysis?

The two requirements only share a NIST CSF 2.0 outcome; nobody has mapped them to each other. Treat them as a lead to check, and usually as new work, not as coverage.

Data as of 2026-10-27: numbers in this post are computed from the current crosswalk and update when it changes. Crosswalk a published crosswalk (NIST, ENISA, CIS, PCI SSC) makes the link · Editorial ControlMapping's judgement where no crosswalk exists; the reason is shown · only shares a CSF 2.0 outcome: worth checking, not a mapping · No mapping in our data nothing mapped in our data; often new work, but check the coverage notes. Not compliance advice.

How to run a gap analysis between two frameworks, and turn it into a tracker