NIS2 vs ISO 27001 on Azure: What Overlaps, What Doesn't
NIS2 vs ISO 27001 on Azure: a control-by-control map of Article 21 to Annex A, plus the three gaps certification doesn't close. For compliance leads and CISOs.
Marc Dekeyser |
NIS2 vs ISO 27001 on Azure: What Overlaps, What Doesn’t
TL;DR: On Azure, ISO 27001 and NIS2 want almost the same technical controls. NIS2 then bolts on three legal duties no certificate touches, and those are the parts a supervisor tests first.
“We are ISO 27001 certified” is a strong security statement. It is a weak NIS2 defence.
Here is why the two keep getting confused. An ISO/IEC 27001:2022 certificate shows you run a working information security management system. Most of its Annex A controls land on the same NIS2 Article 21 measures you would build in Microsoft Azure and Microsoft 365 anyway. The overlap is genuine, and it is large.
Then NIS2 adds three obligations a certificate was never built to carry: the 24-hour and 72-hour incident reporting duty, personal liability for the management body, and registration with the supervisor. None of them live in Annex A.
Read the table first. Then read the gaps, because the gaps are what gets organisations caught.
The mapping: Article 21 to Annex A on Azure
Article 21(2) lists ten measure domains. Most fold onto one or more ISO/IEC 27001:2022 Annex A controls, each with a Microsoft Azure or Microsoft 365 implementation you can point at. A compliance lead uses a view like the one below to avoid rebuilding controls an ISO programme already stood up.
| NIS2 Article 21(2) measure | ISO/IEC 27001:2022 Annex A | Azure / Microsoft 365 implementation |
|---|---|---|
| (a) Risk analysis & information system security policies | A.5.1 policies; A.5.9 inventory of assets | Microsoft Defender for Cloud secure score; Azure Policy; resource inventory |
| (b) Incident handling | A.5.24–A.5.28 incident management | Microsoft Sentinel analytic rules, Microsoft Defender XDR incidents |
| (c) Business continuity, backup, disaster recovery, crisis management | A.5.29–A.5.30; A.8.13 backup | Azure Backup, Azure Site Recovery, geo-redundant storage |
| (d) Supply chain security | A.5.19–A.5.22 supplier relationships | Microsoft Entra ID enterprise app governance; Defender for Cloud third-party findings |
| (e) Security in acquisition, development & maintenance; vulnerability handling | A.8.25–A.8.29 secure development; A.8.8 technical vulnerabilities | Microsoft Defender for Containers image scanning; Defender for Cloud vulnerability assessment |
| (f) Policies to assess effectiveness of measures | A.5.35–A.5.36 review; A.8.16 monitoring | Microsoft Sentinel workbooks; Defender for Cloud regulatory compliance dashboard |
| (g) Cyber hygiene & training | A.6.3 awareness; A.8.7 malware protection | Microsoft Defender for Endpoint; attack surface reduction rules |
| (h) Cryptography & encryption | A.8.24 use of cryptography | Azure Key Vault; encryption at rest/in transit; Microsoft Purview |
| (i) Human resources security, access control, asset management | A.6 people; A.5.15–A.5.18 access control; A.8.2–A.8.5 privileged access | Microsoft Entra ID Conditional Access, Privileged Identity Management |
| (j) MFA, secure communications, emergency comms | A.8.5 secure authentication | Microsoft Entra ID MFA; Conditional Access; secure email in Microsoft 365 |
The overlap is real, and useful. Run a mature ISO 27001 programme on Azure and the technical measures in Article 21(2)(a) through (j) are mostly in place already, mostly evidenced already. The Microsoft Azure Well-Architected Framework security pillar walkthrough shows the same controls sitting inside the Well-Architected guidance. A third lens on the same configuration.
The three gaps a certificate leaves open
All three are legal, not technical. A certificate attests that you run a management system. It says nothing about whether you hit a statutory reporting deadline, whether your board carries personal accountability, or whether you registered with the authority. Supervisors probe these first, because a security programme on its own tends to leave them open.
Reporting deadlines (Article 23)
Annex A requires incident management. It does not require notifying a national authority within 24 hours, then 72. NIS2 does. You can run flawless internal handling under A.5.24–A.5.28 and still breach NIS2 by missing the early warning. External, deadline-bound, and no certificate covers it. Building that capability on Azure is its own job. See NIS2 incident reporting on Azure.
Management-body accountability (Article 20)
Here the board is on the hook personally. Article 20 makes management bodies approve the risk-management measures, oversee implementation, and sit through the training, and it holds them liable when things fail. ISO 27001 expects leadership commitment. It does not put a named individual’s neck on the line. Under NIS2 the obligation cannot be delegated away.
Registration with the competent authority
No ISO equivalent exists. Essential and important entities have to register with their national supervisor and hand over identifying information. You can hold a spotless certificate and still be unregistered, and therefore non-compliant on a basic NIS2 administrative duty.
Why “we’re ISO 27001 certified” isn’t a defence
A supervisor enforces statutory duties. A certificate comes from a private certification body, and it discharges none of them. The supervisor is not asking whether you have a management system. The question is whether you reported the incident on time, whether your management body is accountable, and whether you registered. A certificate answers none of that.
The category error is treating compliance as something you buy or get awarded. ISO 27001 is a conformity assessment against a voluntary standard. NIS2 is a legal regime: administrative supervision, the power to impose binding instructions, and for essential entities, financial penalties tied to turnover. Different planes. One is evidence. The other is law.
None of this diminishes ISO 27001. Certification is a sound way to build and evidence the Article 21(2) technical measures, and a clean certificate genuinely cuts the work of a NIS2 readiness exercise. The mistake is stopping there. Treat the certificate as the head start it is, then close the three legal gaps on purpose. The SOC 2 readiness on Azure architecture piece makes the same point about attestations: strong evidence of controls, not a substitute for a specific regulatory duty.
Which framework should drive your control design?
NIS2, if you are an EU regulated entity. It is the binding obligation, so it sets the target. ISO 27001 then structures how you implement and evidence the technical measures. You design once on Azure and satisfy both: one Microsoft Sentinel, Microsoft Entra ID, and Microsoft Defender for Cloud configuration serves the ISO management system and the NIS2 measures, while the NIS2-specific legal duties get handled as governance work off the platform.
A workable sequence:
- Map your existing ISO 27001 Annex A controls onto NIS2 Article 21(2) with the table above. Mark what already exists.
- Find the technical gaps NIS2 surfaces that your ISO scope missed. Often supply chain (d) and vulnerability handling (e), at the depth NIS2 expects.
- Close the three legal gaps as named workstreams: incident reporting capability, management-body accountability, registration.
- Keep one evidence set for both frameworks, so an ISO auditor and a NIS2 supervisor draw from the same source.
The Azure architecture governance checklist covers the scaffolding that makes a single, dual-purpose evidence set practical.
Producing that dual-purpose evidence is where the manual effort piles up: the control mapping, the configuration proof, the gap list. Platform Architecture Authority (PAA) reads your Microsoft Azure and Microsoft 365 configuration, maps the findings against both NIS2 Article 21 and the Annex A controls they correspond to, and shows where your ISO posture already covers a NIS2 measure and where a gap remains. Then it generates remediation code for the technical gaps. It won’t file your registration, sit on your board, or replace a compliance lead’s judgment on the legal duties. It produces the technical evidence both frameworks ask for, mapped to the article and the control ID.
Key takeaways
- NIS2 Article 21 measures and ISO/IEC 27001:2022 Annex A controls overlap heavily on technical and organizational security: risk management, access control, cryptography, incident handling, business continuity.
- ISO 27001 is a voluntary management-system standard. NIS2 is law, transposed nationally (in the Netherlands, the Cyberbeveiligingswet).
- Three NIS2 duties survive an ISO certificate untouched: the Article 23 incident reporting timeline, Article 20 management-body accountability and liability, and registration with the competent authority.
- ISO 27001 certification is strong evidence toward the Article 21(2) technical measures, and worth pursuing. A head start, not a finish line.
- On Azure, the same Microsoft Sentinel, Microsoft Entra ID, and Microsoft Defender for Cloud configurations serve both frameworks. The legal obligations sit outside the platform.
FAQ
Does ISO 27001 certification make NIS2 compliance automatic? No. It demonstrates most of the technical measures in NIS2 Article 21(2) and is strong supporting evidence, but it does not satisfy the Article 23 reporting timeline, the Article 20 management-body liability, or registration with the supervisor. Those three duties are legal obligations a certificate was never designed to cover.
Is NIS2 stricter than ISO 27001? They differ in kind more than in severity. ISO 27001 is a voluntary management-system standard with broad, flexible controls. NIS2 is law, with specific, deadline-bound duties and personal accountability for leadership. On technical depth they are comparable. On legal enforcement, reporting, and governance accountability, NIS2 is stricter.
Can we use our ISO 27001 evidence for a NIS2 assessment? Yes, and you should. The Annex A control evidence — access control, cryptography, incident management, backup — maps directly to NIS2 Article 21(2) measures, so a single configuration and evidence set on Azure serves both. You then add NIS2-specific evidence for incident reporting capability, board accountability, and registration, which ISO does not produce.
Which standard should we implement first on Azure? Design to NIS2 because it is binding, and use ISO 27001’s structure to implement and evidence the technical measures. The Microsoft Azure and Microsoft 365 configuration is largely the same for both. Sequencing ISO first is reasonable if certification is already a goal, provided you then close the three NIS2 legal gaps rather than assuming the certificate closed them.
Does the Cyberbeveiligingswet change this mapping? The Cyberbeveiligingswet is the Dutch transposition of NIS2, so the Article 21 measures and Article 23 reporting duties apply as enacted in Dutch law, with the competent authority and CSIRT defined nationally. The control-to-Annex-A mapping holds; what the national law fixes is who you report to, who supervises you, and the registration mechanics.
A certificate on the wall and a statutory duty in law are not the same object. Build the controls once on Azure, evidence them against both frameworks, and treat the three legal gaps as work certification will never do for you.
