NIS2 vs ISO 27001: The Mapping, and What It Misses

This question comes up in almost every compliance conversation we have, usually in one of two forms. Either “we're ISO 27001 certified, so we're fine for NIS2, right?” — or “we need NIS2, should we just get ISO 27001?”

Both deserve a straight answer, because the wrong one costs either money you didn't need to spend or a compliance failure you didn't see coming.

The fundamental difference

Everything else follows from this:

ISO 27001 is a voluntary standard. NIS2 is law.

ISO/IEC 27001 is an international standard describing how to build and run an information security management system. You choose to adopt it. An accredited body audits you, and if you pass you receive a certificate valid for three years with annual surveillance audits. The standard itself carries no statutory penalty — not holding the certificate is not an offence, though the underlying security failures it addresses may well breach other law. What it costs commercially is real: customers may decline to buy from you, which is usually why organisations pursue it.

NIS2 — Directive (EU) 2022/2555 — is European legislation, transposed into the national law of each member state. If your organisation falls within scope as an essential or important entity, the obligations apply automatically. There is no opting out, no scoping down to a convenient perimeter, and no certificate that discharges the duty. Enforcement sits with a national competent authority, backed by administrative fines and, unusually, accountability duties placed directly on management.

One is a quality mark you earn. The other is a legal floor you stand on.

Where they genuinely overlap

The good news is real. NIS2's Article 21(2) lists ten categories of cybersecurity risk-management measures, and an established ISMS speaks to all of them at some level. In several the coverage is essentially complete:

The table below maps each of the ten measures to the ISO 27001:2022 clauses and Annex A controls that carry it, and says plainly what the standard leaves you to do anyway. Control numbers and titles are from ISO/IEC 27001:2022 Annex A; the measures are quoted from Article 21(2) of the directive.

NIS2 Article 21(2) → ISO 27001:2022 practical mapping

This is a practical control mapping, not a statement of legal equivalence. A certified ISMS produces useful evidence toward NIS2, and in several places the coverage is close to complete — but no control, and no certificate, discharges a legal obligation. A control listed in your Statement of Applicability means you have a process; the directive frequently specifies what that process must achieve, to whom, and by when. Read the last column accordingly.

The second column matters if you operate in Romania: the same ten measures are transposed as Article 13 of OUG 155/2024 in a different order, so six of the ten carry a different letter in the law a Romanian auditor actually reads.

Four things sit outside the table because no Annex A control corresponds to them at all: registration with the national authority, the scope — which the directive and national law determine, rather than the perimeter you choose for a voluntary ISMS — management liability under Article 20, and the supervisory relationship itself. Those are covered below.

There is also formal recognition of the alignment: Commission Implementing Regulation (EU) 2024/2690 uses ISO/IEC 27001 and ISO/IEC 27002 among its reference standards for the technical and methodological requirements applicable to certain digital entities. That demonstrates useful alignment — not automatic equivalence or NIS2 compliance.

If you run a mature ISMS, you are not starting from zero on NIS2. You are starting from most of the way there, on paper.

Where the gaps are

Four gaps appear consistently. They are the parts regulators look at, and none of them are solved by a certificate.

1. Incident reporting on a statutory clock

This is the largest and most frequently underestimated gap.

ISO 27001 requires an incident management process. It does not tell you when to notify anyone outside your organisation — that's your policy's business.

NIS2 Article 23 sets legally binding deadlines from the moment you become aware of a significant incident:

• Within 24 hours — an early warning to the competent authority (or CSIRT), stating whether the incident appears to be caused by unlawful or malicious acts, and whether it could have cross-border impact.
• Within 72 hours — a full incident notification updating the early warning, with an initial assessment of severity, impact and indicators of compromise.
• Within one month — a final report with a detailed description, root cause, applied mitigations and any cross-border impact.

Twenty-four hours is short. It assumes you have detection capable of telling you an incident is happening, a defined trigger for “significant”, a named person who can file, and the ability to say something meaningful about cause and cross-border impact almost immediately. Most ISMS incident procedures were never designed against a clock like that.

