How to Run a NIS2 Gap Analysis: Who Should Lead It, What Tools You Need, and How Long It Takes

Most NIS2 gap analysis guides — including our own five-phase methodology breakdown — explain what a gap analysis measures: your current controls against the ten Article 21(2) risk-management measures, scored and prioritised into a remediation roadmap. That’s the right framework. It’s also not where most gap analyses actually stall.

They stall on logistics. Who owns the exercise when it touches HR, IT, legal, and the board at once? Do you need a consultant, or can a compliance officer run it with a spreadsheet? How many weeks does it realistically take once you account for people being on holiday, out sick, or simply slow to answer an email? This guide covers the part the methodology articles skip: how to actually get a NIS2 gap analysis done — who leads it, what tools you need, and how long to budget.

This guide assumes you already know your organisation falls under NIS2 as an essential or important entity. If you haven’t confirmed that yet, resolve scope first — running a gap analysis before you know your classification wastes the exercise.

Who Should Own Your NIS2 Gap Analysis

One person needs to be accountable for the whole exercise, even though no single department can complete it alone. Article 21(2) spans ten measure categories [3] — from cryptography to HR security to business continuity — and each one lives with a different team. Splitting ownership without a single accountable lead is the single most common reason gap analyses drag past their deadline: no one chases the slow contributors, and partial answers get logged as complete.

The table below reflects how this typically splits across roles — not a legal requirement, but a practical division of labour that keeps the exercise moving.

Role	Responsibility in the gap analysis	Typical time commitment
Compliance Officer / Project Lead	Owns the schedule, chases evidence, consolidates scoring, reports status	High — the one continuous role
CISO / IT Security Manager	Provides technical evidence for measures (e), (h), (i), (j) — systems, cryptography, access control, MFA	Medium — concentrated in 2–3 working sessions
HR / Operations	Supplies evidence for measure (i) HR security and (g) training records	Low — one interview plus document handover
Legal / Procurement	Supplies supplier contracts for measure (d) supply chain security	Low — document pull, one review call
Management Body / Board	Reviews and approves the finished assessment — required under Article 20(1)	Low — one sign-off session, but non-negotiable

Internal Team or External Consultant? How to Decide

Run it internally if you have someone who can dedicate 15–20% of their time for 6–8 weeks, existing documentation isn’t scattered across four systems, and this is your first pass rather than an audit-defence exercise. A compliance officer or IT manager with a structured template and two or three hours a week from each contributing department can complete a first gap analysis without outside help — the ten measures in Article 21(2) are a checklist, not a specialist discipline, for most SMEs.

Bring in a consultant when your entity operates across multiple jurisdictions with different national transposition details, when the board wants independent assurance rather than a self-graded report, or when your last attempt at self-assessment stalled because no one had the authority to pull evidence from other departments. Expect consultant-led engagements to run several times the cost of a template-based internal exercise once you include their day rate across the full evidence-review cycle — that premium buys independence and cross-jurisdiction experience, not a fundamentally different method. The measures being assessed are identical either way.

A hybrid model works for most mid-sized entities: run the internal exercise using a structured workbook, then pay a consultant for a half-day review of the finished scoring before it goes to the board. That catches self-assessment blind spots without paying for a full engagement.

What Tools You Actually Need

A spreadsheet with a fixed structure — one row per Article 21(2) sub-measure, columns for current-state evidence, gap severity, and remediation owner — is the minimum viable tool, and it’s sufficient for a first-pass analysis. What separates a usable gap analysis from a rushed one is whether the scoring is consistent across measures, which is where most ad-hoc spreadsheets fall down: one contributor scores on a 1–5 scale, another writes “mostly fine,” and the results can’t be compared or prioritised.

