Your NIS2 Gap Analysis in 5 Phases: Article 21 Control Inventory to RAG-Scored Remediation Roadmap

The NIS2 Directive lists ten security measures under Article 21. Knowing that list is not the same as knowing where your organisation stands against it. A gap analysis converts the directive’s requirements into a measured, auditable distance between your current controls and what the law requires — and it does this before a competent authority, an auditor, or a security incident forces the question.

This guide presents a five-phase method structured around Article 21 of Directive (EU) 2022/2555, the technical sub-requirements of Commission Implementing Regulation (EU) 2024/2690, and the three-layer evidence framework recommended in ENISA’s Technical Implementation Guidance (2025). The output is a RAG-scored control inventory and a prioritised remediation roadmap — the two documents every NIS2 compliance project needs to get started.

What a NIS2 Gap Analysis Actually Tests

Article 21(1) requires measures that are “appropriate and proportionate” to the risks faced. That phrase defines the standard: a gap analysis cannot simply check whether a policy document exists. It must assess whether your current controls are calibrated to your specific risk environment. A formal policy that nobody follows, a penetration test that has never been run, or an incident response plan with no mapping to NIS2’s 24-hour early warning threshold — each is a gap regardless of whether the document is in the folder.

A rigorous assessment works at three layers:

• Layer 1 — The directive: Article 21(2)(a)–(j) defines ten mandatory measure categories. Your gap analysis must cover all ten regardless of entity size or classification. For a full breakdown of what each measure requires, see the NIS2 requirements guide.
• Layer 2 — The CIR Annex: Commission Implementing Regulation (EU) 2024/2690 specifies the technical and methodological requirements beneath each Article 21 header. For the entity types it covers, these are binding. For others, they are the baseline against which proportionality will be judged by national authorities.
• Layer 3 — Your controls: What actually exists today, supported by evidence. ENISA’s Technical Implementation Guidance (2025) defines three evidence categories per requirement: policy or procedure documentation, implementation evidence (configurations, records, certificates), and effectiveness evidence (test results, audit findings, monitoring records). A gap exists whenever any category is absent or insufficient.

Phase 1: Scope Confirmation — Which Entities, Sites, and Systems

Effort: Low (1–3 days) | Owner: Compliance Officer / Legal

Rushing past scope confirmation is the most common cause of an incomplete gap analysis — one that creates false assurance precisely when it matters most. Phase 1 produces a written scope statement before any control is assessed.

Entity scope

For a standalone organisation, the question is binary: does the entity fall under NIS2 scope? For corporate groups with subsidiaries across EU member states, each qualifying subsidiary carries its own NIS2 obligations — separate registration requirements, potentially different competent authorities, and different national transposition rules. A consolidated group assessment may be defensible for some elements, but it requires explicit justification and must flag jurisdictional differences where they exist.

Use this decision logic for each legal entity:

1. Is the entity’s primary activity in a sector listed in NIS2 Annex I (essential entities) or Annex II (important entities)?
2. Does the entity meet the size threshold: 50 or more employees, or annual turnover or balance sheet total exceeding €10 million? Or is it critical regardless of size?
3. Has the entity registered with its competent national authority under Article 27?

Document which entities are in scope, which are excluded, and the reasoning for each exclusion.

System and service scope

Article 21 applies to the network and information systems your entity uses for its operations or service provision. The assessment boundary should include production systems directly associated with the NIS2-registered activity, critical supply chain dependencies whose compromise would impact your covered services, operational technology (OT) where it supports critical service delivery, and cloud or managed services consumed in delivering the regulated service.

Back-office systems — HR, finance, internal procurement — that do not directly support a covered service may be excluded. Document the exclusion and the rationale; auditors will ask.

Phase 1 output: a scope statement naming entities in scope, the services covered, system boundaries, and documented exclusions with reasons. One page is sufficient — the point is the written record.

Phase 2: Article 21 Measures Inventory — What Controls Currently Exist

Effort: Medium to High (5–15 days depending on documentation maturity) | Owner: CISO / IT Security Manager

Phase 2 is a structured evidence-gathering exercise. For each of the ten Article 21(2) measures, document what currently exists. Resist the urge to score gaps at this stage — that is Phase 4. The goal here is an accurate picture, not a verdict.

For each measure, gather three categories of evidence: the governing policy or procedure (document title, version, approval date, owner); implementation evidence (configurations, screenshots, audit logs, certificates); and effectiveness evidence (test results, audit findings, incident records, KPI reports). Missing any one category is a partial gap at minimum.