If you take one action after reading this article, make it a dry run of your 24-hour early warning. Organisations that have never rehearsed it consistently discover the bottleneck is not the paperwork — it's deciding whether the threshold has been crossed.

2. Supply chain security, in depth

Article 21(2)(d) requires security in supply chain relationships, including the specific vulnerabilities of each direct supplier and the overall quality of their security practices and development processes.

ISO 27001 covers supplier relationships, but typically at the level of contractual clauses and an approved-supplier list. NIS2 expects you to have actually assessed your critical suppliers' security posture — and it flows downward. Even organisations below the size thresholds are increasingly pulled in contractually, because their in-scope customers must now demonstrate supply-chain assurance.

If you sell to regulated entities, expect NIS2-shaped questionnaires whether or not the directive applies to you directly.

3. Management accountability

ISO 27001 Clause 5 asks for leadership commitment. In practice this is often satisfied by a signed policy and a management review meeting.

NIS2 Article 20 goes considerably further: management bodies must approve the cybersecurity risk-management measures, oversee their implementation, and may be held liable under the applicable national law for infringements. Members of management must also follow training, and are expected to offer similar training to staff.

This changes who owns the problem. Under ISO 27001, security is delegated to a function and reviewed by leadership. Under NIS2, it is a duty of the leadership itself. Boards that have never seen a security metric now need a defensible record showing they approved the measures, reviewed them, and acted on what they were told.

4. Registration and the regulator relationship

NIS2 requires in-scope entities to register or otherwise identify themselves with the national competent authority and maintain accurate contact details, including for cross-border matters. The exact procedure and deadlines are set by each member state's transposition. There is no analogue in ISO 27001 at all — an ISMS has no regulator.

Related: NIS2 authorities have supervisory powers including inspections, security audits and requests for evidence. Being able to produce evidence on demand, rather than assembling it for an annual audit window, is a different operational discipline.

The honest self-test

Ask this question about each of the ten Article 21 measures:

Do we have a documented process, or can we operationally execute this and prove it on demand?

Against the first test, a mature ISMS scores very well. Against the second, most organisations find the number drops sharply — because the ISMS was built to satisfy an auditor on a scheduled date, not a regulator after an incident.

That's the real gap between ISO 27001 and NIS2. Not the controls. The evidence, and the clock.

For what that gap looks like when it is never closed, see our breakdown of the ANCPI ransomware attack — an environment where almost none of the Article 21 measures were operational.

So which should you do?

If you're already ISO 27001 certified: don't rebuild anything. Run a targeted gap analysis against Article 21(2)(a)–(j) and Articles 20 and 23. Expect the work to concentrate in incident reporting readiness, supplier assessment depth, board governance and evidence availability. This is usually a matter of months, not years.

If you're in NIS2 scope with no ISMS: start with NIS2. It has the deadline and the liability. Build the programme so it could be certified later — the structures are compatible — but don't let a certification cycle become the reason you're late on a legal obligation.

If you're not in scope but sell to entities that are: you'll face NIS2 requirements through contracts regardless. ISO 27001 is often the most efficient way to answer those questionnaires once instead of forty times.

If you need both: build the NIS2 programme first and design the evidence layer so it serves both purposes. NIS2 is framework-neutral, so nothing stops one control set from satisfying the directive and the standard simultaneously. What differs is what you must prove, to whom, and how fast.

Frequently asked

Does ISO 27001 certification make us NIS2 compliant?

No. NIS2 is framework-neutral: certification is one way to evidence that measures exist, but it does not satisfy the directive by itself. The reporting deadlines, registration duty and management accountability obligations sit outside any ISMS certificate.

We're ISO 27001 certified. How much of NIS2 do we already have?

As documented process, typically a large majority. As something you can operationally execute and prove on demand within statutory deadlines, considerably less. The honest test is not whether a policy exists but whether you could produce the evidence during an inspection.

Should we get ISO 27001 certified in order to comply with NIS2?

Not necessarily. Certification is a sensible route if you also need it commercially — customers and tenders often ask for it. If your only driver is NIS2, a targeted compliance programme is usually faster and cheaper than a full certification cycle.

