All 49 requirements of the NIS2 implementing regulation, set against ISO/IEC 27001:2022, NIST CSF 2.0, ETSI EN 319 401, CEN/TS 18026 and the national frameworks of Belgium, Finland, Greece, Spain and France — reproduced from ENISA's own published mapping. Plus two columns of ours that ENISA does not have: ISA/IEC 62443 for operational technology, and ISO 22301 for business continuity.
Open the mapping The two columns that are oursLargely, but not completely — and the useful answer is not a percentage, it is a list. ISO/IEC 27001:2022 addresses the substance of most NIS2 cybersecurity risk-management requirements, and an existing ISMS produces much of the evidence a supervisor will ask for. On the mapping below, 69 of the 93 Annex A controls are referenced against at least one NIS2 requirement.
What ISO 27001 does not give you is the part NIS2 adds on top of security management: the duty to register with your national authority, the 24-hour / 72-hour / one-month incident reporting cascade to a CSIRT, and the personal accountability and training duty Article 20 places on your management body. No ISMS control satisfies those, because they are not security controls — they are legal obligations owed to a regulator. Those are set out below.
ISO 27001 is one of 9 frameworks ENISA correlated. The same 49 requirements are also set against NIST CSF 2.0, ETSI EN 319 401 for trust service providers, CEN/TS 18026, and the national frameworks of Belgium, Finland, Greece, Spain and France. Every column is on this page and you can switch between them in the table — useful if you report into a US parent on NIST, or supply the Spanish public sector under the ENS.
Two things ENISA's table does not have, which we added: an ISA/IEC 62443 column for the OT sectors, and an ISO 22301 column for business continuity. The second matters more than it sounds. Article 21(2)(c) is business continuity and crisis management, and ENISA correlates it to no continuity standard at all — section 4 of the regulation ends up resting on three ISO 27001 controls. ISO 22301 answers it with the whole of clause 8, business impact analysis included.
The nine-framework mapping itself is ENISA's. We have reproduced it faithfully, added the ISO control names, added the Article 21(2) linkage, built the reverse index, and noted the handful of transcription artefacts in the original file. Our two columns are marked ours wherever they appear.
On 26 June 2025 ENISA published its Technical Implementation Guidance on Commission Implementing Regulation (EU) 2024/2690 — the act that turns the ten headline measures of NIS2 Article 21(2) into 49 concrete requirements. Alongside it ENISA published a mapping table correlating each of those requirements with European, international and national standards and frameworks. Version 1.1 followed on 10 July 2025.
That table is a spreadsheet, and as far as we can find nobody has put all of it on the web. This page is it — every column, every row, with each requirement addressable by its own link.
ENISA is explicit about what the table is not, and that caveat governs everything below:
“The mapping table should not be interpreted as a measure of equivalency among different standards or frameworks. It simply refers to relevant requirements in these standards or frameworks without assessing whether these fully cover the requirements of the regulation.”
It is also advisory rather than binding, and Member States remain free to determine their own approach to supervision. Read it as a navigation aid between documents, not as a compliance claim. Download ENISA's original spreadsheet.
ENISA's column headings, expanded. Four are standards and specifications; five are national frameworks from Member States that have published their own. The last two cards are ours, not ENISA's.
France has a column but no description. ENISA heads it “FR” and its own annex on national frameworks carries no France entry, so the source document is never named. The identifiers carry -IE and -EE suffixes, which distinguish important entities from essential entities. We have reproduced the references and declined to guess at the document behind them.
Germany has a description but no column. ENISA's annex points to the BSI's state-of-the-art advisory, but no German references appear in the mapping table itself. If you are working to the German transposition, the ISO column is the one that will serve you here.
Implementing Regulation (EU) 2024/2690 is directly binding on a defined subset of NIS2 entities — broadly the digital ones: DNS service providers, TLD name registries, cloud computing service providers, data centre service providers, content delivery network providers, managed service and managed security service providers, online marketplaces, online search engines, social networking platforms, and trust service providers.
If you are a hospital, a port, a water utility or a manufacturer, the regulation does not bind you directly. It remains the most detailed articulation the Commission has published of what Article 21(2) actually asks for, and national authorities and auditors read it that way. Treat it as the best available reading of the standard of care, and check your own national implementing law for what is legally operative in your case.
Grouped by the thirteen sections of the Annex, each tagged with the Article 21(2) point it implements. The buttons below are live — tick the frameworks you want and the rest are hidden. ISO 27001, NIST and our two columns are on by default; every column is still in the page, so nothing is lost by switching one off. Each requirement has its own anchor link, so you can cite a single row.
A written, management-approved security policy with objectives, scope and roles, reviewed on a set cycle.
Named owners for security duties, with the authority and the reporting line to discharge them.
A repeatable method for identifying, assessing and treating risk, with a treatment plan management signs off.
Evidence that you check your own compliance against the policy, not only at audit time.
Review by someone independent of the people who run the controls.
A documented incident policy setting out roles, classification and escalation before an incident happens.
Logging and monitoring wide enough to detect the incidents you are obliged to report.
A route for staff and suppliers to report suspected events quickly, without judgement calls.
Criteria that decide, consistently, whether an event is an incident and whether it is significant.
Containment, eradication and recovery steps that people have actually rehearsed.
Lessons captured and fed back into the controls, with the change trail to prove it.
Continuity and recovery plans with tested objectives, not an untested document.
Backups that are taken, protected, and restored under test.
A crisis structure with decision rights, contacts and communication paths defined in advance.
A supplier security policy that sets requirements by criticality and flows them into contracts.
A maintained register of suppliers and service providers with the services they deliver.
Security requirements set before ICT products and services are bought, not after.
Security built into the development lifecycle rather than tested at the end.
Secure baselines applied and enforced across systems.
Changes, repairs and maintenance assessed for security impact and authorised.
Testing that verifies the controls work, on a defined schedule.
Patches assessed, prioritised and applied within stated timeframes.
Network controls that limit exposure and detect abnormal traffic.
Segmentation that contains an intrusion instead of letting it spread.
Malware protection plus control over what software may run.
A vulnerability handling process, including how you receive and act on external reports.
Measurement of whether the measures work, feeding management review.
Cyber hygiene reaching everyone, including non-technical staff.
Role-appropriate training, with records of who was trained and when.
A cryptography policy covering algorithms, key management and where encryption is required.
Security duties written into employment terms and understood from day one.
Background verification proportionate to the role, where the law permits.
Access, assets and duties dealt with cleanly when someone leaves or changes role.
A disciplinary route for security breaches that is known in advance and applied consistently.
An access control policy grounded in least privilege and need to know.
Access granted, reviewed and revoked through a controlled process.
Privileged accounts identified, restricted, and monitored more closely than the rest.
Administration systems hardened and separated from general-purpose use.
Unique identities, with shared accounts controlled by exception.
Authentication strong enough for the risk, with credential handling rules.
Multi-factor or continuous authentication where the risk warrants it.
Assets classified so protection matches sensitivity.
Handling rules that follow the classification through storage, transfer and disposal.
Control over removable media, including when it may be used at all.
A current inventory of assets with owners.
Assets and access recovered or removed when employment ends.
Power, cooling and other utilities protected so they do not become the outage.
Protection against fire, flood and comparable physical and environmental threats.
Physical perimeters, entry control and monitoring of secure areas.
ENISA's nine columns leave two holes that matter to anyone actually running the programme. Nothing in them is written for a plant, and nothing in them is a continuity standard. So we added two columns of our own: ISA/IEC 62443 for operational technology, and ISO 22301 for business continuity. Both are NexGenio's work rather than a regulator's, both are marked ours wherever they appear, and the derivation of each is set out here so you can disagree with it specifically.
Eight of the nine ENISA columns are IT frameworks and the ninth is a trust-service specification. None of them is written for a plant. Several NIS2 sectors are materially operational technology — energy, drinking water, waste water, chemicals, manufacturing, transport — and for those the relevant standard is the ISA/IEC 62443 series. ENISA does not map to it. Neither does anyone else.
We checked directly against the publications of every body that might have: ENISA, the German BSI, the Austrian NIS authority, ISA and its Global Cybersecurity Alliance, and the IEC itself. None has published a clause-level crosswalk between NIS2 and the 62443 series. What circulates instead is vendor and certification-body marketing asserting that the two are “complementary”, without a table behind it.
ISA's own alliance came closest. Its June 2025 white paper Applying ISO/IEC 27001, ISO/IEC 27002 and the ISA/IEC 62443 Series for Operational Technology Environments works a single example — 62443-2-1's NET 3 Secure remote access against four ISO/IEC 27002 controls — and then says in its own “next steps” that a full element-by-element mapping could be developed. It does not exist yet.
So the column below is NexGenio's work, not a regulator's, and we have kept it visually separate from ENISA's nine for exactly that reason. It carries none of ENISA's authority. It carries our reasoning, which you can check.
We map to requirement families and foundational requirements — ORG 1, NET 3, FR 5, ZCR 3 — and not to individual system requirements, component requirements or SP.XX.YY service-provider requirements.
Two reasons, and the second is the honest one. First, the 62443 parts are paywalled, and the individual requirement titles are not ours to reproduce. Second, when we had those titles researched, two separate passes returned fabricated ones — invented SR names under FR3 and FR4, a mislabelled ZCR 4 and ZCR 5, and an SPE 5 that does not exist. Every identifier on this page was subsequently read off a standard's own table of contents, and anything that could not be was left out rather than guessed. A coarser mapping that is correct beats a granular one that is decorated with plausible fiction.
Parts used: 62443-2-1:2024 Edition 2.0 (asset owner security programme, the eight SPEs), 62443-3-3:2013 (the seven foundational requirements), 62443-3-2:2020 (ZCR 1–7, zones and conduits), 62443-4-1:2018 (the eight secure development practices), with 62443-2-3, 62443-2-4:2023 and 62443-4-2:2019 cited at part level where the duty falls on a service provider or a component supplier rather than on you.
Edition 2.0 of 62443-2-1 was published on 7 August 2024 and its foreword says the requirements were revised to “eliminate duplication of an information security management system”. It ships an informative Annex A.4 cross-referencing ISO/IEC 27001. You will hear this summarised as “the new standard was built to map to ISO 27001”.
Two corrections. The foreword never names ISO/IEC 27001, and ISA's own announcement of the edition does not mention it either. And the annex maps to ISO/IEC 27001:2013 — the superseded edition, not the 2022 control set your certificate is against and not the edition ENISA mapped NIS2 to. We therefore did not route this column through that annex. Mapping NIS2 to ISO 2022 to 62443 via a 2013 crosswalk would have been quicker and quietly wrong.
47 of the 49 requirements have a 62443 reference. Requirements 10.2 and 10.4 — background verification and the disciplinary process — have none, because 62443 is a technical and programme standard and does not reach into human resources. ISO 27001 does, via A.6.1 and A.5.28. For those two, the ISO column is the one to use.
Beyond the table, 62443 is silent on the same regulator-facing duties ISO 27001 is silent on, and for the same reason: Article 23's reporting cascade, Article 20's management body accountability and training duty, and the Article 27 registration obligation are legal obligations, not control objectives. A 62443 certificate closes none of them.
The practical three-layer framing for a plant: 62443 for the technical and programme layer, your governance function for the management body duties, and your legal or compliance function for the regulator interface. Nothing on this page collapses those three into one.
Article 21(2)(c) is business continuity, backup management, disaster recovery and crisis management. The Implementing Regulation turns it into section 4 — three requirements on business continuity and disaster recovery, plus crisis management. ENISA maps no continuity standard whatsoever. Every one of its nine columns answers section 4 out of an information security framework.
Look at what section 4 gets from the ISO column: A.5.29 information security during disruption, A.5.30 ICT readiness for business continuity, A.8.13 information backup. Three Annex A controls, roughly a paragraph each, and clause 8.1 for operational planning. That is the entire continuity apparatus ENISA's mapping offers.
ISO 22301:2019 answers the same three requirements with 7 clauses, because in 22301 continuity is the management system rather than one control theme inside it: 8.2 business impact analysis and risk assessment, 8.3 business continuity strategies and solutions, 8.4 business continuity plans and procedures, 8.5 exercise programme, 8.6 evaluation of documentation and capabilities, on top of 8.1.
The difference is not academic and it is where NIS2 continuity programmes usually fail an inspection. A.5.30 tells you to plan ICT readiness against business continuity objectives. It does not tell you how those objectives were derived. 8.2 does: a business impact analysis that produces prioritised activities, recovery time objectives and recovery point objectives, with the disruption tolerances written down and the dependencies identified. Requirement 4.1 of the Implementing Regulation asks for continuity plans based on the results of a business impact analysis. The word is in the regulation. It is not in ISO 27001.
We map at clause x.y and no deeper. The clause 8 titles used here were verified against the published structure of ISO 22301:2019. The sub-sub-clause titles — 8.2.2, 8.4.2 and so on — were not, so they are not used. Same discipline as the 62443 column, same reason.
Clauses 4 to 7, 9 and 10 are the Annex SL harmonised management-system clauses, shared verbatim in structure with ISO 27001, ISO 42001 and the rest. If you already hold an ISO 27001 certificate, those clauses are largely satisfied by the system you are already running. The work that is genuinely new is clause 8.
26 of the 49 requirements have an ISO 22301 reference and 23 have none. That is the correct result, not a defect. A BCMS has nothing to say about cryptography, multi-factor authentication, network segmentation or vulnerability handling, and a column that claimed otherwise would be padding.
Read it the other way round: the clusters where 22301 lights up are section 4 in full, the impact side of section 2's risk assessment, section 3's incident handling and communication, section 12's asset criticality, and section 13's environmental and physical threats. Those are the places where an information security framework answers thinly and a continuity framework answers properly.
And as with 62443, a 22301 certificate closes none of the Article 23 reporting duties, the Article 20 management body duties or the Article 27 registration obligation. Continuity is a capability. Those are legal obligations.
If you already run an ISMS, this is the direction you actually need. Every one of the 93 ISO/IEC 27001:2022 Annex A controls, with the NIS2 requirements it serves. Controls shown in grey are not referenced anywhere in ENISA's mapping — which does not make them optional under ISO 27001, only absent from this correlation.
The Annex requirements above exist to give these ten measures operational content. This is the directive's own wording.
Text of Directive (EU) 2022/2555, Article 21(2), as published on EUR-Lex.
These are the NIS2 obligations with no Annex A equivalent — not because the mapping is incomplete, but because they are duties owed to a regulator rather than security controls. A perfect ISMS leaves every one of them open, and no other column in the table closes them either.
In-scope entities must register, provide and maintain a defined set of details, and keep them current. ISO 27001 has no concept of registering with a regulator at all.
An early warning within 24 hours of becoming aware of a significant incident, a fuller notification within 72 hours, and a final report within one month, to a named CSIRT or competent authority.
Article 20 requires the management body to approve the risk management measures, oversee their implementation, and be capable of being held liable for failing to do so. ISO 27001 clause 5 asks for leadership and commitment. It creates no personal liability.
Members of the management body must undergo training to acquire sufficient knowledge and skills to identify risks and assess management practices. A.6.3 covers staff awareness. It does not reach the board as a legal obligation on the individuals.
A.5.19–A.5.22 cover supplier relationships well. Article 21(3) adds something ISO does not contemplate: entities must take into account the results of EU-level coordinated security risk assessments of critical supply chains.
An ISMS protects the scope you define. NIS2 defines your scope for you, by sector and size, and adds entities regardless of size. An ISO 27001 scope statement drawn too narrowly is a common and expensive finding.
You will see that number, or something near it, on a lot of vendor pages. We looked for the calculation behind it. There isn't one. The figure recurs across at least eight vendors and consultancies, several of which describe it themselves as a rule of thumb, and no regulator or standards body has published a percentage at all. ENISA, which is the only body to have published an actual mapping, explicitly declines to assess coverage.
So we are not going to give you a number. The list above is the honest version of the same answer, and it is more useful, because you can act on a list.
Reproducing a regulator's table means saying exactly what you changed. Four things, and then two additions:
Two columns are additions, not reproductions. ENISA's table has nine framework columns. This page has eleven. The ISA/IEC 62443 and ISO 22301 columns are NexGenio's own work — no regulator or standards body has published either mapping — and they are marked ours on every row, rendered in a separate tinted block, and listed separately in the framework legend. They carry none of ENISA's authority, and the reasoning behind both, including where each stops, is set out in full above.
The Article 21(2) linkage in each requirement header is ours, derived from the Annex's own wording — each requirement opens “For the purpose of Article 21(2), point (x) of Directive (EU) 2022/2555”. The plain-language line under each requirement title is ours too, and is a summary rather than a substitute for the requirement text.
Found something wrong? Tell us and we will correct it and say so here.
Sourced from ENISA's mapping table version 1.1 (10 July 2025) and Commission Implementing Regulation (EU) 2024/2690. This page is reviewed when either source is revised. Last reviewed 16 September 2026.
A short call establishes which of the 49 requirements actually apply to you, what your existing framework already covers, and what is genuinely missing. From there the Baseline Check gives you something you can take to your board.
Book a scoping call