Article 21(2)	Measure	Key current-state questions
(a)	Risk analysis & information security policies	Is a risk assessment methodology documented? When was the risk register last updated? Is the information security policy board-approved with distribution evidence?
(b)	Incident handling	Does an incident response plan exist? Has it been tested? Is incident severity mapped to NIS2 reporting timelines (24h early warning, 72h notification, 1-month final report)?
(c)	Business continuity, backup & disaster recovery	Is a Business Impact Analysis documented? Are RTO/RPO targets set and tested? Are backups immutable and stored off-site or air-gapped?
(d)	Supply chain security	Is there a supplier register with risk classification? Are cybersecurity clauses in supplier contracts? When was the last supplier security assessment completed?
(e)	Secure acquisition, development & maintenance	Is a vulnerability management programme in place with defined remediation SLAs? Is a Coordinated Vulnerability Disclosure (CVD) policy published?
(f)	Effectiveness assessment of cybersecurity measures	Is there an internal audit programme covering all ten measures? Is penetration testing conducted at least annually for critical systems?
(g)	Cyber hygiene & cybersecurity training	Are mandatory awareness training completion rates tracked by department? Have board members received cybersecurity training as required under Article 20?
(h)	Cryptography & encryption policies	Is a cryptographic policy documenting approved algorithms and minimum key lengths in place? Is TLS 1.2 or higher enforced on all services? Are encryption keys managed separately from the data they protect?
(i)	HR security, access control & asset management	Is a Joiner-Mover-Leaver (JML) process operational with timely access revocation? Are quarterly access reviews conducted for critical systems? Is a complete and up-to-date asset inventory maintained?
(j)	MFA & secure communications	Is MFA enforced for remote access, cloud services, and privileged accounts? Are sensitive internal communications end-to-end encrypted? Does an out-of-band emergency channel exist, independent of primary IT?

Common inventory errors: accepting policy documents without checking implementation evidence; relying on vendor-supplied certificates without verifying their scope; treating “we have a firewall” as equivalent to a documented network security architecture; counting shared or generic accounts as controlled access with proper accountability.

Phase 3: CIR Annex Mapping — Does Each Control Satisfy the Technical Requirement?

Effort: Medium (3–7 days) | Owner: CISO / IT Security Manager

Commission Implementing Regulation (EU) 2024/2690, adopted on 17 October 2024, specifies technical and methodological requirements for each Article 21(2) measure. A gap analysis that stops at the directive layer will miss real deficiencies — the CIR Annex sits between the ten Article 21 headers and your controls, and it adds specificity that a generic “we have an IRP” answer cannot satisfy.

Does the CIR apply to your entity?

CIR 2024/2690 applies to a defined list of entity types: DNS service providers, top-level domain (TLD) registries, cloud computing service providers, data centre service providers, content delivery network (CDN) providers, managed service providers (MSPs), managed security service providers (MSSPs), online marketplaces, online search engines, and social networking platforms. If your entity is not in one of these categories, the CIR requirements are not directly binding — but ENISA and national authorities treat the Annex as a proportionality benchmark for any essential or important entity when assessing whether measures are “appropriate.”

How the CIR Annex layers onto Article 21

For each Article 21 measure, the Annex specifies concrete sub-requirements. Two examples show the gap-widening effect in practice.

Article 21(2)(b) incident handling: beyond requiring an incident response plan, the CIR Annex requires documented incident classification criteria explicitly linked to NIS2 reporting thresholds, and annual tabletop or simulation exercises with documented outputs. An organisation with an incident response plan but no classification matrix mapped to the 24-hour early warning threshold has a CIR-layer gap — even if the plan looks complete at the directive level.

Article 21(2)(j) MFA: the Annex specifies phishing-resistant MFA methods (FIDO2 hardware keys, authenticator apps with number matching) as the preferred standard and permits SMS-based OTP only where phishing-resistant alternatives are not feasible — with the feasibility assessment documented. An organisation using SMS OTP for privileged account access without that documented justification has a measurable gap.

The “appropriate, applicable, feasible” exclusion clause

The CIR explicitly permits entities to exclude specific Annex requirements they consider not appropriate, not applicable, or not feasible — but the exclusion must be documented “in a comprehensible manner.” Undocumented exclusions are treated as gaps during supervisory reviews. Every exclusion your organisation applies should be logged in a dedicated CIR Exclusions sheet in your gap analysis template, with the rationale and the name of the person who documented it.

Phase 3 output: a control mapping table showing each applicable CIR Annex requirement, the corresponding Article 21 measure, whether your controls satisfy it fully, partially, or not at all, and any documented exclusions.

