Most NIS2-versus-ISO-27001 mapping tables you can find online share one weakness: they pair "Article 21" with "Annex A" at the headline level and stop. Article 21 has ten distinct measure categories in paragraph 2, points (a) through (j). Annex A of ISO 27001:2022 has 93 controls across four themes. A mapping that does not say which subpoint pairs with which control is a diagram, not a working document. You cannot hand it to an auditor, and you cannot use it to find your gaps.
This is the version we use. Every pairing below resolves to the actual text of the NIS2 article it cites, grounded through the Ansvar gateway against the NIS2 corpus (Directive (EU) 2022/2555, CELEX 32022L2555). Where ISO genuinely covers a measure, we say so and name the control. Where ISO falls short — and there are three real gaps — we say that too, because pretending an ISO certificate closes them is how organisations walk into a NIS2 inspection unprepared.
What NIS2 Article 21 actually requires#
Article 21(1) sets the standard: essential and important entities must take "appropriate and proportionate technical, operational and organisational measures" to manage risk to their network and information systems, judged against the state of the art and the cost of implementation, scaled to the entity's exposure, size, and the likelihood and severity of incidents. That proportionality clause matters — it is why a small important entity and a large essential one can both be compliant with different control depth.
Article 21(2) then makes it concrete. The measures must follow an all-hazards approach and include at least ten categories:
- (a) policies on risk analysis and information system security
- (b) incident handling
- (c) business continuity, including backup management, disaster recovery, and crisis management
- (d) supply chain security, including the security of relationships with direct suppliers and service providers
- (e) security in network and information systems acquisition, development, and maintenance, including vulnerability handling and disclosure
- (f) policies and procedures to assess the effectiveness of the risk-management measures
- (g) basic cyber hygiene practices and cybersecurity training
- (h) policies and procedures on the use of cryptography and, where appropriate, encryption
- (i) human resources security, access control policies, and asset management
- (j) the use of multi-factor authentication or continuous authentication, and secured voice, video, text, and emergency communications where appropriate
That "at least" is load-bearing. The list is a floor, not a ceiling. An implementing act under Article 21(5) already adds technical and methodological detail for DNS providers, cloud and data-centre operators, managed service providers, and several other digital-infrastructure categories — so for those sectors the floor is higher and more specific than the ten bullets above.
The clause-by-clause mapping#
Here is the working table. Each row names the ISO 27001:2022 Annex A control, the NIS2 article subpoint it satisfies, and whether the coverage is full or partial. "Full" means an organisation implementing that control, evidenced, would satisfy the measure for audit. "Partial" means the control contributes but does not by itself discharge the obligation.
| ISO 27001:2022 Annex A | NIS2 article | Coverage | Why |
|---|---|---|---|
| A.5.1 Policies for information security | Art. 21(2)(a) | Full | 21(2)(a) explicitly requires policies on risk analysis and information system security |
| A.5.2 Information security roles and responsibilities | Art. 20, Art. 21 | Full | Art. 20 requires management-body accountability; Art. 21 requires the governance framework |
| A.5.23 Information security for use of cloud services | Art. 21(2)(d) | Partial | 21(2)(d) supply chain security covers cloud as a service-provider relationship |
| A.5.29 Information security during disruption | Art. 21(2)(c) | Full | 21(2)(c) requires business continuity and crisis management |
| A.5.30 ICT readiness for business continuity | Art. 21(2)(c) | Full | 21(2)(c) explicitly names backup management, disaster recovery, crisis management |
| A.6.8 Information security event reporting | Art. 23 | Full (process only) | Art. 23 requires incident notification — see the gap section on the timeline |
| A.8.2 Privileged access rights | Art. 21(2)(i) | Partial | 21(2)(i) requires access control policies; privileged access is one slice |
| A.8.5 Secure authentication | Art. 21(2)(j) | Full | 21(2)(j) explicitly requires multi-factor or continuous authentication |
| A.8.8 Management of technical vulnerabilities | Art. 21(2)(e) | Full | 21(2)(e) requires vulnerability handling and disclosure |
| A.8.16 Monitoring activities | Art. 21(2) | Partial | Security monitoring is implied by the all-hazards risk-management duty |
| A.8.24 Use of cryptography | Art. 21(2)(h) | Full | 21(2)(h) explicitly requires cryptography and encryption policies |
| A.8.25 Secure development life cycle | Art. 21(2)(e) | Partial | 21(2)(e) covers security in acquisition and development |
A few observations that only fall out of mapping at the subpoint level.
Article 21(2)(j) is the most specific technical requirement in the whole measure list — it names multi-factor authentication by name. ISO's A.8.5 (secure authentication) maps cleanly, but note the direction of the obligation: NIS2 tells you what (MFA), ISO tells you how well (the control objective). You need both. The control gives you the implementation practice; the article gives you the non-negotiable that it must exist "where appropriate."
Article 21(2)(c) maps to two ISO controls, not one. A.5.29 (information security during disruption) and A.5.30 (ICT readiness for business continuity) together cover the backup, disaster-recovery, and crisis-management triad the article names. Mapping (c) to a single continuity control under-evidences it.
Article 21(2)(f) — the requirement to have policies and procedures to assess the effectiveness of your own measures — has no crisp single Annex A partner. It is the meta-control. In practice you evidence it with your ISO management-system clauses (the Plan-Do-Check-Act machinery outside Annex A) plus A.5.35 and A.5.36 (independent review and compliance), which is exactly the kind of seam a headline-level table hides.
If you want to run these pairings yourself rather than trust the table, point your MCP client at the gateway and ask it to fetch each provision. The lookup that grounds the (j) row is get_provision(jurisdiction='EU', law='NIS2', article='21'); the corpus returns the verbatim text and you can read subpoint (j) directly. Our gap analysis workflow does this fan-out automatically — it walks each Article 21(2) subpoint, maps your declared controls, and flags the ones with no evidence.
Gap one: the reporting clock (Article 23)#
This is the gap that catches people. ISO 27001:2022 has A.6.8, "information security event reporting." It requires you to have a mechanism for reporting security events through appropriate channels in a timely manner. An auditor checks that the process exists.
NIS2 Article 23 is a different animal. It sets a legal timetable to an external recipient. Under Article 23(4), for a significant incident an essential or important entity must submit:
- an early warning within 24 hours of becoming aware of the incident, flagging whether it looks malicious or could have cross-border impact (Article 23(4)(a))
- a fuller incident notification within 72 hours, with an initial severity and impact assessment and any indicators of compromise (Article 23(4)(b))
- a final report within one month of that notification, with a detailed description, the root cause, and the mitigations applied (Article 23(4)(d))
The recipient is your national CSIRT or competent authority — not your internal ticket queue. And a "significant incident" has a statutory definition in Article 23(3): one that has caused or could cause severe operational disruption or financial loss, or considerable material or non-material damage to others.
A.6.8 gives you the reporting capability. It does not give you the clock, the threshold, or the external channel. You map the control to the article for the process, then build the 24h/72h/one-month workflow and the CSIRT notification path as separate, NIS2-specific machinery. An ISO certificate is silent on whether you can actually hit a 24-hour wall at 2 a.m. on a Sunday. We model exactly this timeline as a workflow so the clock and the notification draft are generated from the incident facts, with the Article 23 citation attached — see how the platform turns an obligation into a cited workflow.
Gap two: management liability and training (Article 20)#
ISO 27001 assigns roles. A.5.2 (information security roles and responsibilities) makes sure someone owns each control. The management system requires leadership commitment. But ISO does not make a named director personally liable for a control failure, because a certification scheme cannot — liability is a matter of law.
NIS2 Article 20 can. Article 20(1) requires member states to ensure that the management bodies of essential and important entities approve the cybersecurity risk-management measures, oversee their implementation, and can be held liable for the entity's infringements of Article 21. That is personal accountability at board level written into the directive.
Article 20(2) adds a second duty that no Annex A control captures: members of the management body are required to follow training so they can identify risks and assess cybersecurity practices, and entities are encouraged to extend similar training to staff. ISO's A.6.3 covers security awareness, education, and training for personnel generally — but Article 20(2) puts a specific training obligation on the directors themselves.
So A.5.2 maps to Article 20 for the roles dimension, and A.6.3 maps to the staff-training dimension. Neither closes the board-liability gap or the mandatory director-training gap. Those are obligations you discharge through governance and minuted board approval, not through a control implementation an auditor ticks.
Gap three: supply chain depth (Article 21(2)(d) and 21(3))#
The mapping table pairs supply chain with A.5.23 and the supplier-relationship controls, and marks it partial. Here is why partial is the honest answer.
ISO's supplier controls — A.5.19 through A.5.22, plus A.5.23 for cloud — establish that you manage information security in supplier relationships, agree it in contracts, and monitor it. Good practice, and it maps to the surface of Article 21(2)(d).
But NIS2 goes deeper in Article 21(3). When deciding which supply chain measures are appropriate, entities must take into account the vulnerabilities specific to each direct supplier, the overall quality of each supplier's products and cybersecurity practices including their secure development procedures, and — this is the part with no ISO analogue — the results of the coordinated security risk assessments of critical supply chains carried out at Union level under Article 22(1).
That Article 22(1) hook means your supply chain due diligence is not purely internal. It is supposed to ingest EU-level critical-supply-chain risk assessments and reflect them in your supplier decisions. No Annex A control points you at an external EU risk assessment, because that mechanism lives in the directive, not the standard. You can be fully conformant with A.5.19–A.5.23 and still under-deliver on Article 21(3) if you have not built the supplier-specific, assessment-aware diligence the article demands.
Why "certified" is not "compliant"#
An ISO 27001:2022 certificate is strong evidence. For most of Article 21(2) — points (a), (c), (e), (h), (i), (j) especially — a maintained Annex A control set, evidenced, is exactly what a NIS2 supervisor wants to see. We are not arguing the certificate is worthless. The opposite: it does most of the heavy lifting on the technical and organisational measures, and re-using it as evidence saves real work.
The argument is narrower and it matters. Three NIS2 obligations sit outside the standard by construction:
- Article 23's reporting clock is a legal timetable to an external authority. A.6.8 gives you the process, not the 24h/72h/one-month obligation or the CSIRT channel.
- Article 20's management liability and director training are accountability and governance duties a certification scheme cannot impose. A.5.2 and A.6.3 cover roles and staff awareness, not board liability.
- Article 21(3)'s supplier-specific, assessment-aware diligence goes beyond the generic supplier-relationship controls and reaches into Article 22(1)'s EU-level assessments.
If your NIS2 readiness plan is "we have ISO 27001, we're covered," those three are where an inspection finds daylight. The fix is not to throw out the certificate — it is to map it honestly, claim coverage only where the control genuinely discharges the measure, and build the three gaps as named, NIS2-specific work with the article citation attached to each.
Running this yourself#
Every article reference in this post resolves to live corpus text. If your AI client speaks MCP, you can reproduce the whole mapping:
- Connect your client to the gateway —
https://gateway.ansvar.eu/mcp, OAuth 2.1, free tier gives you 100 searches a day. - Ask it to fetch each NIS2 provision: Article 20, Article 21, Article 23. The corpus returns verbatim text with citation metadata, so you read the subpoints yourself rather than trusting a summary.
- For the cross-framework view, the gateway reaches the EU regulations corpus (61 regulations, 4,054 articles) alongside 262 security frameworks — so the same session that reads NIS2 Article 21 can pull the matching ISO Annex A control and you map them side by side.
The pairings in this post are not a frozen spreadsheet. They are grounded against the corpus, which means when an implementing act under Article 21(5) lands new sectoral technical requirements, or the standard's controls shift, the mapping is re-grounded against the new text rather than hand-patched. That is the difference between a mapping table that was true the day someone wrote it and one you can trust on the day you need it.
If you are scoping NIS2 readiness from an existing ISO 27001 programme, our gap analysis starts from your declared controls and walks each Article 21(2) subpoint, marking the ones with evidence, the ones partially covered, and the three structural gaps above — with the article citation on every finding. The certificate is your head start. The gaps are the work the certificate was never going to do for you.