If you want a recognised external framework rather than building your own scoring logic, Ireland’s National Cyber Security Centre and Belgium’s Centre for Cybersecurity jointly maintain CyFun (Cyber Fundamentals) — a voluntary, NIST CSF-aligned framework that assigns organisations one of three assurance levels (Basic, Important, Essential) based on size, sector, and risk exposure [1]. CyFun itself isn’t proof of NIS2 compliance — that determination sits with your national competent authority — but it gives you a structured, externally recognised way to organise the same evidence a gap analysis needs, through either self-assessment or formal certification [1].

Whichever tool you use, evidence beats documentation. ENISA’s technical implementation guidance on NIS2 risk-management measures, published to support Commission Implementing Regulation (EU) 2024/2690, is explicit that entities need practical evidence — logs, configuration exports, signed policies — not just a policy document asserting a control exists [2]. Build your gap analysis template with an evidence column from the start; adding it retroactively means a second pass through every measure.

One operational detail derails more gap analyses than the scoring method itself: access control on the working file. A shared spreadsheet with no version history and open edit access for a dozen contributors reliably produces overwritten scores and lost evidence links. Use a single master file with locked scoring columns, or a workbook with built-in change tracking — whichever tool you pick, decide who can edit versus comment before the first contributor opens it, not after the first conflict.

How Long a NIS2 Gap Analysis Actually Takes

For a single-entity organisation with reasonably centralised IT, budget 6–8 weeks from kickoff to a board-ready report. That splits roughly into three blocks, and the middle one is where timelines actually slip.

Phase	Typical duration	What causes delay here
Scoping and kickoff	1 week	Confirming which entities/sites/systems are in scope
Evidence collection and scoring	3–5 weeks	Waiting on department heads; evidence scattered across systems with no single owner
Consolidation, prioritisation, board sign-off	1–2 weeks	Scheduling the board review slot — often the longest single wait in the whole project

In practice, the evidence-collection block is where a compliance officer spends most of their actual hours — not filling in the template, but chasing meeting slots with department heads who treat the request as low priority until a deadline is attached. Set a hard evidence-submission date in the kickoff email, not a vague “in the coming weeks,” and the collection phase compresses noticeably. Multi-entity groups, heavy OT/ICS estates, or organisations still consolidating IT asset inventories should budget toward 10–12 weeks — the measures don’t change, but the evidence trail is longer.

Before You Start: The Pre-Analysis Checklist

Four tasks, completed before the first evidence-collection meeting, save more time than any tool choice:

Task	Effort	Why it matters
Name a single accountable lead (not a committee)	Low	Prevents the ownership gap covered above
List every system, site, and legal entity in scope	Medium	Ambiguous scope is the top cause of rework after the fact
Pre-book a board review slot for 6–8 weeks out	Low	Board calendars fill up — booking late adds 2–3 weeks of pure waiting
Send a template and evidence list to each department in week 1	Medium	Departments that receive a vague ask deliver vague answers

Six Execution Mistakes That Stall Gap Analyses

The same failure patterns recur across organisations running their first NIS2 gap analysis:

• No single accountable owner. Splitting the exercise across departments without one person tracking overall progress means gaps in accountability mirror gaps in the assessment itself.
• Treating it as an IT-only project. Measures (c), (d), (g), and (i) touch business continuity, procurement, training, and HR — excluding those teams from the start guarantees a second round of evidence requests later.
• No evidence-submission deadline. Open-ended requests get open-ended responses. A dated deadline in the kickoff communication is the single highest-leverage change you can make to the timeline.
• Skipping the board until the report is “finished.” Article 20(1) requires the management body to approve the risk-management measures your gap analysis assesses — bringing the board in only at the end risks a rejected report and a second sign-off cycle.
• Inconsistent scoring across measures. Without a fixed scoring scale agreed before evidence collection starts, one contributor’s “partially met” is another’s “met,” and the prioritisation step becomes guesswork.
• Scoring against the directive text instead of the CIR detail. Article 21(2) states the ten measures at a high level; Commission Implementing Regulation (EU) 2024/2690 breaks several of them into specific technical sub-requirements. A gap analysis scored only against the directive’s summary language can mark a measure “met” that a CIR-literate auditor would still flag.

