IT Security Frameworks for NIS2: What ISO 27001, NIST CSF, and ISO 27005 Each Prove — and What None of Them Proves

No operative article of NIS2 names an IT security framework. The ISO/IEC 27000 series is mentioned exactly once in the whole Directive — in Recital 79, which is interpretive and creates no obligation — and NIST is not mentioned at all [1]. That is deliberate: Article 25 obliges Member States to encourage standards “without imposing or discriminating in favour of the use of a particular type of technology”. There is no approved list to comply with.

So “which framework should we adopt?” is the wrong question. The three most-compared options answer three different questions, and a supervisor asking for evidence will want all three answered. This guide shows what each one can actually prove, what none of them proves, and — using the European Union Agency for Cybersecurity’s own mapping data — which layer your organisation is missing.

What NIS2 actually says about security standards

In plain terms: standards are an input the law tells you to consider, not a rule the law tells you to follow. Nothing in NIS2 makes any framework compulsory, and nothing in it makes any framework sufficient.

Two provisions carry the whole question. The first is the second subparagraph of Article 21(1), which sets the standard of care for risk-management measures [1]:

“Taking into account the state-of-the-art and, where applicable, relevant European and international standards, as well as the cost of implementation, the measures referred to in the first subparagraph shall ensure a level of security of network and information systems appropriate to the risks posed.”

Standards sit behind a double qualifier — “taking into account” and “where applicable”. The binding object is the level of security, not the standard. The second provision, Article 25(1), explains why no EU-level list will ever appear:

“In order to promote the convergent implementation of Article 21(1) and (2), Member States shall, without imposing or discriminating in favour of the use of a particular type of technology, encourage the use of European and international standards and technical specifications relevant to the security of network and information systems.” [1]

Article 25(2) then hands the technical work to ENISA, which is why the agency’s Technical Implementation Guidance exists at all. That document is careful about its own status: it is “written in a technology-neutral and standards-neutral way”, it “does not aim to establish a new standard or to duplicate existing ones”, and it states plainly that “the choice of which standards and good practices to apply should be made by the entity” [3].

The consequence practitioners miss: because no standard is mandated, a gap between your programme and ISO 27001 is not, by itself, a legal breach. What creates exposure is an undocumented deviation — a control you decided not to implement, with no recorded risk basis for the decision. Article 21(1) makes proportionality assessable (“the degree of the entity’s exposure to risks, the entity’s size and the likelihood of occurrence of incidents and their severity”), and an assessment you cannot produce is an assessment a supervisor will treat as absent. The framework is optional. The reasoning is not.

The three frameworks are not alternatives — they are layers

In plain terms: ISO 27001 defines the machine, ISO 27005 tells you how to run its most important part, and NIST CSF 2.0 tells you what the machine is supposed to produce. Comparing them like competing products is a category error, which is why “which is better” articles never reach a usable answer.

ISO/IEC 27001:2022 is a requirements standard — in ISO’s own words, it “defines requirements an ISMS must meet” [6]. That is what makes it certifiable: an accredited body can audit conformity against its management-system clauses and issue a certificate.

ISO/IEC 27005:2022 is not certifiable and does not try to be. ISO describes it as guidance that “provides guidance on managing information security risks to support the implementation of an information security management system (ISMS) based on ISO/IEC 27001” [5]. It fills in the method behind ISO 27001’s risk clauses — 6.1.2 and 6.1.3, both of which ENISA’s mapping cites directly, with clause 6.1.3 named in the guidance text as “information security risk treatment” [3].

NIST CSF 2.0, published 26 February 2024, is a third thing again. Its own abstract states that it “offers a taxonomy of high-level cybersecurity outcomes” and that “the CSF does not prescribe how outcomes should be achieved” [2]. The Core is explicit on the point: “These outcomes are not a checklist of actions to perform; specific actions taken to achieve an outcome will vary by organization and use case” [2]. It has six Functions — GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND, RECOVER — resolving into 22 Categories and 106 Subcategories, plus Tiers that “characterize the rigor of an organization’s cybersecurity risk governance and management practices” and Profiles that record a Current and a Target state [2].

