NIS2 vs ISO 27001: what an ISMS does not cover
The question arrives in the same shape almost every time. We are certified to ISO 27001, are we NIS2 compliant? And the answer that gets given — usually some version of “it’s a good starting point” — is true but useless, because it does not tell you what is left to do.
There is a better answer, and it is more specific than most vendors will give you. ISO 27001:2022 covers the large majority of the technical and organisational ground that Article 21(2) of NIS2 asks for. Four things it does not cover, and those four are legal obligations rather than security controls, which is exactly why a security management system does not produce them. They are the duties Article 20 places on the management body, the reporting deadlines in Article 23, the depth of supply chain scrutiny in Article 21(3), and a short list of named controls the law is prescriptive about where the standard is risk-based.
This article maps the overlap properly, using the official ENISA mapping rather than a vendor’s, and then works through the four gaps and what closing each one actually requires.
Want the short version first? The free NIS-2 gap assessment asks twelve questions, one per obligation area, and tells you which of the four gaps are open in your case. Five minutes, no sales call.
They are not the same kind of thing
Before the mapping, a distinction that causes more confusion than any control-level detail: these two instruments are not comparable objects, and treating them as competing options is the error underneath most of the bad advice on this topic.
NIS2 is Directive (EU) 2022/2555. It is law, transposed into national law by each Member State, and it applies to you because of what your organisation does and how large it is — not because you chose it. You cannot opt out, and there is no version of compliance that involves deciding the requirements do not suit your context. Non-compliance is enforced by a national competent authority with inspection powers and fines.
ISO/IEC 27001:2022 is a voluntary management system standard. You adopt it, you define its scope yourself, and certification is granted by an accredited body against the scope you declared. Its power comes from being risk-based: it tells you to establish a process for deciding which controls you need, rather than handing you a fixed list.
That difference in nature produces the four gaps almost mechanically. A voluntary, scope-defined, risk-based system will not generate a legal deadline, a personal liability, or a mandatory control that your own risk assessment concluded you did not need. It was never built to.
The practical consequence is that ISO 27001 is best understood as the machinery you already own for producing the evidence NIS2 will ask for, not as a substitute for reading the directive.
The official mapping, and what it actually says
For the digital sectors covered by Commission Implementing Regulation (EU) 2024/2690 — cloud providers, data centres, CDNs, managed service and managed security service providers, DNS providers, TLD registries, online marketplaces, search engines, social networking platforms and trust service providers — the technical requirements are set at EU level rather than nationally. The Annex to that regulation breaks Article 21(2) into thirteen requirement areas with far more specificity than the directive itself.
In June 2025 ENISA published Technical Implementation Guidance on those thirteen areas, around 170 pages of implementation advice and examples of evidence, together with a mapping table in spreadsheet form that correlates every CIR requirement to control references in ISO/IEC 27001:2022 and 27002:2022, NIST CSF 2.0, ETSI EN 319 401, CEN/TS 18026:2024 and several national frameworks. The table has been revised since release and is now at version 1.2.
Two things about that document matter more than the mapping itself.
The guidance is not binding. What binds you is the directive and, if you fall under it, the implementing regulation. The ENISA material is reference guidance — but national authorities and auditors cite it, which makes it the closest thing available to a shared expectation of what “adequate” looks like.
And ENISA states plainly that the mapping is a navigation aid, not a statement of equivalence. Standards address the same concerns in different language and at different depth. A mapping row telling you that CIR requirement 6.1 relates to ISO 27001 A.8.8 does not mean that implementing A.8.8 discharges the legal obligation. It means look there first.
That caveat is the honest frame for everything below. The overlap is real and it is large. It is not equivalence anywhere.
Where ISO 27001 does the work
Read the ten Article 21(2) measures next to Annex A and the correspondence is close enough that most certified organisations are further along than they think.
| Article 21(2) measure | Where an ISMS already answers it |
|---|---|
| (a) Risk analysis and information system security policies | Clauses 6.1.2, 6.1.3, A.5.1 — the risk assessment and treatment process is the ISMS core |
| (b) Incident handling | A.5.24–A.5.28 — planning, assessment, response, evidence collection |
| (c) Business continuity, backup, disaster recovery, crisis management | A.5.29, A.5.30, A.8.13 — ICT readiness for continuity, backup |
| (d) Supply chain security | A.5.19–A.5.23 — supplier relationships, agreements, monitoring, cloud services |
| (e) Security in acquisition, development and maintenance, vulnerability handling | A.8.8, A.8.25–A.8.31 — secure development lifecycle, vulnerability management |
| (f) Assessing the effectiveness of measures | Clauses 9.1–9.3 — monitoring, internal audit, management review |
| (g) Cyber hygiene and training | A.6.3, A.8.7 — awareness and training, malware protection |
| (h) Cryptography and encryption | A.8.24 — use of cryptography, key management |
| (i) HR security, access control, asset management | A.6.1–A.6.6, A.5.15–A.5.18, A.5.9–A.5.11 |
| (j) MFA, secured communications, emergency communications | A.8.5, A.8.20 partially — see the fourth gap below |
If you hold a current certificate, the practical implication is that you should not restart. You should re-open your Statement of Applicability, work down the ten measures, and record for each one which existing controls and records answer it. That exercise typically takes two or three days and produces most of the evidence pack an inspection would ask for.
What it will not produce is anything in the next four sections.
Gap one: the management body
Article 20 does something no management system standard does. It requires that the management bodies of essential and important entities approve the cybersecurity risk-management measures, oversee their implementation, and it makes those bodies liable for infringements. Article 20(2) then requires members of the management body to follow training, and to encourage regular equivalent training for employees.
The instinct is to point at clause 5.1 and say leadership is covered. It partly is. ISO 27001 requires top management to demonstrate leadership and commitment, to ensure the policy is established, and to conduct management review under clause 9.3. Any certified organisation has minutes somewhere.
Three things are still missing, and they are not cosmetic.
Approval as a distinct act. Clause 9.3 requires review of the ISMS. Article 20 requires approval of the measures. In practice this means a dated record in which the body examined the risk-management measures and approved them — not a management review agenda item where the ISMS was noted alongside eleven other topics. When an authority asks who approved these measures and when, “the board reviews the ISMS annually” is not a satisfying answer.
Personal exposure. Article 20(1) makes management bodies liable for infringements, and Article 32(5) allows competent authorities, for essential entities, to seek a temporary prohibition on the exercise of managerial functions at chief executive or legal representative level where remedies are ignored. Several Member States have gone further in transposition. There is no equivalent anywhere in ISO 27001, and the difference in tone when a board understands this is noticeable.
Training for the body itself. A.6.3 covers awareness for personnel. Article 20(2) attaches an obligation to the directors personally, and the evidence expected is a record of what training they received and when — attendance, date, content. This is the single most common thing missing from otherwise well-run certified organisations.
Closing this gap costs a governance policy that defines what the body approves and how often, a training record, and a standing agenda item with dated minutes. It costs no technical work at all, which is why it is so often left undone until an inspection.
Gap two: the reporting clock
Article 23 sets deadlines that are absolute, run from awareness, and have nothing to do with how well your incident response works internally.
| Stage | Deadline | What it must contain |
|---|---|---|
| Early warning | 24 hours from becoming aware | Whether the incident is suspected of being caused by unlawful or malicious acts, or could have cross-border impact |
| Incident notification | 72 hours from becoming aware | Initial assessment, severity and impact, indicators of compromise where available |
| Intermediate report | On request of the CSIRT or authority | Relevant status updates |
| Final report | One month after the notification | Detailed description, type of threat and root cause, mitigation applied, cross-border impact where applicable |
ISO 27001 gives you A.5.24 through A.5.28 — a full incident lifecycle — and A.5.5 on contact with authorities. None of it contains a deadline, because the standard cannot know what jurisdiction you are in. Your incident procedure almost certainly describes escalation in terms of internal severity and internal roles. Article 23 asks for something different: a decision, made under pressure and usually incomplete information, about whether this incident is significant, and the name of the person authorised to make that call at three in the morning.
That decision is the operational heart of the gap, and it is where the 24-hour clock is lost. Not in the technical response, which is usually competent, but in the twelve hours it takes for someone senior enough to decide the threshold has been crossed.
Alongside it sits registration. Article 27 requires certain entity types to submit and maintain registration details with the competent authority, and much of the early enforcement pattern across Member States has been about administrative failures of exactly this kind — registrations missed, notifications filed late, approval records that could not be produced — rather than sophisticated security failures. Those are the cheapest failures to avoid and the easiest for an authority to establish without a technical investigation.
Closing this gap means a notification procedure with named roles and a severity threshold written in advance, draft notification content prepared before you need it, and the national portal details known to the people on call. It is a day of work that only exists if someone decides to do it.
If you would rather not build the notification procedure from scratch, the NIS-2 Compliance Suite covers all thirteen processes with one procedure each, including the Article 23 notification flow with the significance decision and the three deadlines built in. €590 excl. VAT.
Gap three: how far down the supply chain
Article 21(2)(d) lists supply chain security, and an ISMS answers that with A.5.19 to A.5.23 — supplier relationships, security in agreements, monitoring and review, cloud services. For most audit purposes that is a complete answer.
Article 21(3) then extends the obligation in a way the standard does not. It requires entities to take into account the vulnerabilities specific to each direct supplier and service provider, and the overall quality of products and cybersecurity practices of their suppliers, including their secure development procedures.
Read that carefully. Two distinct extensions are hiding in one sentence.
The first is that the assessment must be supplier-specific rather than categorical. A tiering model that places all cloud providers in one risk band and applies the same questionnaire is a categorical assessment. The directive asks about vulnerabilities specific to each direct supplier — which means a named assessment per supplier, not a band.
The second reaches past your direct suppliers. The overall quality of products and cybersecurity practices of their suppliers is a second-tier concern. You are not expected to audit your supplier’s supplier, but you are expected to have asked, and to have something on file about how your critical suppliers manage their own chain and whether they develop securely.
The Cooperation Group’s coordinated risk assessments of critical supply chains add a further layer for some sectors, and results from those feed back into what authorities expect.
In practice this gap closes with a revised supplier assessment that asks two additional questions — about the supplier’s own supply chain management and about their secure development procedures — and with named, dated assessment records for critical suppliers rather than a tier assignment. The difference between a categorical model and a named assessment is the difference between passing and failing this point.
Gap four: where the law is prescriptive and the standard is not
This is the smallest gap in volume and the most philosophically awkward, because it cuts against how ISO 27001 works.
The standard is risk-based by design. A.8.5 requires secure authentication technologies appropriate to the access restrictions and the risk. If your risk assessment concludes that single-factor authentication with strong password policy is adequate for a given system, and you document that reasoning, you can be certified.
Article 21(2)(j) does not offer that route. It names multi-factor or continuous authentication solutions, secured voice, video and text communications, and secured emergency communication systems within the entity, as measures that must be among those implemented. The implementing regulation elaborates further for the entities it covers, requiring authentication by multiple factors in accordance with the classification of the asset being accessed, and ENISA’s guidance goes further still — recommending enforcement on internet-facing systems such as email, remote desktop and VPN, and documentation of the exceptions.
The gap is not that certified organisations lack MFA. Most have it. The gap is that a risk-based justification for its absence somewhere, which passes a certification audit, does not pass a regulatory one.
Secured emergency communications is the item most often entirely absent. It asks a simple question with an uncomfortable answer: if your primary network is compromised and you cannot trust your own email, how does the crisis team communicate? Most organisations discover they have no answer, no out-of-band channel, and no contact list that exists anywhere other than in the systems that are down.
The scope trap
One more thing worth naming, because it produces the most expensive surprises and it does not fit neatly into any of the four gaps.
An ISO 27001 certificate covers the scope you declared. That scope is frequently a single service line, a data centre, a product, or the subsidiary that needed the certificate to win a contract. NIS2 applies to the entity as it is regulated — which is usually much larger than the certified scope, and sometimes a different legal person entirely.
Before you rely on your certificate as evidence, read the scope statement on it against the entity your national authority believes it is regulating. If the certificate covers a subsidiary and the obligation attaches to the parent, the certificate demonstrates good practice but discharges nothing.
If you are still confirming which entities in your group are in scope at all, who must comply with NIS-2 works through the sector and size tests.
What to do, depending on where you start
| Your situation | The efficient path |
|---|---|
| ISO 27001 certified, current scope matches the regulated entity | Map the SoA to the ten measures, then close the four gaps. Two to four weeks, mostly documentation |
| ISO 27001 certified, scope narrower than the regulated entity | Extend the ISMS scope or run a parallel NIS2 documentation set for the uncovered parts. Decide this before the next surveillance audit |
| ISO 27001 implementation in progress | Fold NIS2 obligations in now rather than later. The four gaps are cheap to add during design and expensive to retrofit |
| Neither in place, NIS2 obligation confirmed | Build to NIS2 directly. Certification is a business decision that can follow; the legal deadline cannot wait for a three-year certification cycle |
| Neither in place, no NIS2 obligation, customers asking for assurance | ISO 27001 is the right target. It is what customers recognise and buy |
The last row matters more than it looks. If nobody is obliging you to comply with NIS2 and your driver is commercial, a certificate is worth more than a compliance file, because a certificate is a thing a procurement department can accept. Compliance evidence has no equivalent currency.
The combined path, in order
For an organisation with a working ISMS and a confirmed NIS2 obligation, the sequence that wastes the least time.
- Confirm which legal entities are in scope and whether the implementing regulation applies to any of them. This changes how prescriptive the requirements are.
- Map the Statement of Applicability to the ten Article 21(2) measures and record the gaps. Two to three days.
- Write the governance record: what the management body approves, how often, and the training record for its members. This is the fastest gap to close and the one authorities check first.
- Write the notification procedure with the significance threshold, named decision-maker and the three deadlines. Rehearse the 24-hour call once.
- Revise the supplier assessment to ask about second-tier practices and secure development, then re-assess your critical suppliers by name.
- Audit MFA coverage against internet-facing systems, document exceptions, and establish an out-of-band emergency communication channel with a contact list held outside your primary systems.
- Register with the competent authority if you have not, and confirm the reporting channel details are with the people on call.
Steps three through six are the four gaps. Everything else you already own.
Frequently asked questions
Does ISO 27001 certification make you NIS2 compliant? No. It covers a large share of the Article 21(2) risk-management measures and produces most of the evidence an inspection would ask for, but it does not discharge the Article 20 management body duties, the Article 23 reporting deadlines, the depth of supply chain assessment in Article 21(3), or the specifically named controls in Article 21(2)(j). It is one way to demonstrate compliance with part of the directive, not a legal substitute for it.
Will an authority accept my certificate as evidence? As supporting evidence, generally yes — but read the scope. A certificate covering a narrower scope than the regulated entity demonstrates good practice for the certified part only. Article 24 also allows Member States to require the use of particular certification schemes, so national transposition is worth checking.
Should we get certified if our driver is NIS2? Not necessarily, and not first. Certification takes months and costs audit fees; the legal obligation does not wait for it. Build the documented set the directive requires, and treat certification as a separate commercial decision.
How much of NIS2 does ISO 27001 actually cover? On the technical and organisational measures, most of it — ENISA’s mapping table finds ISO 27001 or 27002 references for essentially every requirement area of the implementing regulation. On the legal obligations that sit outside Article 21(2), none of it, because those are not security controls.
Is the ENISA guidance mandatory? No. The directive and the implementing regulation bind you. The guidance is reference material — but authorities and auditors cite it, so departing from it means being able to explain why.
Does ISO 27001 help with the 24-hour deadline? It gives you the incident response capability. It does not give you the notification decision, the threshold, or the deadline, because a voluntary standard cannot contain a jurisdiction’s reporting law. That procedure has to be written separately.
Where to go from here
On the mechanics of the ISMS itself, the risk assessment is where NIS-2 Article 21(2)(a) and ISO 27001 clause 6.1.2 meet most directly.
On the ISO side, two pieces are worth reading before you buy anything: what the standard actually requires you to document and retain, and the 2024 amendment that added a climate change determination to the context analysis.
The four gaps are documentation gaps rather than engineering ones. If you have an ISMS running, closing them is a matter of weeks and the work is mostly writing — which is either a relief or an irritation, depending on how much of your time writing procedures deserves.
The free NIS-2 gap assessment takes twelve questions and tells you which of the four are open in your case, with the relevant article for each.
If you would rather start from a written set, the NIS-2 Compliance Suite covers all ten measures across thirteen procedures — one per process, each opening with a table mapping every obligation to the step that discharges it, the role accountable and the record it produces, plus the registers and forms. €590 excl. VAT. For the ISO 27001 side, the ISO 27001 Total Kit covers the mandatory documented information for clauses 4 to 10 and the Annex A controls that imply records.
For the measure-by-measure detail behind the mapping above, the ten Article 21 measures works through each one with the evidence expected.
Sources
- Directive (EU) 2022/2555 (NIS2), in particular Articles 20, 21, 23, 24, 27, 32 and 34
- Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 and its Annex
- ENISA, Technical Implementation Guidance on Cybersecurity Risk Management Measures, version 1.0, June 2025
- ENISA, Technical Implementation Guidance Mapping Table, version 1.2
- ISO/IEC 27001:2022 and ISO/IEC 27002:2022