Which one comes first if we have neither?

NIS2, if you're in scope. It's a legal obligation with deadlines and liability attached; ISO 27001 is a commercial choice with no statutory clock. Build the NIS2 programme in a way that can be certified later if you decide you want the certificate.

Romania implementation note

National implementations differ. What follows is one national example, not the universal EU process:

• Romanian law requires management approval and oversight of the cybersecurity measures, and management training obligations apply.
• ISO certification does not replace DNSC identification, registration, incident-reporting or supervisory requirements under the Romanian transposition (OUG 155/2024, as approved and amended).
• The compliance mechanics are set by the DNSC orders, not by the certificate. As of this review that means Order 1/2026 and Order 2/2026 for the measures and the self-assessment, and Decision 3/2026 if you are part of a group — all three are described below and linked in the sources.

One wording difference is worth noting alongside the renumbering shown in the mapping above: where the directive's (e) covers acquisition, development and maintenance, the Romanian text adds casare — secure disposal — bringing A.7.14 and A.8.10 into scope for that measure explicitly.

Romania's additional six-hour reporting rule

Romania adds a reporting deadline that is not part of the directive's sequence. Alongside the familiar 24-hour early warning, 72-hour notification and one-month final report set out in Article 15(7) of OUG 155/2024, Article 15(3) requires reporting within six hours — without undue delay, and no later than six hours from becoming aware of information that allows the national incident-response team to determine a cross-border impact.

This is a national requirement, not a NIS2-wide one. If your incident playbook was written against the directive, it has a six-hour trigger missing. For the full sequence, see our guide to NIS2 incident reporting.

What the 2026 orders changed

Two DNSC orders published in 2026 now govern how the maturity self-assessment is completed. Order 1/2026 (Monitorul Oficial 712 and 712 bis of 27 August 2026) approved the risk-management measures and the self-assessment methodology, and requires that requirements implemented under special or sectoral regulations be recorded in a statement of applicability prepared by the entity.

Order 2/2026 (Monitorul Oficial 792 of 18 September 2026) supplements it, and is the one that matters if you were planning to mark controls as not applicable. It sets out how exclusions work:

• A control can be excluded by selecting N/A for both scoring parameters, within hard limits: one control at the Basic level, three at Important, five at Essential.
• Key measures can never be excluded, at any assurance level — and at the Essential level, neither can the controls tied to management aspects.
• Each excluded control still scores: 2.5 at Basic, 3 at Important and Essential.
• Every exclusion must be justified in writing, with the reasons the control does not apply, and recorded in the statement of applicability.
• Exceed the limits, or exclude something that cannot be excluded, and those exclusions are disregarded — the self-assessment is not considered compliant until it is corrected.

Order 2/2026 also adds a rule for entities that are part of a group of undertakings: they implement the cybersecurity requirements according to applicability rules approved by decision of the DNSC director. That decision now exists — Decision 3/2026 (Monitorul Oficial 798 of 21 September 2026), with annexed norms. It matters directly to the ISO question, because a group running one central ISMS cannot simply point at the parent. Each control is classified as inherited from the group, implemented locally against group standards, or shared — and whichever it is, the entity remains answerable for demonstrating the control works in its own scope. Governance controls need not be redefined locally; they must still be shown to be applied.

None of this is satisfied by an ISO 27001 certificate. The statement of applicability in ISO 27001 and the one Romanian law asks for share a name and serve different purposes — one records which Annex A controls you apply and why, the other justifies exclusions from a state-mandated self-assessment against a different control set. If you want to see which key measures would block you before you start, our free NIS2 check (in Romanian) walks through them.

The short version

ISO 27001 tells you how to build a security management system. NIS2 tells you what the law now requires, who is accountable for it, and how quickly you must report when it fails.

A certificate is good evidence that measures exist. It is not, and was never designed to be, proof of compliance with a directive that didn't exist when the standard was written.

This article is general information, not legal advice. Whether and how certification is recognised as evidence varies by member state and supervisory practice — confirm specifics with your authority or counsel. This article reflects the legislation in force on the last-reviewed date; proposed amendments are not treated as adopted law.