Framework	What it actually is	Certifiable?	Evidence it produces	What it cannot evidence under NIS2
ISO/IEC 27001:2022	Requirements for an information security management system	Yes — accredited third-party certification	Statement of Applicability, risk treatment plan, internal audit results, management review minutes	That the ISMS covers the whole regulated entity; incident reporting, registration and management-body duties
NIST CSF 2.0	Outcome taxonomy across six Functions; explicitly not a checklist	No — there is no CSF certificate	Current and Target Profiles, Tier rating, prioritised outcome gap list	An auditable management system; any legally recognised conformity statement
ISO/IEC 27005:2022	Guidance on the risk assessment and treatment method	No — guidance, not requirements	Risk criteria, documented assessment method, treatment decisions and rationale	Controls, governance structures or any operational security outcome

Read down the last column and the layering becomes obvious. Each framework’s blind spot is another one’s core. That is also why the two comparisons worth running are pairwise and directional, which we cover separately in the function-by-function NIS2 vs NIST CSF 2.0 gap map and in the analysis of where ISO 27005 stops short of Article 21(2)(a).

What the EU’s own mapping data shows: 118 against 285

In plain terms: ENISA has already mapped every technical requirement to both ISO 27001 and NIST CSF 2.0. The pattern in that mapping tells you something the vendor comparisons do not — and ENISA attaches a warning that invalidates the “80% overlap” figure repeated across this topic.

ENISA’s Technical Implementation Guidance maps each requirement of Commission Implementing Regulation (EU) 2024/2690 to five standards — ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIST Cybersecurity Framework 2.0, ETSI EN 319 401 V3.1.1 and CEN/TS 18026:2024 — and to national frameworks including Belgium’s CyFun, Finland’s Kybermittari and Spain’s ENS [3].

We parsed the published mapping table (version 1.2, September 2025) and counted the references ourselves [4]. Across its 49 requirement points:

• Not one cell is blank. Every requirement point carries at least one ISO 27001 reference and at least one NIST CSF 2.0 reference.
• ENISA needed 118 ISO/IEC 27001:2022 references but 285 NIST CSF 2.0 references to cover the same 49 points — roughly 2.4 times as many.
• The CSF references touch 89 of the framework’s 106 Subcategories.
• The ISO column is not a control list. It mixes Annex A controls with management-system clauses — 5.2, 5.3, 6.1.2, 6.1.3, 7.x, 8.x, 9.1 to 9.3 and 10.1 all appear.

The asymmetry is a granularity effect, not a coverage verdict. CSF Subcategories are narrow outcome statements, so several are needed to express one regulatory requirement; ISO clauses and Annex A controls are broader, so one often absorbs the whole point. Where the two diverge most, the divergence is informative:

CIR requirement point	ISO 27001 refs	CSF 2.0 refs	What the spread indicates
3.5 Incident response	1 (A.5.26)	14	ISO treats incident response as a single control; CSF decomposes it into managed, analysed and mitigated outcomes
6.10 Vulnerability handling and disclosure	1	13	One ISO control stands in for thirteen distinct CSF outcomes — the widest structural gap in the table after incident response
12.4 Asset inventory	1	10	CSF’s IDENTIFY Function is far more granular than ISO’s asset controls
12.2 Handling of assets	4	1	One of the few points where ISO carries more anchors than CSF
11.7 Multi-factor authentication	1	1	Thinnest in both frameworks — the Article 21(2)(j) measure neither standard elaborates

Now the warning. ENISA states, in the same document [3]:

“The mapping should not be interpreted as a measure of equivalency among different standards or frameworks. It simply refers to relevant requirements in these standards or frameworks without assessing whether these fully cover the requirements of the regulation.”

