Doing ISO 27001 and NIS2 once instead of twice

Roughly 70 to 80 per cent of what NIS2 Article 21 asks for is already covered by an ISO 27001 ISMS. The remaining fifth is where the work is, and it is not the part anyone budgets for.

Daniel Grigorovich
Daniel Grigorovich
Founder · 8 Sept 2026 · 6 min read
ISO 27001NIS2GRC
Doing ISO 27001 and NIS2 once instead of twice

Who should read this: a company that is being pushed toward ISO 27001 by a customer and toward NIS2 by a regulator, at the same time, and is about to run them as two projects.

Do not run them as two projects. Most of the work is the same work, and the parts that differ are not the parts you would guess.

The measure of overlap

NIS2 Article 21(2) lists ten categories of measure that in-scope entities have to take. Mapped against ISO 27001:2022 clauses and Annex A controls, the coverage lands at roughly 70 to 80 per cent. Five of the ten are fully covered by a working ISMS. The other five are partly covered. None is a complete gap.

Article 21(2) measureCovered by ISO 27001
(a) Risk analysis and information security policyFull
(b) Incident handlingPartial
(c) Business continuity and crisis managementPartial
(d) Supply chain securityPartial
(e) Secure acquisition, development and maintenanceFull
(f) Assessing effectiveness of the measuresFull
(g) Cyber hygiene and trainingPartial
(h) Cryptography and encryptionFull
(i) HR security, access control, asset managementFull
(j) MFA, secure communications and emergency commsPartial

The practical reading of that table: if you build an ISMS properly, you are most of the way through Article 21 without having opened a NIS2 project. The detail of the ten measures is in the NIS2 Article 21 measures.

Where “partial” actually bites

Partial is doing a lot of work in that table, so it is worth being specific about the five.

Incident handling. ISO 27001 wants you to detect, respond, learn and improve. It says nothing about telling anybody outside. NIS2 does, and on a clock. See below.

Business continuity. ISO 27001 asks for continuity of information security. NIS2 asks for operational resilience of the service, including crisis management and backup arrangements at a level an ISMS does not necessarily reach.

Supply chain. ISO 27001 Annex A 5.19 to 5.22 covers your direct suppliers. NIS2 expects you to think about the dependencies behind them, and to pass requirements down. If your customers are already sending you supplier questionnaires, this is the same mechanism pointed at you, described in supply chain security under NIS2.

Cyber hygiene and training. ISO 27001 requires awareness and competence. NIS2 requires it of the management body specifically, and makes it their obligation rather than a training record, covered in training requirements for boards and employees.

MFA and secure communications. ISO 27001 names authentication as a control to select. NIS2 names multi-factor authentication and secured emergency communications as things you use. A control marked applicable and partly deployed passes one and not the other.

The five NIS2 obligations no ISMS contains

This is the fifth that does not map, and it is the part that surprises people who assumed a certificate would settle the matter.

1. Incident reporting deadlines. Early warning within 24 hours, notification within 72 hours, final report within one month, to your CSIRT or competent authority. ISO 27001 has no equivalent obligation and no clock. Getting this wrong is a reporting failure rather than a security failure, and it is measured in hours. The mechanics are in the NIS2 incident reporting timeline.

2. Management body liability. Article 20 puts approval and oversight of the measures on the management body and makes it accountable. ISO 27001 asks for leadership commitment, which is not the same legal thing. See board accountability under NIS2.

3. Registration. In-scope entities have to register with the national authority. Purely administrative, no ISO 27001 equivalent, and easy to miss entirely.

4. Coordinated vulnerability disclosure. NIS2 expects participation in the EU mechanism. ISO 27001 covers internal vulnerability management, not external coordination.

5. Jurisdiction. Which member state supervises you is a NIS2 question with a real answer, and it matters if you operate in several. ISO 27001 does not care where you are. See which jurisdiction applies.

Notice what these five have in common. None of them is a security control. All of them are obligations of the organisation, and four of the five are things a certificate cannot demonstrate.

The sequencing that saves the money

Two rules, and they are cheap to follow if you decide early.

Build one control set, not two. Implement a control once, map it to both frameworks, and evidence it once. Two registers, two policy sets and two evidence folders describing the same controls is the single most common and most expensive mistake here, and it compounds because every future framework gets its own folder too.

Do the scoping for both at the start. ISO 27001 scope is your decision. NIS2 scope is a matter of law and it is not negotiable. If you are in scope, work out the boundary of the regulated service first, then draw your ISMS scope so that it contains it. Drawing the ISO scope first, for the narrowest possible certificate, and discovering later that the regulated service sits half outside it, means redoing the risk assessment and the Statement of Applicability. That is the trap described in scope and the Statement of Applicability, with legal consequences added.

If you do not know whether you are in scope at all, settle that before anything else. The NIS2 scope checker takes a couple of minutes, and the categories are explained in essential and important entities compared.

What this costs versus two projects

Run separately, you pay twice for gap analysis, twice for policy work, twice for evidence collection and twice for the internal effort, which is the largest line either way, as set out in what ISO 27001 actually costs an SME.

Run together, you pay once for the 70 to 80 per cent, and the incremental NIS2 work is the five obligations above plus the deepening of the five partial measures. In a company of 20 to 250 people that increment is weeks, not months, and most of it is procedural rather than technical.

The one thing you cannot merge is the certificate. ISO 27001 gets audited by a certification body. NIS2 gets supervised by an authority, and supervision for important entities is generally reactive rather than a scheduled audit. Holding a certificate does not discharge the NIS2 obligation, though it is the most efficient way to be able to demonstrate most of it, a point covered in certification standards under NIS2.

The technical reality: both frameworks stop at the same place

Here is the thing neither of them does, and it is the same thing.

ISO 27001 asks you to select and implement controls. NIS2 asks for measures appropriate to the risk. Both are outcome-agnostic about quality. A.8.8 and Article 21(2)(e) both ask you to handle technical vulnerabilities, and both are satisfied by a documented process with a monthly scan, whether or not the critical findings from that scan were fixed. Both ask for logging. Neither asks whether anyone reads the logs. Article 21(2)(b) and A.5.24 both want incident handling, and a written procedure meets them while nothing in the estate would actually raise the incident.

So doing both once gets you one control set, one evidence record and two obligations discharged for slightly more than the price of one. It does not tell you whether an intrusion would be noticed. That takes detection and exposure management running continuously and feeding findings back into the same record, which is the half of the problem the frameworks describe and neither one performs. The starting point for either project, and the fastest way to see which of your gaps are documentation and which are technical, is a structured audit before you commit.

Daniel Grigorovich

Daniel Grigorovich · Founder

I believe that no business should suffer from "compliance checklists" or navigating vague regulatory text. While I still stand by the principle that all software products should be reliable and secure, I want to give companies a way to overcome the challenges faced when implementing these requirements.