Gap analysis

A gap analysis has three inputs: a requirement baseline, an assessment scale and evidence of current practice. The baseline must be decomposed to testable statements; NIS2 Art. 21(2) lists ten measure areas, (a) risk analysis and security policies through (j) MFA and secured communications, but each needs to be broken down, for example using Commission Implementing Regulation (EU) 2024/2690 for the digital-infrastructure and digital-service entities it covers, or national guidance, before it can be scored. ISO/IEC 27001:2022 is usually assessed clause by clause for 4-10 plus the 93 Annex A controls; NIST CSF 2.0 (February 2024) formalises the approach as a comparison between a Current Profile and a Target Profile across its six functions, now including Govern.

Scales range from binary (met/not met) through three-level (met, partial, missing) to maturity models on a 0-5 scale inspired by CMMI, where for example 0 means non-existent, 1 ad hoc, 2 repeatable, 3 defined, 4 managed and measured, and 5 optimised. The choice matters: binary scales hide progress, while maturity scales invite inflated self-scoring unless each level has explicit evidence criteria. A robust assessment records, per requirement, the current state, the evidence reviewed, the target state, the gap description, a risk rating of the gap and an estimated effort, so that prioritisation can be done on risk reduction per unit of effort rather than on perceived urgency.

Evidence depth distinguishes a gap analysis from an audit. Gap analyses are usually interview- and document-based and performed by the organisation or a consultant as advisory work, without formal sampling or independence requirements. That makes them fast, but also prone to "paper compliance": a policy exists, so the requirement is scored as met although nobody follows it. Spot checks of records, such as a sample of user access reviews or restore-test logs, sharply improve reliability. It also differs from a risk assessment: a gap analysis measures distance to a requirement set, whereas a risk assessment measures exposure to threats; a gap on a low-risk requirement may rightly be accepted, and a fully compliant organisation can still carry significant risk.

The output feeds planning: in ISO 27001 terms it informs 6.1.3 risk treatment and 6.2 objectives, and in practice it is converted into a compliance roadmap. Re-running the same assessment at fixed intervals, typically annually or before a certification or supervisory audit, turns it into a measurement of progress in the Check phase of PDCA. Scoping errors are the commonest failure: assessing only the IT department when NIS2 or ISO 27001 scope covers the whole organisation, or omitting outsourced services that still fall under the entity's responsibility.