Browse how the thirteen NIS2 cybersecurity-requirement areas in Commission Implementing Regulation (EU) 2024/2690 align with eight major control frameworks: ISO/IEC 27001, NIST CSF 2.0, ETSI EN 319 401, CEN/TS 18026:2024, SOC 2 Type II, CIS Controls v8, NIST SP 800-53, and ISO/IEC 22301.
Four frameworks are sourced directly from ENISA's NIS2 TIG Mapping Table v1.2 (August 2025) — ISO 27001, NIST CSF 2.0, ETSI EN 319 401, and CEN/TS 18026:2024. The granular crosswalk is in ENISA's XLSX file, which also indexes the national frameworks ENISA cites (Belgium, Finland, Greece, Spain, France) — listed for reference under the picker. The other four (SOC 2, CIS Controls v8, NIST 800-53, ISO 22301) are practitioner-curated assessments at the same depth, anchored to their published source standards.
→Jump to supply-chain·NIS2 Article 21(2)(d)A practitioner's navigation aid for the NIS2 cybersecurity-measures regulation, organised by the thirteen thematic areas in Implementing Regulation 2024/2690. At EU level, that regulation binds only the provider types it names: DNS, TLD registries, cloud, data centre, CDN, managed and managed security service providers, online marketplaces, search engines, social networks and trust services. Austria goes further: since 2 October 2026, its NISV 2026 ordinance applies the thirteen areas to every essential and important entity. For everyone else, national law sets the detail, and the thirteen areas remain a useful reference.
If your organisation already runs an ISMS aligned to ISO 27001 or NIST CSF, find the NIS2 area, read the summary, scan the mapped controls, then jump to ENISA's XLSX for the exact requirement-level mapping.
ENISA's own note: the mapping should not be interpreted as a measure of equivalence between frameworks. Standards address the same concerns with different language and depth. Reviewer judgement still required — for every control, every audit.
Pick the framework you run today. We'll show you which NIS2 thematic areas your existing controls cover well, which ones are partially covered with NIS2-specific gaps to close, and which ones are net-new work. Click any area to jump down to its full forward mapping below.
Belgian national cybersecurity framework published by the Centre for Cybersecurity Belgium (CCB). Built on NIST CSF, with a starting level (Small) and three assurance levels (Basic / Important / Essential).
Finnish national cyber-maturity self-assessment tool published by Traficom (NCSC-FI). NIST CSF-aligned, used by Finnish entities for organisational cybersecurity benchmarking against NIS2 expectations.
Greek national NIS2-implementation instrument issued in 2025. Codifies cybersecurity-measure baselines for NIS2-scope entities in Greece. Refer to the Greek NCSA / national gazette for the authoritative text.
Spanish national security scheme governing public-sector and contracted IT systems. 73 security measures across organisational, operational, and protective categories, at three levels (Low / Medium / High). Comparable in scope to ISO 27001 Annex A; widely adopted beyond the strict public-sector mandate.
ENISA's table carries a French column labelled only "FR": requirement references tagged for important (IE) and essential (EE) entities. The table does not name the source document or its edition. France's national cybersecurity authority is ANSSI (Agence nationale de la sécurité des systèmes d'information).
All entries are reviewer guidance, not a compliance verdict. ISO 27001, NIST CSF 2.0, ETSI EN 319 401, and CEN/TS 18026 derive from ENISA's NIS2 TIG Mapping Table v1.2 (August 2025) and the NIS2 directive itself. The other four are practitioner-curated at the same depth, anchored to their published source standards. National frameworks above are listed for orientation — refer to ENISA's XLSX for the per-control alignment.
Direct or near-direct alignment — your existing controls already address what NIS2 expects here.
A.5.4, A.5.10, A.5.12, A.5.13 cover risk management. NIS2 expectations align directly.
A.5.29, A.5.30, A.8.13, A.8.14 cover BCP, backup, and disaster recovery. Direct alignment.
A.8.25–A.8.32 cover secure development, vulnerability handling, and acquisition. NIS2 SBOM expectations align.
A.6.3, A.8.7, A.8.8 cover awareness, training, and the basic-hygiene baseline. Direct alignment.
A.8.24 covers cryptographic controls. NIS2 does not add framework-specific cryptography requirements beyond this.
A.6.1–A.6.6 cover the joiner / mover / leaver process, terms of employment, and disciplinary handling.
A.5.15–A.5.18 cover access control, identity management, authentication information and access rights; A.8.2 privileged access rights; A.8.5 secure authentication. Annex A doesn't prescribe MFA — A.8.5 asks for secure authentication in line with your access control policy. NIS2 names it: multiple factors or continuous authentication where the asset's classification calls for it (11.7), and strong authentication such as MFA for privileged and system administration accounts (11.3).
A.5.9–A.5.14 cover the asset inventory, acceptable use and handling, return of assets, classification, labelling and information transfer; A.7.10 covers storage media. Two details NIS2 spells out: the inventory also lists your operations and services (12.4.2), and removable media is technically blocked unless there is an organisational reason to use it (12.3.2).
A.7.1–A.7.14 cover physical and environmental security comprehensively.
Your framework touches this area but NIS2 adds specific requirements that may not be covered. Review the note for what to add.
Annex A.5.1–A.5.3 covers the security-policy framework. NIS2 Article 20 adds explicit personal accountability for the management body, mandatory cybersecurity training for them, and oversight obligations — wire those into your governance separately.
A.5.24–A.5.28 cover incident response operations. NIS2 Article 23 adds specific regulator-reporting deadlines (24h early-warning, 72h incident notification, 1-month final report) and the notification route to your national CSIRT or competent authority — these are NIS2-specific and not in the standard.
A.5.19–A.5.23 cover supplier relationships, security in supplier agreements, the ICT supply chain, monitoring of supplier services, and cloud services. NIS2 names inputs Annex A doesn't: the EU's coordinated risk assessments of critical supply chains (Article 21(3)) and, in the Implementing Regulation, selection criteria that include vendor lock-in (5.1.2), listed contract terms such as incident notification, audit rights and subcontracting rules (5.1.4), and a register of direct suppliers (5.2) — which ENISA maps only to A.5.22, supplier monitoring.
A.5.35–A.5.37 cover internal audit and management review. NIS2 Article 23 reporting and competent-authority interaction sit beyond the ISMS — those need their own procedures.
Direct or near-direct alignment — your existing controls already address what NIS2 expects here.
GV.OC (Organisational Context) and GV.PO (Policy) cover the policy framework with explicit governance focus — closer to NIS2 Article 20 expectations than ISO 27001.
GV.RM, ID.RA, ID.IM cover risk management, assessment, and improvement. Strong alignment.
RS.MA, RC.RP, PR.IR cover continuity, recovery, and infrastructure resilience.
GV.SC (Cybersecurity Supply Chain Risk Management) is a dedicated NIST CSF 2.0 category with 10 subcategories — the most explicit alignment with NIS2 Article 21(2)(d) across any major framework. GV.SC-04 (suppliers known and prioritised by criticality) and GV.SC-05 (security requirements in supplier contracts) match the regulation's supplier register and contract terms.
ID.RA, PR.PS, DE.CM cover the secure-development and vulnerability-management lifecycle. SBOM expectations align via PR.PS.
ID.IM and GV.OV cover continuous improvement and oversight. NIS2 regulatory reporting still needs separate operational procedures.
PR.AT (Awareness and Training) and PR.PS (Platform Security) cover the basic-hygiene baseline.
PR.DS (Data Security) covers cryptographic protections for data at rest and in transit.
PR.AA (Identity Management, Authentication, Access Control) and PR.AT cover personnel security broadly.
PR.AA covers identities and credentials (PR.AA-01), authentication (PR.AA-03), and access permissions built on least privilege and separation of duties (PR.AA-05). CSF 2.0 states outcomes, not methods: ENISA maps multi-factor authentication (11.7) to PR.AA-03, and maps nothing in CSF 2.0 to administration systems (11.4).
ID.AM covers inventories of hardware, software and services, suppliers' services and data (ID.AM-01, -02, -04, -07), prioritisation by classification and criticality (ID.AM-05), and managing assets through their life cycle (ID.AM-08). ENISA maps removable media (12.3) to PR.DS-01, data at rest, and maps nothing in CSF 2.0 to returning assets when employment ends (12.5) — cover that in your leaver process.
Your framework touches this area but NIS2 adds specific requirements that may not be covered. Review the note for what to add.
DE.CM, RS, RC cover detection, response, and recovery — well-covered operationally. NIS2 Article 23 reporting deadlines and the notification route to your national CSIRT or competent authority still need separate procedures.
PR.AA-06 and PR.IR cover physical access and infrastructure resilience. NIST CSF treats physical security less granularly than ISO 27001 — for facility-heavy entities, supplement with ISO 27001 Annex A.7.
Direct or near-direct alignment — your existing controls already address what NIS2 expects here.
Policy and statement of applicability requirements are mandatory for TSPs and align with NIS2 Article 20 expectations.
Risk assessment and treatment is mandatory for TSPs (§5).
Business continuity is mandatory for TSPs to keep trust services available.
§7.14 (Supply chain) tracks Annex §5 closely: the TSP's role in the chain, selection criteria that include vendor lock-in and the EU's coordinated risk assessments, security requirements passed on to subcontractors, monitoring of changes in suppliers' practices, and a register of suppliers and their agreements (REQ-7.14.3-11X).
TSP audit cycles are mandatory and align with the effectiveness-monitoring NIS2 expects.
Personnel training and awareness requirements are mandatory for TSP staff.
Cryptographic controls are core to the TSP function — strong alignment, exceeds NIS2 baseline expectations.
Personnel screening, training, and confidentiality requirements are mandatory for TSPs.
§7.4 (Access control) covers least privilege, dedicated administration accounts, strong authentication for privileged accounts, reviews of privileged access, and access changes when people leave or change role. Multi-factor authentication is conditional — where appropriate, by the classification of the systems accessed (REQ-7.4-06X) — the same test 11.7 sets.
§7.3 (Asset management) tracks the regulation closely: an inventory with a classification level for each asset based on confidentiality, integrity, authenticity and availability, availability aligned with recovery objectives, periodic review, return of assets when people leave, and storage media handled through their life cycle. 12.3's removable media rules — a technical block, no self-execution, malware scanning — are not spelled out.
TSP physical security requirements (secure rooms for key material, environmental controls) are detailed and exceed NIS2 baseline.
Your framework touches this area but NIS2 adds specific requirements that may not be covered. Review the note for what to add.
TSP-specific incident handling is required, but the NIS2 Article 23 notification timing towards the national CSIRT or competent authority needs separate wiring.
Limited scope — TSP-specific software requirements only. For broader NIS2 SDLC obligations, supplement with ISO 27001 A.8.25–A.8.32 or NIST CSF PR.PS.
Direct or near-direct alignment — your existing controls already address what NIS2 expects here.
A cloud-service cybersecurity policy is required at all three assurance levels — direct alignment with NIS2 expectations.
Risk-based assurance levels are the structure of the standard itself — Basic / Substantial / High map to escalating risk treatment depth.
Cloud-service continuity, backup, and recovery are core requirements at all three levels.
Secure development, vulnerability handling, and change management are required at all three levels.
Assurance assessments and continuous review are core to the three-level model.
Basic-hygiene baseline (patching, malware protection, secure configuration, awareness training) is mandatory at the Basic level and onwards.
Cryptographic protection of data at rest and in transit is mandatory across the three levels with escalating key-management depth.
Personnel security, screening, and confidentiality requirements are required for cloud-service staff.
ENISA's table maps all seven points of §11 to CEN/TS 18026 requirements — mostly its IAM series — multi-factor authentication (11.7) included.
ENISA's table maps all five points of §12 to CEN/TS 18026 requirements, mostly its AM series: classification, handling, removable media, the inventory, and return of assets when employment ends.
Data-centre physical security, environmental controls, and supporting utilities are required for cloud-infrastructure providers — exceeds NIS2 baseline at higher assurance levels.
Your framework touches this area but NIS2 adds specific requirements that may not be covered. Review the note for what to add.
Incident-handling requirements are mandatory across the three levels. NIS2 Article 23 reporting deadlines (24h / 72h / 1-month, each to your national CSIRT or competent authority) still need separate procedures.
ENISA's table maps both points of §5 — the supply chain security policy and the directory of suppliers — to CEN/TS 18026 requirements, mostly its PM series. Check two NIS2-specific inputs against them: the EU's coordinated risk assessments (Article 21(3)) and the contract terms listed in 5.1.4.
Direct or near-direct alignment — your existing controls already address what NIS2 expects here.
CC3.0 (Risk Assessment) covers risk identification, analysis, and mitigation. Direct alignment with NIS2 expectations.
A1.0 (Availability TSC) explicitly mandates BCP, DR, and capacity management. Direct alignment.
CC8.0 (Change Management) covers system development and change control. Direct alignment with NIS2 SDLC expectations.
CC4.0 (Monitoring Activities) plus the SOC 2 Type II audit cycle itself produce continuous-effectiveness evidence — exceeds the NIS2 baseline.
CC6.0 (Logical and Physical Access Controls) and the Confidentiality TSC cover cryptographic protection of data at rest and in transit.
CC1.0 covers personnel security including onboarding, background checks, and termination.
CC6.1–CC6.3 cover logical access, registering and removing users, and access based on roles with least privilege and segregation of duties. The criteria don't name MFA, so read the report's control descriptions to see where it is enforced (11.7) and how privileged accounts are handled (11.3).
Your framework touches this area but NIS2 adds specific requirements that may not be covered. Review the note for what to add.
CC1.0 (Control Environment) covers governance and policies. NIS2 Article 20 personal accountability for management bodies is not addressed in the TSC.
CC7.0 (System Operations) covers incident response operations. NIS2 Article 23 reporting deadlines (24h / 72h / 1-month, each to your national CSIRT or competent authority) are NIS2-specific and outside the SOC 2 scope.
CC9.2 covers assessing and managing risks from vendors and business partners — the core of NIS2 Article 21(2)(d). The specifics NIS2 names sit outside the criteria: a register of direct suppliers, listed contract terms such as incident notification and audit rights, and the EU's coordinated risk assessments.
CC1.0 covers awareness and training as part of the control environment. NIS2 expects more specific basic-hygiene baselines that may not be fully captured.
CC6.5 covers disposing of assets so their data can't be recovered, and CC6.7 covers moving and removing information. Inventory, classification and removable media appear only as points of focus (CC6.1, CC6.7), which a SOC 2 examination doesn't have to assess one by one — check the report. Returning assets when employment ends (12.5) isn't addressed.
CC6.4 covers physical access controls for facilities housing in-scope systems. Less granular than ISO 27001 A.7 — for facility-heavy entities, supplement.
Direct or near-direct alignment — your existing controls already address what NIS2 expects here.
Control 17 (Incident Response and Management) provides comprehensive incident-response procedures. NIS2 Article 23 reporting deadlines still need separate wiring.
Control 15 (Service Provider Management) covers an inventory of service providers (15.1), their classification, security requirements in contracts (15.4), assessment and monitoring. NIS2 adds the EU's coordinated risk assessments of critical supply chains (Article 21(3)).
Control 16 (Application Software Security) covers secure development and vulnerability management.
CIS is BUILT around basic cyber hygiene. Implementation Group 1 (IG1) IS the baseline NIS2 Article 21(2)(g) calls for — the most explicit framework alignment with NIS2's basic-hygiene expectation.
Control 3 (Data Protection) covers encryption at rest and in transit, plus cryptographic key management.
Control 5 (Account Management) and Control 6 (Access Control Management) cover accounts, granting and revoking access, and centralised access control. Safeguards 6.3–6.5 require MFA for externally exposed applications, remote network access and administrative access — the remote and administrative access recital 23 of the regulation singles out.
Control 1 covers the enterprise asset inventory and Control 3 the data side: a data management process, a data inventory and a classification scheme (3.1, 3.2, 3.7). For removable media, 10.3 and 10.4 disable auto-run and scan media for malware — the steps 12.3 asks for — and 3.9 encrypts data on it. Returning assets when employment ends (12.5) is an HR process CIS doesn't cover.
Your framework touches this area but NIS2 adds specific requirements that may not be covered. Review the note for what to add.
Risk-prioritisation is implicit in the IG1/IG2/IG3 structure, but CIS doesn't mandate a formal risk-management process. NIS2 expects a documented risk methodology.
Control 11 (Data Recovery) covers backup and recovery. Broader BCP / crisis-management is partial — supplement with ISO 22301 if BCP is critical.
Control 18 (Penetration Testing) covers offensive validation. Broader effectiveness review (audit, KPI/KRI) needs to come from elsewhere.
NIS2 requires this area but the framework you have does not address it. New procedures or controls are needed.
CIS focuses on technical controls; governance and policy framework are outside its scope. Pair with ISO 27001 or NIST CSF for the policy layer.
CIS doesn't address HR security (joiner / mover / leaver, background checks, terms of employment). NIS2 expects this — pair with ISO 27001 or NIST 800-53.
CIS doesn't address physical and environmental security. For facility-heavy entities, supplement with ISO 27001 Annex A.7.
Direct or near-direct alignment — your existing controls already address what NIS2 expects here.
PM family (Program Management) and the policy-and-procedures controls in every other family provide comprehensive policy coverage.
RA family (Risk Assessment) is dedicated to risk management end-to-end. Stronger than most frameworks at this depth.
IR family (Incident Response) is comprehensive — preparation, detection, response, recovery, reporting. NIS2 Article 23 deadline-specific reporting still needs separate procedures.
CP family (Contingency Planning) covers BCP, DR, backup, and continuity testing. Direct alignment.
SR family (Supply Chain Risk Management) was added in Revision 5 specifically and aligns directly with NIS2 Article 21(2)(d). The most explicit supply-chain alignment of any framework, alongside NIST CSF 2.0’s GV.SC category.
SA family (System and Services Acquisition) covers secure development, vulnerability handling, and acquisition. Direct alignment with NIS2 SDLC obligations.
CA family (Assessment, Authorisation, and Monitoring) provides the assessment and continuous-monitoring framework. Exceeds the NIS2 baseline.
AT family (Awareness and Training) and PL family (Planning) cover basic-hygiene baseline and security awareness. Direct alignment.
SC family (System and Communications Protection) provides comprehensive cryptographic and communications-security controls.
PS family (Personnel Security) covers screening, terms, transfers, and termination. Direct alignment.
The AC (Access Control) and IA (Identification and Authentication) families cover access policy, account management, separation of duties (AC-5), least privilege (AC-6) and privileged accounts. IA-2(1) and IA-2(2) require MFA for privileged and non-privileged accounts.
CM-8 (System Component Inventory), RA-2 (Security Categorization) and the MP (Media Protection) family — media use, transport and sanitisation — cover inventory, classification and removable media. PS-4 (Personnel Termination) includes retrieving organisational property when someone leaves.
PE family (Physical and Environmental Protection) is comprehensive on facility, equipment, and supporting-utility security.
Direct or near-direct alignment — your existing controls already address what NIS2 expects here.
This IS what ISO 22301 is for — BCP, DR, crisis management, recovery testing. The most explicit BCP-area alignment with NIS2 §4 of any framework.
Your framework touches this area but NIS2 adds specific requirements that may not be covered. Review the note for what to add.
Clause 8.2 covers business-impact analysis and BCM-specific risk. Broader information-security risk management needs a complementary framework.
Disruption response is in scope (BCP-relevant incidents). Cybersecurity incident response and NIS2 Article 23 reporting are outside scope.
Clause 8.3.4 addresses supply-chain considerations within the BCP context (continuity dependencies on suppliers). Does not cover the full NIS2 21(2)(d) supplier-assurance scope.
Clause 9 (Performance Evaluation) and Clause 10 (Improvement) cover BCMS-specific effectiveness review. Broader cybersecurity effectiveness review needs a complementary framework.
Clause 7.2 covers BCMS-related personnel competence and training only.
BCMS-related physical considerations (alternate sites, recovery facilities). Day-to-day physical security is outside scope.
NIS2 requires this area but the framework you have does not address it. New procedures or controls are needed.
ISO 22301 is BCMS-specific; general information-security policy is outside scope. Pair with ISO 27001 for the policy layer.
Outside scope.
Outside scope.
Outside scope.
Outside scope.
Outside scope.
The cards below summarise each Implementing Regulation thematic area and its prominent control references in ISO/IEC 27001:2022, ISO/IEC 27002:2022, and NIST CSF 2.0. Where ETSI EN 319 401 is in scope, that mapping is shown too. Supply-chain security (Implementing Reg, Annex §5) is highlighted. It is the area Vittnor — Supply Chain Assurance for the mid-market — is built around.
A documented top-level information security policy approved by the management body, reviewed at planned intervals or after material change, and communicated to staff and relevant third parties.
A risk management framework that identifies, analyses, evaluates, and treats cybersecurity risks across people, processes, and technology, with documented risk acceptance criteria and management-body sign-off.
Documented procedures to detect, classify, respond to, and recover from cybersecurity incidents — including the early-warning, incident, and final NIS2 reporting milestones (24 / 72 hours / 1 month).
Backup and recovery policy with tested restoration procedures, business-continuity plans for critical services, and crisis-management arrangements that survive a cyber incident.
Information security in supplier and service-provider relationships. Covers supplier risk-tiering, contract clauses, evidence collection, sub-processor disclosure, and re-review on material change. This is the area Vittnor is built around.
What the directive says“supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers”
NIS2 Directive 2022/2555 · Article 21(2)(d)Read on EUR-Lex
NIST CSF 2.0 added an entire Govern → Supply Chain Risk Management category (GV.SC) — the most explicit alignment between NIST and the NIS2 supply-chain clause across any major framework.
Secure development lifecycle, vulnerability handling, change management, and security in the acquisition of products and services. Includes coordinated vulnerability disclosure and SBOM expectations.
Documented procedures for measuring whether the cybersecurity risk-management measures are working — internal audits, management review, KPI / KRI tracking, and corrective-action loops.
Awareness and training for all personnel including the management body, plus the basic-hygiene baseline — software updates, malware protection, secure default configurations, password discipline.
Cryptographic controls policy — algorithm selection, key management, hardware-backed key storage where required, certificate lifecycle management.
Background checks proportionate to role, terms of employment, joiner / mover / leaver process, return of assets, disciplinary process for security violations.
Access control policies for staff, visitors, suppliers and systems; access rights on need-to-know, least privilege and separation of duties, reviewed at planned intervals; dedicated privileged and system administration accounts; restricted administration systems; unique identities linked to a single person; secure authentication; and multi-factor or continuous authentication where the asset's classification calls for it (11.7).
Article 21(2)(j) also names secured voice, video and text communications and secured emergency communication systems within the entity, where appropriate. The Implementing Regulation gives them no section of their own, so ENISA's mapping table has no row for them.
A classification level for every asset, information included, set by its confidentiality, integrity, authenticity and availability needs; a handling policy for the whole asset life cycle, from acquisition to disposal; a removable media policy; an up-to-date inventory that also lists your operations and services; and deposit, return or deletion of assets when employment ends.
Physical security of premises, secure areas, equipment protection, supporting utilities, environmental monitoring, secure disposal.
What you see here — ENISA's mapping made browseable — is a navigation aid. Useful, but it's a static reference. Real assurance work is doing the mapping for your suppliers, with your evidence, in a way that holds up under audit.
Vittnor V1 — the version shipping Q4 2026 — is built around NIS2 Article 21(2)(d). It scopes your suppliers, assesses the ones in scope, collects their evidence and records each review decision, with a log of who did what.
The V2 release — on the product roadmap for 2028+ — extends the same evidence model into cross-framework crosswalks. One supplier evidence record, routed automatically into your NIS2, ISO 27001, DORA and SOC 2 audit contexts simultaneously, each with reviewer sign-off. ENISA's mapping table is the foundation; the platform layer is what we add on top.
Common questions about NIS2 and the major control frameworks. If you're looking for the area-by-area mapping, the reverse search and forward mapping above are the answer; this section covers the framing questions practitioners ask before they get into the controls.
Not on its own. ISO/IEC 27001:2022 is a voluntary, certifiable standard; NIS2 is EU law, applied through each country's national act, and a certificate doesn't make you compliant. A current ISO 27001 ISMS does cover most of the technical and organisational measures NIS2 expects — ENISA's mapping table links every point of Commission Implementing Regulation (EU) 2024/2690 to ISO 27001. Three things sit outside the standard and need their own procedures: Article 23 reporting deadlines (24-hour early warning, 72-hour incident notification, 1-month final report, each to your national CSIRT or competent authority); Article 20 duties for management bodies, which approve the measures, oversee them, can be held liable and must follow cybersecurity training; and the supply-chain inputs NIS2 names that ISO 27001 doesn't, such as the EU's coordinated risk assessments of critical supply chains (Article 21(3)).
NIST Cybersecurity Framework 2.0's six functions (Govern, Identify, Protect, Detect, Respond, Recover) align well with the thirteen NIS2 thematic areas across the board. The Govern function, added in 2.0, maps particularly closely to NIS2's governance expectations under Article 20. The dedicated GV.SC category (Cybersecurity Supply Chain Risk Management — ten subcategories) is the most explicit framework alignment with NIS2 Article 21(2)(d) of any major framework. Use the reverse-search tool above with NIST CSF 2.0 selected to see the area-by-area mapping with practitioner notes.
SOC 2 Type II is the most-cited evidence artefact when EU buyers ask cloud / SaaS suppliers for cybersecurity posture. The AICPA Trust Services Criteria — Security, Availability, Processing Integrity, Confidentiality, Privacy — align with most NIS2 thematic areas. Strongest where NIS2 expects technical and operational controls (CC6 access, CC7 system operations, CC8 change management, A1 availability). Gaps to wire in separately: NIS2 Article 23 reporting deadlines (regulator-facing, outside SOC 2 scope), Article 20 management body accountability (not addressed in TSC), and the supply-chain specifics NIS2 names beyond general supplier risk management (a register of direct suppliers, listed contract terms, the EU's coordinated risk assessments). A current SOC 2 Type II report is a defensible substitute for many NIS2 21(2)(d) supplier-assurance evidence requests, but not framework-equivalent.
Three things specifically. (1) Regulatory reporting deadlines under Article 23: 24-hour early-warning, 72-hour incident notification, and 1-month final report, each to your national CSIRT or competent authority. ISO 27001 A.5.24–A.5.28 cover incident-response operations, but the regulator-facing reporting machinery is NIS2-specific. (2) Management-body duties under Article 20 — the management body approves the cybersecurity measures, oversees their implementation and can be held liable for infringements, and its members must follow cybersecurity training. (3) Supply-chain specifics — Article 21(3) requires you to take into account each direct supplier's vulnerabilities, the quality of their products and security practices, and the results of the EU's coordinated risk assessments of critical supply chains. For the providers it binds (and, through NISV 2026, every essential and important entity in Austria), Implementing Regulation 2024/2690 adds listed contract terms (5.1.4) and a register of direct suppliers (5.2). Recital 85 says you could also consider risks further down the chain — an option, not a requirement. ISO 27001 A.5.19–A.5.23 give you the supplier process to build these on.
No — and to be clear, Cyber Essentials isn't the UK's substitute for NIS2 either. Cyber Essentials and Cyber Essentials Plus are NCSC-backed voluntary certification schemes (administered by IASME) covering five core technical controls: firewalls, secure configuration, user access control, malware protection, and security update management. They're a defensible baseline that EU NIS2 buyers commonly accept as a substitute for the NIS2 Article 21(2)(d) evidence they're collecting from UK suppliers — but they don't cover the full NIS2 control set. For UK organisations actually under NIS2 obligations (rare, given UK is post-Brexit and outside NIS2 scope), broader coverage is required.
Yes — ISO/IEC 22301:2019 is the international Business Continuity Management System standard and maps directly to NIS2's business-continuity area (Implementing Regulation Annex §4). Strong on backup, recovery, disaster-management, and crisis arrangements. ISO 22301 is narrow in scope — it doesn't cover access control, cryptography, HR security, or general information-security policy. Most useful as a complement to ISO 27001 or NIST CSF 2.0 for organisations where business continuity is a critical concern (utilities, financial market infrastructure, healthcare). It exceeds the NIS2 baseline for BCP specifically.
ENISA published an official NIS2 Technical Implementation Guidance Mapping Table (XLSX) alongside the main NIS2 TIG document — first as v1.0 in June 2025; the current version is v1.2 (August 2025). The table maps each Commission Implementing Regulation (EU) 2024/2690 cybersecurity-requirement to control references in ISO/IEC 27001:2022, NIST CSF 2.0, ETSI EN 319 401 V3.1.1, CEN/TS 18026:2024, and selected national frameworks (Belgium's CyberFundamentals (CyFun®) 2023, Finland's Kybermittari, Greece's Ministerial decision 1689/2025, Spain's ENS / Royal Decree 311/2022, and a French column labelled simply "FR"). ENISA's own caveat: the mapping is a navigation aid, not a measure of equivalence between frameworks — standards address the same concerns with different language and depth. The hub above sources its ISO 27001, NIST CSF 2.0, ETSI, and CEN/TS 18026 assessments directly from this table, supplemented with practitioner-curated assessments for SOC 2, CIS Controls v8, NIST 800-53, and ISO 22301 (frameworks ENISA's table doesn't cover). The five national frameworks are listed under the picker for orientation. Practitioners doing detailed gap analysis should download the XLSX from ENISA directly.
ENISA, the EU's cybersecurity agency, published its NIS2 Technical Implementation Guidance on 26 June 2025 to help entities apply Commission Implementing Regulation (EU) 2024/2690. It gives practical advice, examples of evidence, and a mapping table to ISO 27001, NIST CSF 2.0 and other frameworks. It is advisory, not legally binding: your obligations come from the regulation and from your country's national law. ENISA doesn't supervise entities, and your incident reports go to your national CSIRT or competent authority, not to ENISA.
No single framework gets you to NIS2 compliance — NIS2 is a regulation, not a control framework. The practitioner question is: which framework do you already run? Then add the NIS2-specific overlay (regulatory reporting under Article 23, Article 20 governance, the supply-chain specifics) on top. ISO/IEC 27001:2022 and NIST CSF 2.0 are the closest single-framework matches across the thirteen NIS2 thematic areas. NIST SP 800-53 r5 is the most comprehensive but heaviest. CIS Controls v8 maps strongly to the basic-cyber-hygiene baseline (Article 21(2)(g)) but is thin on governance and HR — best as a complement. ISO 22301 is BCP-specific. SOC 2 Type II is common in supplier-evidence contexts but not framework-equivalent. Pick what your organisation already operates against, then layer the NIS2-specific procedures on top.
Framework mapping is the control layer. Where NIS2 actually stands — the act, the supervisory authority, the deadlines — differs by country.
The official spreadsheet maps every Implementing Regulation requirement to specific control references in ISO 27001, NIST CSF 2.0, ETSI EN 319 401, CEN/TS 18026:2024, and selected national frameworks. It is the source of truth.
Download the ENISA XLSX