Full nominal coverage in the table, explicitly disclaimed as non-equivalence in the text. Any article converting a crosswalk into a percentage — “ISO 27001 covers 80% of NIS2” and its variants — is converting a reference index into a compliance claim the index’s own author refuses to make. What ENISA does endorse is the opposite of picking one: understanding these relationships “may help relevant entities use and integrate multiple standards or frameworks efficiently, to maintain compliance, reduce duplication and streamline audits” [3].

One scope guard before you reuse those numbers. CIR 2024/2690 binds eleven categories of digital providers — DNS services, TLD registries, cloud, data centres, CDNs, managed service providers, managed security service providers, online marketplaces, online search engines, social networking platforms and trust service providers [8]. Other sectors follow national transposition of Article 21, though in practice the implementing regulation is widely treated as interpretive guidance for them too. The mapping is still the best available picture of how EU institutions relate these frameworks to the law.

What each framework proves to a supervisor — and what none of them proves

In plain terms: a certificate is a useful exhibit. It is not a defence, and at least one national regulator has said so in writing.

Germany’s Federal Office for Information Security has published a dedicated page on ISO/IEC 27001 in the NIS2/BSIG context. Its conclusion is unambiguous: an ISO/IEC 27001 certification “can answer the underlying requirements only incompletely or not at all” and “cannot be regarded as proof of NIS2 conformity” [7]. The BSI names the specific gaps behind that conclusion. Three of them generalise well beyond Germany:

1. Scope is self-selected. Entities set their own ISMS scope, which “can be limited to individual business areas or sites”, whereas the statutory duty attaches to the entire regulated operation [7]. A certificate covering one data centre says nothing about the other four.
2. Risk acceptance and transfer are permitted by the standard. ISO 27001 allows risk acceptance and risk transfer as legitimate treatment options; the German transposition excludes blanket risk transfer or general risk acceptance [7]. Insurance is not a control.
3. Statutory duties sit outside the standard. Incident reporting, entity registration, and management-body accountability and training are legal obligations with no counterpart in ISO 27001 [7].

None of the three frameworks addresses reporting, registration or personal accountability, because none of them was written against a directive. What NIS2 does grant certification is narrower and easier to overstate. Under Article 32(7), when a competent authority takes an enforcement measure it shall “as a minimum, take due account of” eight listed factors, one of which is “(g) any adherence to approved codes of conduct or approved certification mechanisms” [1]. Read the scope precisely: it applies when an authority is already taking an enforcement measure under Article 32(4) or (5). It can shape what happens next. It cannot prevent the finding that triggered it.

Which layer are you missing?

In plain terms: pick your next move from where you already are, not from a feature comparison. The cheapest useful step is almost always the missing layer, not a second framework at a layer you already occupy.

Where you are now	Layer you are missing	Next move	Effort
ISO 27001 certified	Regulatory coverage, not security coverage	Compare the certified ISMS scope statement against the whole regulated entity, then map the CIR points to your Statement of Applicability and record a reason for every exclusion	Medium
Running NIST CSF 2.0, no certification	An auditable management system and a documented risk method	Build the ISMS shell around your existing Target Profile — the Profile already contains most of the risk-treatment content clause 6.1.3 expects	High
ISO 27001 plus CSF, informal risk process	Defensible risk criteria	Adopt ISO 27005’s risk criteria approach so acceptance decisions have a recorded basis rather than a signature	Low
No framework at all	All three layers	Start with the risk method. Article 21(2)(a) is the gateway measure, and every later measure inherits its proportionality reasoning	Medium

The same table reads differently by role, and the differences matter more than the framework choice:

