How to run a gap analysis that produces a real plan

A gap analysis compares what a framework requires against what you actually do, and produces the list of differences. It is the first activity in every compliance programme, the basis of every cost estimate, and the exercise most often undermined by optimism.

Before you start

• Fix the scope. Which entities, systems and locations. A gap analysis against an undefined scope produces an unusable result.
• Pick the framework version. Controls change between revisions.
• Decide the scoring scale and write down what each level means, before scoring anything.
• Identify who can answer. The person who operates the control, not the manager who believes it happens.

A scoring scale that works

Four levels is enough, and the definitions matter more than the labels:

• Not implemented - no meaningful activity.
• Partially implemented - happens sometimes, inconsistently, or only in part of scope.
• Implemented, not evidenced - it genuinely happens, but produces no record. This level is the most useful thing on the scale.
• Implemented and evidenced - operates and produces dated records you could hand an auditor.

Separating "implemented" from "evidenced" changes the plan entirely. Those two states need completely different remediation - one needs engineering, the other needs a report or a log export. Collapsing them hides the cheapest wins you have.

Scoring honestly

Self-assessment drifts optimistic, predictably. Counter it:

• Ask for evidence, not opinion. "Show me the last one" rather than "do you do this?"
• Sample. If access reviews are claimed quarterly, ask for all four from last year.
• Ask the operator, not the owner. The gap between what a manager believes and what happens is the thing you are measuring.
• Score against your whole scope. A control working in one team and not another is partial, not implemented.
• Default to the lower score when uncertain. Discovering a gap now is cheap; discovering it during fieldwork is not.

What to record per gap

• The requirement, referenced precisely.
• Current state, in one sentence.
• The gap - what is missing.
• Effort estimate, roughly banded.
• Dependency - what must happen first.
• Owner - the function that will close it.
• Risk if left open, which drives sequencing.

Without effort and dependency, the output is a list rather than a plan - and cannot be sequenced or costed.

Turning gaps into a sequence

Do not work through the framework in numerical order. Sequence by:

1. Foundations first. Asset inventory, identity, and the risk assessment unblock many other controls. Nothing downstream is solid without them.
2. Highest risk next - regardless of how tedious.
3. Cheap wins in parallel - especially "implemented, not evidenced" items, which are often a scheduled export away.
4. Long-lead items started early even if they finish late: penetration tests, evidence that accumulates over time, anything needing procurement.

That last point is the one teams miss. Evidence history cannot be compressed, so anything requiring months of records must start on day one whatever its risk ranking.

Common mistakes

• Scoring from documentation alone - a policy proves intent, not operation.
• Treating it as a one-off. Re-run it periodically; it is your progress measure.
• No effort estimates, so nobody can plan or fund it.
• Skipping "not applicable" justifications, which you will need for the SoA anyway.
• Presenting a flat list to leadership instead of a sequenced plan with a timeline.

Key takeaways

• Fix scope and scoring definitions before assessing anything.
• Separate "implemented" from "evidenced" - they need different fixes.
• Ask the operator and sample the evidence; do not accept opinion.
• Sequence by foundations, risk and lead time - not control number.