NIS2 Compliance Beyond Checkboxes: A 2026 Implementation Playbook

The Network and Information Security Directive 2 (NIS2) entered force across the European Union on 17 January 2024, and Member States had until 17 October 2024 to transpose it into national law. Eighteen months later, a quiet truth has emerged: most organisations that fall under NIS2 have a paper programme, not a defensible one. They have a control catalog, a risk register, an incident response policy. And almost no operational evidence that any of it works under pressure.

This is the playbook we use at Pelican Tech to take a mid-market essential or important entity from "we have policies" to a programme that survives a competent regulator's review. It is opinionated. It is not a control-by-control reading of Article 21. And it is shaped by the kinds of failure modes we see in the field, not the ones the directive's authors imagined.

The shift NIS2 actually demands

NIS2's predecessor (NIS1) was a national-critical-infrastructure regime dressed up as a directive. NIS2 is something different: a horizontal cyber regulation applied to roughly 160,000 entities across 18 sectors, with personal liability for management bodies, 24/72-hour incident notification windows, and supply-chain accountability that explicitly reaches down to the entity's "critical" suppliers.

The practical implication is one most boards still underestimate. The directive is not graded on whether you have a control. It is graded on whether you can demonstrate the control was operating during the period being investigated. That distinction, between attestation and evidence, is where the majority of programmes will fail their first real test.

If you remember nothing else from this piece, remember this: NIS2 enforcement will be evidence-driven, retrospectively. A regulator does not arrive in an emergency to ask if your asset inventory is up to date. They arrive after an incident and ask for the asset inventory you had on the day the breach started.

Where mid-market teams stall

We have shepherded ~30 NIS2 programmes through national authorities in Israel, Germany, the Netherlands, and Ireland. The same five gaps appear with depressing regularity:

1. Asset inventory exists, but is not the asset inventory the response team uses. The CMDB lives in IT. The detection team works from a SIEM ruleset that names hosts differently. The cloud team has its own tag schema. When a breach happens, three teams open three different spreadsheets. NIS2 Article 21(2)(a) requires "policies on risk analysis and information system security." But the operational version of that policy is a single source of truth about what you own, what it does, and who owns its security posture today.

2. Incident response runbooks have never been timed. A 24-hour early-warning notification window sounds generous until you measure how long it takes your on-call to: identify that an event is reportable, determine which national CSIRT receives it, find the contact channel, get sign-off from legal, and submit. The first time this exercise is run end-to-end, it almost always exceeds 24 hours. Often by days.

3. Supplier risk lists are wishful, not operational. Article 21(2)(d) explicitly requires "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers." Most lists we are handed contain every vendor finance has paid in the last three years. The list a regulator will accept is much shorter and much sharper: which suppliers can stop our service, leak our data, or be used as a pivot, and what specific contractual or technical mitigation is in place for each.

4. Encryption inventory is unowned. Article 21(2)(h) requires "policies and procedures regarding the use of cryptography and, where appropriate, encryption." Almost no organisation we audit can answer two basic questions: which keys protect which data, and what happens when one rotates. Cryptography is treated as a series of one-off project decisions instead of a governed register.

5. Management-body engagement is performative. The directive imposes personal liability on senior managers, including potential individual fines and bans from management positions. Boards we work with often respond by demanding more reports. The reports they ask for are almost never the ones that would change a decision. Useful board reporting under NIS2 should answer three questions only: What changed in our risk picture this quarter? What did we decide to do about it? What evidence will we have if asked?

The 90-day programme

If you are starting now, the first 90 days are not about achieving compliance. They are about building the evidence apparatus that compliance can later sit on top of. Trying to do these in parallel almost always fails.

Days 0–30: Establish the system of record

Pick one tool, anything from a curated spreadsheet to a fully governed CMDB, and make it the canonical answer to "what do we own, what does it do, who is accountable for its security posture today?" This is the foundation; nothing else matters until it exists. Most organisations are tempted to perfect this step before moving on. Don't. A 70%-correct inventory that is used daily is worth more than a 100%-correct one that is updated quarterly.

Specific outputs by day 30:

• A single asset register with: owner, criticality tier, regulatory scope (in/out of NIS2), supporting suppliers
• A single cryptographic register linked to the asset register: which key protects which asset, where it lives, who rotates it
• A single supplier register, scored by impact (not by spend)

Days 30–60: Time the response

Run two unannounced tabletops in this window. Not full red-team exercises. Those come later. Tabletops with a clock, a note-taker, and the actual on-call rotation. The artefact you are building is a measured response timeline: from event detected → team paged → triage decision → containment → 24-hour notification → 72-hour follow-up.

What you are looking for is the gap between your written runbook and the time it actually takes. The first run is almost always 3–5x slower than the runbook claims. The second run, assuming you fix the obvious issues, is usually 1.5–2x slower. That second number is the honest baseline you take to the board and to the regulator.

Days 60–90: Make the board reporting load-bearing

Replace existing security board reports with a single quarterly artefact that answers, for the period being reported:

• Which top-five risks materially changed (up, down, new, retired)?
• Which decisions did the management body take in response, and on what evidence base?
• What controls did we test, and what did testing reveal?
• What incidents or near-misses occurred, with timeline and lessons?

If a board member asks a question your report cannot answer, that is the next quarter's improvement target. This is the document a regulator will eventually ask to see, so make sure it does not embarrass you.

The audit no one prepares for

Beyond programme design, there is a specific exercise we recommend every entity run before the first regulator engagement: a one-day evidence retrieval test. Pick a date eighteen months in the past. Ask the security organisation to assemble, in a single working day, the operational evidence that would show: (a) which controls were operating on that date, (b) what changes had been deployed in the previous 30 days, (c) what incidents were open, and (d) which suppliers had access to systems in scope.

Most organisations cannot do this in a week, let alone a day. The gap between what your tooling stores and what your retrospective story requires is the most under-appreciated risk in the entire directive, and the one that turns an investigation into an enforcement action.

Where this connects to our practice

We see NIS2 not as a compliance project but as a forcing function for the kind of operational discipline mature security organisations need anyway. Pelican Tech's Risk Management & Threat Analysis practice focuses specifically on building the evidence apparatus described above: asset and cryptography registers, response timing measurement, board-grade quarterly reporting, and the supplier risk methodology regulators will accept. We also work alongside our ISO 27001 / ISMS team for entities that need the underlying management system, and with our SIEM/SOAR specialists when detection and response timing is the binding constraint.

If you are eighteen months into your NIS2 programme and uncertain whether what you have would survive contact with a competent national authority, that is the right time to talk to us, well before an incident makes the question urgent.