Board and Management Involvement: What Article 20 Liability Requires

Article 20(1) of the NIS2 Directive states that the management body of an essential or important entity must approve the cybersecurity risk-management measures the entity takes, oversee their implementation, and can be held liable for infringements of the Article 21 obligations [3]. That liability attaches to the management body regardless of who actually ran the gap analysis or which consultant wrote the report — delegation of the work is not delegation of the accountability.

Article 20(2) additionally requires management body members to undergo regular training, so the board’s involvement in a gap analysis is not a one-off approval signature — it’s part of an ongoing obligation to understand what they’re approving [3]. In practice, this means your gap analysis output needs to be board-legible: a scored, prioritised summary a non-technical director can review in one sitting, not a raw technical spreadsheet. Build the executive summary layer before the board meeting, not as an afterthought once someone asks for it.

Put the board sign-off on the calendar during the pre-analysis checklist stage, not after the evidence is consolidated. A board that receives the request cold, with no advance notice that a NIS2 sign-off is coming, will typically push the item to its next scheduled meeting — adding weeks to a project that was otherwise finished on time.

What Happens After the Gap Analysis

A completed gap analysis is an input, not a deliverable in itself. The output feeds three things: a prioritised remediation roadmap (our five-phase gap analysis methodology covers RAG scoring and roadmap sequencing in detail), an evidence repository you’ll need again for the next annual review, and the board briefing pack required for Article 20 sign-off. Treat the analysis as the first lap of a cycle you’ll repeat — most entities re-run a lighter version annually, or whenever a significant system, supplier, or entity structure changes.

Frequently Asked Questions

Can one person run a NIS2 gap analysis alone?
One person can lead and consolidate it, but they can’t generate the evidence alone — cryptography, HR security, and supply chain measures each need input from the team that actually holds that evidence. Budget for a lead plus short contributions from 3–5 other roles.

Do we need a consultant, or can we do this in-house?
Most single-entity organisations running a first gap analysis can do it in-house with a structured template and a dedicated lead. Bring in outside help for multi-jurisdiction entities, independent board assurance, or when a prior in-house attempt stalled from lack of internal authority to pull evidence.

How is a gap analysis different from a risk assessment?
A gap analysis compares your current controls against what Article 21 requires and produces a scored list of shortfalls. A risk assessment goes further, evaluating the likelihood and impact of specific threats materialising against those same systems. Most organisations run the gap analysis first, then use its findings as an input to the risk assessment.

How long before our first NIS2 audit should we run one?
As early as possible — a gap analysis only creates value if there’s time left to remediate what it finds. Running it 6–8 weeks before an anticipated review leaves no room for the fixes it identifies; most entities run their first pass as soon as scope is confirmed, then repeat annually.

Should we use a spreadsheet template or dedicated software?
A well-structured spreadsheet is enough for a first gap analysis at most single-entity organisations — the value is in consistent scoring and a clear evidence trail, not the software itself. Dedicated compliance platforms earn their cost once you’re managing multiple entities, running the exercise annually, or need continuous rather than point-in-time scoring.

What happens if the gap analysis finds we’re not compliant?
Finding gaps is the expected outcome, not a failure — that’s what the exercise is for. Article 21(4) requires entities to take corrective measures once shortfalls are identified [3], so the gap analysis and the remediation roadmap that follows it are two stages of the same obligation, not a pass/fail test.

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.

Sources

1. CyFun (Cyber Fundamentals) Framework — NCSC Ireland
2. ENISA Technical Implementation Guidance on NIS2 Cybersecurity Risk Management Measures, v1.0 (June 2025) — ENISA
3. Directive (EU) 2022/2555 (NIS2 Directive), Articles 20 and 21 — EUR-Lex