Phase 4: Gap Scoring — RAG per Measure

Effort: Low to Medium (2–4 days) | Owner: CISO / Compliance Officer

A binary pass/fail obscures the information needed for remediation planning. A five-point maturity scale adds calibration effort that rarely improves the output. Red/Amber/Green (RAG) scoring produces auditable, action-ready results with criteria that a compliance officer can defend to management and regulators.

RAG criteria for NIS2 gap scoring

Score	Criterion
Green	The requirement is met. Policy exists, implementation is confirmed, and effectiveness evidence — a test result, audit finding, or monitoring record — confirms the control is operating as designed. No material gap.
Amber	The requirement is partially met. Policy or procedure exists but implementation is incomplete; or implementation exists but has not been tested or independently verified; or the control satisfies the directive layer but misses specific CIR Annex sub-requirements. Gap exists but poses manageable risk.
Red	The requirement is not met. No policy, no implementation, or both are absent; or an existing control has been tested and found ineffective; or a CIR-layer sub-requirement is unaddressed with no documented exclusion rationale. Gap poses material compliance risk.

Apply RAG at two levels: measure level (one score per Article 21(2) header — the management dashboard view) and sub-requirement level for any Amber or Red measures, identifying exactly which CIR Annex item is the source. Measure-level scores give the board a status overview; sub-requirement scores drive the remediation plan.

Gap scorecard example

Art. 21 Measure	Current Control	RAG	Gap	Evidence Status
(b) Incident handling	IRP documented; no NIS2 classification matrix	Amber	Incident severity not mapped to 24h/72h/1-month reporting thresholds	Policy: YES · Impl: Partial · Effect: NO
(j) MFA & secure comms	SMS OTP deployed for all users including privileged accounts	Amber	SMS OTP on privileged accounts; no feasibility exclusion documented	Policy: Partial · Impl: YES · Effect: NO
(i) HR security & access control	No formal JML process; access revocation handled ad hoc	Red	Orphaned accounts active after offboarding; no quarterly access reviews	Policy: NO · Impl: NO · Effect: NO

Phase 5: Remediation Roadmap — Prioritised by Risk

Effort: Low to Medium (2–5 days) | Owner: CISO + Compliance Officer + relevant business owners

The gap scorecard tells you what is wrong. The remediation roadmap tells you what to fix first. Prioritisation combines two dimensions: risk severity — what the gap exposes you to if exploited or identified by a regulator — and remediation effort — the time, cost, and organisational complexity to close it.

Risk × Effort priority matrix

	Low Effort	High Effort
High Risk (Red)	Quick wins — address within 30 days	Phase 1 roadmap (0–3 months): plan and resource immediately
Medium Risk (Amber)	Phase 2 roadmap (3–6 months)	Phase 3 roadmap (6–9 months)
Low Risk	Schedule in next annual review cycle	Deprioritise unless required for audit

Red gaps with low remediation effort — drafting a cryptographic policy, publishing a CVD disclosure page, completing the competent authority registration, documenting CIR exclusion rationales — are quick wins that reduce regulatory exposure within days. Address these in the first month before touching anything that requires infrastructure investment.

Red gaps requiring structural work — deploying privileged access management (PAM), implementing organisation-wide MFA enforcement, standing up 24/7 detection capability — belong in the first three-month window of the roadmap, with resource allocation and delivery milestones assigned before work begins.

Role-responsibility assignment

Gap type	Primary owner	Escalation to
Policy and documentation gaps (cryptographic policy, IRP, CVD policy, information security policy)	CISO / Compliance Officer	General Counsel for legal review
Technical implementation gaps (MFA enforcement, PAM, encryption configuration)	IT Operations / Security Engineering	CISO for scope and budget
Governance and training gaps (board training, management risk register approval)	Compliance Officer	Board / C-Suite
Supply chain gaps (contract cybersecurity clauses, supplier assessments)	Procurement / Legal	CISO for technical requirements

Closing documentation gaps immediately

Several of the most consistently Red-scored measures require documentation before they require technology: a cryptographic policy, an incident classification procedure mapped to Article 23 thresholds, a CVD page, an information security policy structured around Article 21. These gaps can be closed in hours with a pre-built, NIS2-specific template rather than weeks of drafting from scratch. The NIS2 Quick-Start Bundle provides structured documentation covering the four most commonly Red-scored Article 21 measures — ready to customise and obtain sign-off without starting from a blank document.

The Gap Analysis Template: Column Structure

