Teams operating across the EU and US frequently end up running two parallel compliance programmes: one shaped by NIS2, another shaped by NIST’s Cybersecurity Framework. They cover much of the same ground, yet because one is a legal directive and the other a voluntary control framework, they rarely line up cleanly. The goal of a good mapping is to make them reinforce one another.
Different instruments, overlapping intent
NIS2 is a directive: it states obligations for essential and important entities — risk management measures, incident reporting timelines, governance accountability, supply-chain security. It tells you what must be true, and leaves substantial room for how you achieve it.
NIST CSF 2.0 is a framework: it organises cybersecurity outcomes into functions — Govern, Identify, Protect, Detect, Respond, Recover — and decomposes them into categories and subcategories. It tells you how to structure your controls to achieve outcomes, without mandating anything.
The implication for mapping is important: you are not matching a rule to a rule. You are connecting a legal obligation to the set of control outcomes that, taken together, demonstrate the obligation is met.
Where the bridges naturally form
A few of the strongest correspondences we see in practice:
-
Governance and accountability. NIS2’s emphasis on management-body responsibility maps closely onto the Govern function introduced in CSF 2.0. CSF 2.0’s elevation of governance to a top-level function makes this bridge far cleaner than it was under CSF 1.1.
-
Risk management measures. NIS2’s baseline measures correspond to a spread across Identify and Protect — asset management, risk assessment, access control, and supply-chain risk in particular.
-
Incident handling and reporting. NIS2’s reporting timelines are an obligation with no direct equivalent in CSF, but the underlying capability maps to Detect and Respond. The timeline itself is a procedural requirement layered on top of the technical capability.
The trap: one-to-one matching
The most common mistake is trying to force a one-to-one mapping. A single NIS2 obligation usually touches several CSF subcategories, and a single CSF subcategory often supports more than one obligation. Treating the relationship as many-to-many is not sloppiness — it reflects how the instruments actually work.
This is exactly where a graph model earns its keep. Representing obligations, requirements and control outcomes as linked nodes lets you ask questions a spreadsheet cannot: which CSF subcategories, if implemented, would satisfy this NIS2 obligation? Which obligations remain unsupported by any implemented control? The second question is your gap analysis, expressed structurally.
Keep the obligation as the anchor
When the mapping gets messy — and it will — the discipline that keeps it honest is anchoring to the obligation, not the control. Controls come and go as your architecture changes; the obligation is stable. If every control in your estate traces back to a specific legal requirement, you can re-platform, re-tool and reorganise without losing the thread that connects your security posture to what the law actually demands.
This article is general information, not legal advice. Framework structures evolve; always check against the current published versions.