• CISO or IT security manager. Your constraint is the granularity gap in the ENISA table. If your programme is ISO-anchored, incident response, vulnerability handling and asset inventory are where a single ISO control is standing in for a dozen CSF outcomes — audit those three first, using the CSF Subcategories as the checklist ISO does not give you.
• Compliance officer. Your constraint is scope and documentation, not controls. Reconcile the certified ISMS scope against the registered entity, and make sure every deviation from a standard has a recorded risk decision behind it. That reconciliation is the single most common finding waiting to happen.
• Board member or managing director. Do not accept a certificate as a status report. Ask two questions: does the certified scope cover the whole regulated entity, and which statutory duties — reporting, registration, oversight — sit outside it entirely? Those duties are the ones that attach to you personally.

Whichever layer you start with, the destination is the same: a documented set of measures that maps to the ten Article 21(2) measures with a recorded reason behind each decision. If you are weighing certification specifically, our NIS2 vs ISO 27001 comparison works through the alignment clause by clause.

Frequently asked questions

Does NIS2 require ISO 27001 certification?
No. Article 21(1) requires standards to be taken into account “where applicable”, and Article 25(1) bars Member States from imposing a particular technology [1]. The BSI states directly that a certificate “cannot be regarded as proof of NIS2 conformity” [7].

Is NIST CSF 2.0 acceptable to EU regulators?
ENISA maps every implementing-regulation requirement to CSF 2.0, so the framework is recognised as a legitimate reference point [3]. It is not certifiable, so it cannot by itself produce the conformity evidence a supervisor may ask for — it produces a prioritised gap list, which is a different kind of exhibit.

Do I need ISO 27005 if I already have ISO 27001?
Not as a requirement. ISO 27005 is guidance supporting the ISMS risk clauses [5]. It earns its place when your risk decisions are contested — it supplies the criteria and method that turn “the board accepted this risk” into a defensible record.

Is there a NIS2 certificate?
There is no EU certification scheme for organisations. Article 24(1) lets Member States require entities to use ICT products, services and processes certified under European cybersecurity certification schemes — the object is procurement. Article 24(2) empowers the Commission to specify categories of entities required to use certified products, by delegated act; no such act has been adopted [1].

Which framework is cheapest to start with?
NIST CSF 2.0, because it is free to download and requires no auditor. That is a real advantage for producing a first gap picture. It is not an advantage at the point a competent authority asks for evidence of implementation, which is the moment the certifiable layer starts to matter.

The decision, restated

NIS2 declines to name a framework and forbids Member States from imposing one, so no framework can be right or wrong in the abstract. What is assessable is whether your measures reach an appropriate level of security and whether you can show the reasoning behind them. ISO 27001 gives you an auditable system and a certificate that counts as a mitigating factor after the fact. NIST CSF 2.0 gives you the finest-grained outcome checklist available and, per ENISA’s own table, the more detailed anchor for 41 of the 49 requirement points. ISO 27005 gives you the method that makes both defensible.

Start from the layer you lack. Then document the deviations — because under Article 21, the deviation is never the problem. The missing reason is.

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. Directive (EU) 2022/2555 (NIS2), Articles 21, 24, 25 and 32 — EUR-Lex, official English text (linked above).
2. NIST, The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29, 26 February 2024 (linked above).
3. ENISA, NIS2 Technical Implementation Guidance, version 1.0, June 2025 (linked above).
4. ENISA, Technical Implementation Guidance Mapping table, version 1.2, September 2025 — reference counts in this article were derived by parsing that file (linked above).
5. ISO/IEC 27005:2022, Information security, cybersecurity and privacy protection — Guidance on managing information security risks, iso.org/standard/80585.html.
6. ISO/IEC 27001:2022, Information security, cybersecurity and privacy protection — Information security management systems — Requirements, iso.org/standard/82875.html.
7. BSI, ISO/IEC 27001 im Kontext NIS-2/BSIG (#nis2know) (linked above).
8. Commission Implementing Regulation (EU) 2024/2690 — EUR-Lex (linked above).
9. NIST, CSF 2.0 Informative References — including the ISO/IEC 27001:2022-to-CSF v2.0 mapping in the OLIR catalog.