A gap analysis is only reusable and auditable if documented consistently. The following spreadsheet structure captures what a competent authority or internal auditor will expect to see.

Sheet 1 — Entity & Scope

• Entity name, legal form, NIS2 classification (essential / important)
• Sector and sub-sector (Annex I / Annex II reference)
• Assessment date, assessor, next scheduled review date
• Systems and services in scope; systems excluded with documented rationale
• CIR 2024/2690 applicability: yes / no / partial (with entity type noted)

Sheet 2 — Gap Assessment

Columns: Article 21 Reference | Measure Name | CIR Annex Requirement (where applicable) | Requirement Summary | Current Control Description | Policy Evidence (ref) | Implementation Evidence (ref) | Effectiveness Evidence (ref) | RAG Score | Gap Description | Priority Band | Gap Owner | Remediation Action | Target Evidence | Target Date | Status

Sheet 3 — Remediation Roadmap

Columns: Gap ID | Article 21 Reference | RAG | Priority Band | Gap Owner | Remediation Action | Effort Estimate (person-days) | Indicative Cost Band | Target Evidence | Target Date | Progress Notes | Closed Date

Sheet 4 — CIR Exclusions Log

Columns: CIR Annex Requirement | Exclusion Category (not appropriate / not applicable / not feasible) | Reasoning | Documented By | Date

After the Gap Analysis: What Comes Next

A completed gap analysis is the input to three downstream compliance activities.

Risk assessment: the gaps in your scorecard become inputs to a NIS2 risk assessment, which quantifies the probability and impact of each gap being exploited and updates the organisation’s risk register. Gap analysis and risk assessment are separate activities: gap analysis identifies what is missing; risk assessment determines how much that matters given your threat environment.

Compliance tracking: use a structured NIS2 compliance checklist to track remediation progress against each Article 21 measure and capture evidence artefacts as gaps close. The checklist becomes your running audit log.

Evidence repository: as each remediation action closes a gap, log the target evidence in a centralised location. ENISA recommends maintaining policy documentation, implementation records, and effectiveness evidence (test results, audit findings, monitoring reports) for each measure — this repository is your audit pack when a competent authority requests documentation.

Treat the gap analysis as a living document. Schedule a reassessment after any significant infrastructure change, following a major security incident, when a new critical supplier joins your supply chain, and as a minimum annually.

Frequently Asked Questions

How long does a NIS2 gap analysis take?

For a mid-sized organisation with partial documentation already in place, the five phases typically take four to eight weeks. An organisation with an existing ISO 27001 ISMS can often complete Phases 1–4 in two to three weeks, since a significant portion of the evidence base already exists. Organisations with minimal documentation should budget six to ten weeks, with the bulk of time in Phase 2 evidence gathering.

What is the difference between a NIS2 gap analysis and a risk assessment?

A gap analysis answers: “Do our current controls meet what Article 21 requires?” A risk assessment answers: “What is the probability and impact of each identified gap being exploited?” Both are required. The gap analysis typically comes first, because its outputs — the RAG scorecard and the list of unmet requirements — become the primary inputs to the risk assessment. You cannot meaningfully quantify risk from controls you have not yet inventoried.

Does ISO 27001 certification close my NIS2 gaps?

ISO 27001 certification demonstrates a functioning ISMS and there is substantial overlap with Article 21 measures — ENISA estimates 70–80% of ISO 27001 controls map to NIS2 obligations. However, certification does not automatically satisfy NIS2. Gaps specific to NIS2 include: incident reporting timelines mapped to Article 23 thresholds (24h/72h/1-month), supply chain security requirements under Article 21(2)(d), explicit board-level cybersecurity training under Article 20, and registration with the relevant national authority. A gap analysis using the ISO 27001 control set as a baseline still needs to verify these NIS2-specific requirements explicitly.

Do I need an external consultant to conduct a NIS2 gap analysis?

For essential entities or organisations with complex multi-site scope, external assurance adds credibility — particularly if the gap analysis will be shared with a competent authority or used to justify a compliance timeline to the board. For important entities with experienced internal compliance or security teams, an internally led gap analysis using a structured template is a practical and proportionate starting point. Pre-built gap analysis templates reduce the time to a defensible first output from weeks to days.

Sources

• Directive (EU) 2022/2555 (NIS2 Directive), Article 21 — EUR-Lex
• Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 — EUR-Lex
• ENISA Technical Implementation Guidance on NIS2 Cybersecurity Risk Management Measures, v1.0 (June 2025) — ENISA

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.