The short answer
ISO 27001 is a voluntary international standard you can be certified against; NIS2 is EU law you must comply with whether you like it or not. An established ISO 27001 ISMS covers a substantial part of NIS2's ten risk-management measures — but leaves four consistent gaps: statutory incident-reporting deadlines, depth of supply-chain security, accountability of management, and registration with your national authority. Certification is useful evidence. It is not compliance.
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. Nobody fines you for not having it. 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.
| ISO 27001 | NIS2 | |
|---|---|---|
| Nature | Voluntary standard | Binding EU law |
| Applies because | You chose it | Your sector and size |
| Scope | You define it | The whole in-scope entity |
| Proof | Certificate from accredited body | Evidence to the national authority |
| Failure costs | Lost certificate, lost deals | Fines, sanctions, management liability under national law |
| Incident reporting | Internal process, your timelines | 24h / 72h / 1 month, statutory |
| Management role | Leadership commitment (Clause 5) | Approval and oversight duties (Art. 20) |
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:
Risk analysis and information security policies — this is the heart of ISO 27001. Clauses 6 and 8 on risk assessment and treatment, plus the policy framework, map cleanly onto Article 21(2)(a).
Secure acquisition, development and maintenance — Annex A's technological controls cover secure development, change management, test data and vulnerability management, addressing Article 21(2)(e).
Assessing effectiveness — Clause 9's internal audit, monitoring and management review are exactly what Article 21(2)(f) asks for.
Cryptography — the ISMS cryptographic policy and key management controls satisfy Article 21(2)(h).
Access control, asset management and HR security — Annex A's organisational, people and technological control themes cover Article 21(2)(i) thoroughly.
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).
- Check the current DNSC procedures and orders — they, not the certificate, define the compliance mechanics in Romania.
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.
Sources
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.