ENISA's official mapping ties 48 of the 2024/2690 Annex's 49 requirement headers to ISO 27001:2022 Annex A controls — here is the full crosswalk as normalized CSV, the caveat ENISA attached to it, and where the real work hides below header level.
ENISA's official mapping ties 48 of the 2024/2690 Annex's 49 requirement headers to ISO 27001:2022 Annex A controls — here is the full crosswalk as normalized CSV, the caveat ENISA attached to it, and where the real work hides below header level.
The "NIS2 module" on a digital-infrastructure company's renewal quote is, materially, two public documents: Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024, and a 35 KB spreadsheet ENISA published in June 2025. The regulation turns the measure list in NIS2 Art. 21(2) into written-out technical requirements for eleven classes of entities. The spreadsheet maps each requirement header to ISO/IEC 27001:2022 clause and control IDs. This post publishes the crosswalk between the two as a normalized, machine-readable CSV. The headline numbers, derived by script from ENISA's mapping table: of its 49 data rows, 48 map to at least one Annex A control (98.0%), one maps to management-system clauses only, and zero are unmapped. If you hold an ISO 27001:2022 certificate, the concordance layer of the module you are being quoted is public and nearly complete. What remains is harder than a spreadsheet, and the vendor doesn't own it either.
Article 1 names the regulation's audience exactly:
"This Regulation, with regard to DNS service providers, TLD name registries, cloud computing service providers, data centre service providers, content delivery network providers, managed service providers, managed security service providers, providers of online market places, of online search engines and of social networking services platforms, and trust service providers (the relevant entities) lays down the technical and the methodological requirements of the measures referred to in Article 21(2) of Directive (EU) 2022/2555 and further specifies the cases in which an incident shall be considered to be significant as referred to in Article 23(3) of Directive (EU) 2022/2555."
Eleven entity classes. Anyone not on that list is outside 2024/2690's scope: NIS2 Art. 21 still reaches essential and important entities generally, through national implementing law, but the Annex below binds only the listed classes. The list comes from NIS2 Art. 21(5), which required the Commission to adopt implementing acts for exactly these providers by 17 October 2024; 2024/2690 is that act, adopted on the deadline day.
Article 2(1) does the keying:
"For the relevant entities the technical and methodological requirements of cybersecurity risk-management measures referred to in Article 21(2), points (a) to (j), of Directive (EU) 2022/2555 are set out in the Annex to this Regulation."
The Annex is 13 numbered sections, each heading carrying the Art. 21(2) point it implements:
The correspondence is many-to-many. Two sections implement point (a). Point (i) ("human resources security, access control policies and asset management" in the directive's words) is served by four sections: 10, 11, 12 and 13. Section 11 keys to two points at once; section 13 to three. Thirteen sections over ten points, counted from the heading parentheticals in the regulation text.
One structural fact for the rest of this post: below the section level, requirements carry x.y headers (3.2 Monitoring and logging) and are then written out at x.y.z depth (3.2.1 through 3.2.7). The mapping we're about to look at stops at x.y. The regulation does not.
ENISA published its Technical Implementation Guidance for 2024/2690 on 26 June 2025: a 170-page guidance PDF, version 1.0, plus a companion mapping table in Excel. The ISO mapping exists only in the Excel file. The guidance says so itself (printed p. 10): "The mapping to standards and frameworks is available on the ENISA website in Excel format."
The PDF contains no mapping table of its own. There is not a single "Table N" caption in the whole document, and every in-text reference to a mapping table is a footnote. Nine of those footnotes are consultation-draft leftovers: footnotes (33), (49), (51), (54), (61), (66) and (72) still read "in the mapping table at the end of this section", and (52) and (56) refer to "the standards in the mapping table", pointing at tables that follow no section in the published file. A slide citing "the mapping table in the ENISA guidance" is citing a table that does not exist; the spreadsheet is the source.
The spreadsheet also moves. The file the landing page links today is Mapping table version 1.2, uploaded September 2025; the June release was version 1.0. Version 1.2 carries a changelog: v1.1 (10 July 2025) "Removed references to older version of ISO (A9)in measures 11.1, 11.2, 11.3" (spacing as printed), and v1.2 (21 August 2025) corrected only the Belgian CyFun column. Running our derivation on v1.0 and on v1.2 produces a byte-identical crosswalk, because the A9 references v1.1 deleted are the same ones our validation had already excluded; more on that at row 11.1 below. A file that changes under a stable landing page is the argument for deriving your artifact with a re-runnable script instead of typing it from whatever version you happened to download.
ENISA also tells you what the mapping is not. Printed p. 10 of the guidance:
"The mapping 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."
And printed p. 9, on the guidance as a whole: "The guidance, examples of evidence and tips are non-exhaustive. Their partial or complete implementation does not assume compliance or conformity with the requirements of the regulation." The mapping "was done only to horizontal standards and for specific topics" (also printed p. 10). Read together, the honest use of the crosswalk is this: it tells a certified holder which evidence to pull first. It does not tell anyone that a certificate discharges the regulation.
The same sheet also maps to NIST CSF 2.0, ETSI EN 319 401, CEN/TS 18026:2024 and five national frameworks; those columns are out of scope here.
Below is the full mapping, all 49 rows, as CSV. The schema: point_no and title_2690 come from ENISA's mapping table and match the regulation's Annex headers. iso_clauses holds ISO/IEC 27001:2022 management-system clause references, annex_a_controls holds Annex A control IDs (per the standard's licensing: IDs only, no ISO text anywhere in this artifact). evidence_example is my own-words condensation, ten words or fewer, of the first bullet in the ENISA guidance's EXAMPLES OF EVIDENCE block for that point; it derives from ENISA's text only.
coverage is mechanical: mapped means at least one Annex A control reference, clauses-only means management-clause references and nothing else, none means an empty ISO cell. There is deliberately no class named "full", because a class named "full" would assert the equivalency ENISA just disclaimed.
The counts, derived from the v1.2 mapping table by a script that ships with this post's source artifacts alongside the raw cell values: mapped 48 of 49 (98.0%), clauses-only 1 of 49 (row 7.1), none 0. Ten of the 49 rows carry at least one management-clause reference. There is no 80/20 here; at header level, nearly everything in the Annex lands in territory a certified holder already owns evidence for.
Normalization note: 13 of the 49 rows were repaired before the IDs were machine-usable. A Greek capital Α (U+0391) stands in for the Latin A in references across rows 2.1 and 11.1 through 11.7; two references are missing dots (A5.7, A5.29); five carry stray internal spaces (A.5 .24, A. 5.30, A. 7.11, A. 7.3, A. 7.1). All repairs are ours, logged, with raw values preserved; none of this is ENISA's rendering. Four references were flagged and excluded rather than fixed: 5.28 in row 10.4, which is not a canonical clause number in the 2022 edition and is plausibly a mis-keyed control reference (still present in v1.2; left out pending a human call), and A9/A.9 in rows 11.1 to 11.3, identifiers from the 2013 edition of the standard, which ENISA itself removed in v1.1.
One line restated before the data, because it belongs next to the data: this mapping "should not be interpreted as a measure of equivalency" (ENISA guidance, printed p. 10).
Seven rows show the texture. For each: what the regulation's Annex requires, what the mapping points at, what ENISA lists as evidence.
Row 1.1: the clean match. The security policy requirement maps to clauses 5.2 and 9.3 plus controls A.5.1, A.5.4 and A.5.36 (policy, management responsibility, policy compliance; my labels, not ISO's). Annex point 1.1.1 lists eleven mandatory policy elements, (a) through (k), down to "(k) indicate the date of the formal approval by the management bodies of the relevant entities". Point 1.1.2: "The network and information system security policy shall be reviewed and, where appropriate, updated by management bodies at least annually and when significant incidents or significant changes to operations or risks occur. The result of the reviews shall be documented." ENISA's first evidence item (printed p. 14) is the "documented policy on the security of network and information systems which contains the elements required by points 1.1.1 (a) to 1.1.1 (k)". A certified holder has the policy and the review records. The check worth running is (a)-through-(k) completeness; an approval date printed in the document itself is the kind of element an existing policy misses.
Row 2.1: the normalization exhibit. The raw ISO cell, identical in v1.0 and v1.2: 6.1, 6.1.2, 6.1.3, 6.2, 8.2, 8.3, A5.7, Α.5.19, Α.5.20, Α.5.21. One missing dot and three Greek capital Α's in one cell. Normalized: six clause references plus A.5.7, A.5.19, A.5.20, A.5.21. The requirement (2.1.1): "establish and maintain an appropriate risk management framework", "perform and document risk assessments and, based on the results, establish, implement and monitor a risk treatment plan", with results and residual risks "accepted by management bodies". ENISA's evidence (p. 21): documented framework, documented assessment results, treatment plan, approval records. This is ISMS core territory, and the mapping is dense here because the overlap is real.
Row 3.2: mapped, and narrower than the text. Four controls: A.5.28, A.8.15, A.8.16, A.8.17 (evidence collection, logging, monitoring, clock sync; my labels). Now the regulation. Point 3.2.3 requires a logging asset list "based on the results of the risk assessment carried out pursuant to point 2.1" and, where appropriate, twelve categories of logs, from "relevant outbound and inbound network traffic" to "activation, stopping and pausing of the various logs". Point 3.2.6: the entities shall "ensure that monitoring and logging systems are redundant. The availability of the monitoring and logging systems shall be monitored independent of the systems they are monitoring." ENISA's evidence block (p. 36) opens with "Procedures in place." and "Tools in place." The four control IDs are real coverage, but this row is one CSV line and seven sub-points of regulation. Whether your logging evidence answers for redundant log systems and monitoring-of-the-monitoring cannot be read off any header-level table. That is what partial looks like: demonstrated by the requirement text, invisible in the mapping.
Row 5.1: new artifacts inside a mapped row. Controls A.5.19, A.5.20, A.5.21, A.8.30. Point 5.1.1: in the supply chain security policy, "the relevant entities shall identify their role in the supply chain and communicate it to their direct suppliers and service providers." ENISA's second evidence bullet (p. 66) names the artifact: "Evidence (e.g. email, contract or announcements) of the communication of the role of the entity to the direct suppliers and service providers, where possible." That is a specific, dated record per supplier relationship; whether it exists in a certified ISMS is a file-by-file question. Point 5.1.4 then lists eight items of mandatory contract content where appropriate, including "(e) the right to audit or right to receive audit reports" and supplier incident-notification duties. And 5.1.2(d) writes supplier-selection criteria that include "the ability of the relevant entities to diversify sources of supply and limit vendor lock-in, where applicable". A regulation that puts lock-in into the supplier-selection calculus is worth noticing in a post about renewal quotes.
Row 7.1: the only clauses-only row. ISO cell: 6.2, 9.1, 9.3. Zero Annex A controls; the counterpart is ISMS machinery (objectives, measurement, management review; my labels). The requirement: "establish, implement and apply a policy and procedures to assess whether the cybersecurity risk-management measures taken by the relevant entity are effectively implemented and maintained", with point 7.2 requiring the entities to determine what gets monitored and measured, by which methods "to ensure valid results", when, and by whom. ENISA's evidence (p. 107): a documented effectiveness-assessment policy and procedures. For a certified holder this is the measurement programme, in policy form. It is the one row where the crosswalk hands you no control ID at all, and it still describes something an operating ISMS produces.
Row 11.1: the A.9 story. The v1.0 raw cell: Α.5.15, A.7.2, Α.8.3, Α.8.21, A9. Three Greek Α's, and one reference, A9, that is not an identifier in ISO/IEC 27001:2022 at all: the 2022 Annex A families run A.5 through A.8, and A.9 belongs to the 2013 edition. Our derivation's validation layer excluded it before ENISA's changelog was on record; the v1.1 changelog then confirmed the read: "Removed references to older version of ISO (A9)in measures 11.1, 11.2, 11.3". The substance of the row is clean: point 11.1.1 requires the entities to "establish, document and implement logical and physical access control policies", and ENISA's evidence (p. 130) is the access control policy documents. Section 11 is also the many-to-many exhibit from earlier: its heading keys to Art. 21(2) points (i) and (j) at once. The row's history, though, is the strongest argument in this post for validating identifiers against the standard's actual ID scheme instead of trusting any file, including the regulator's.
Row 13.1: where the work is genuinely new. One control: A.7.11 (supporting utilities; my label). The requirement (13.1.1): "prevent loss, damage or compromise of network and information systems or interruption to their operations due to the failure and disruption of supporting utilities." Point 13.1.2 then specifies, where appropriate: "(a) protect facilities from power failures and other disruptions caused by failures in supporting utilities such as electricity, telecommunications, water supply, gas, sewage, ventilation and air conditioning" and "(e) conclude contracts for the emergency supply with corresponding services, such as for the fuel for emergency power supply". ENISA's evidence (p. 157): a list of supporting utilities with associated risk assessments. For a SaaS running on rented data-centre capacity, emergency-fuel contracts are someone else's evidence. This row is where the regulation's own proportionality mechanism earns its keep, covered in the next section.
The residue is not a set of unmapped rows; the derivation found zero of those. It sits in two places. First, granularity: the mapping table stops at x.y headers while the regulation binds at x.y.z depth. Row 3.2 is one line of CSV; points 3.2.1 through 3.2.7 are the obligation. ENISA's caveat says this in terms: the mapping refers to relevant requirements "without assessing whether these fully cover the requirements of the regulation". Second, requirement text that visibly outruns the mapped IDs, as quoted at rows 3.2, 5.1 and 13.1 above. Neither residue lives in the spreadsheet, so neither lives in a module built on the spreadsheet. It is close-reading work against your own evidence, point by sub-point.
For requirements that genuinely do not fit an operation, the regulation prescribes the handling itself. Art. 2(2), third paragraph:
"Where the Annex to this Regulation provides that a technical or methodological requirement of a cybersecurity risk-management measure shall be applied 'where appropriate', 'where applicable' or 'to the extent feasible', and where a relevant entity considers it not appropriate, not applicable or not feasible for the relevant entity to apply certain such technical and methodological requirements, the relevant entity shall in a comprehensible manner document its reasoning to that effect."
"Where appropriate" appears 48 times in the regulation's text, "where applicable" 13 times, "to the extent feasible" 4 times (exact lowercase-string counts; the sentence-initial capitalized occurrences add 4, 1 and 2 more, all inside the Annex); each occurrence inside the Annex is a place where this documentation duty can bite. A certified holder already runs this discipline under another name: it is Statement-of-Applicability reasoning, justified exclusions in writing. The mechanism is familiar even where the requirement is new. That, too, is evidence you already hold, and it sits in the regulation itself rather than in the mapping.
One argument for staying with an incumbent GRC tool is that moving would mean losing the framework mappings configured inside it. For this framework pair, the concordance layer is two public documents and the 49 rows of CSV above, re-derivable by script from ENISA's file in seconds. What sits beyond the concordance is work no vendor owns either: the x.y.z close-reading, the evidence checks row by row, the documented not-applicable reasoning under Art. 2(2). It belongs to your ISMS, and it stays yours wherever the ISMS is operated.
Which leaves one question worth asking, in your voice, not mine:
When your renewal quote included the NIS2 add-on, did anyone show you what's in it beyond the public 2690-to-27001 mapping?
For the directive-level version of this argument, run across NIS2, SOC 2 and the CRA at once, see one control set, three regimes.
Operationally, this crosswalk is a single control-set overlay in devguard: the 49 rows load against the existing ISO 27001:2022 control set, each mapped row pointing at the evidence already attached to its controls, with row 7.1 and the flagged references carrying their own open status instead of a pretended match.
[image: the 2024/2690 crosswalk loaded as a control-set overlay in devguard, filtered to row 7.1 and the flagged references]
The crosswalk is public and normalized now. Pull the mapped-row evidence out of your ISMS this week, read the x.y.z text under the rows that matter for your operation, scope the residue as real work, and take the question above into the renewal call.
Keeping a crosswalk like this alive against your actual control set, rather than inside a vendor's module, is what devguard is built for.
Vadim leads engineering, the architecture, automation, and integrations that let compliance live. He's set on making a serious, audit-grade system genuinely easy to run.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.