ENISA NIS2 Technical Implementation Guidance: A Practical Summary

Last verified: March 2026. Based on ENISA Technical Implementation Guidance v1.0 (June 2025), Commission Implementing Regulation (EU) 2024/2690, and Directive (EU) 2022/2555 (NIS2).

In June 2025, the European Union Agency for Cybersecurity (ENISA) published what is arguably the most important practical document for NIS2 compliance to date: the Technical Implementation Guidance on Cybersecurity Risk Management Measures — a 170-page companion to the Commission Implementing Regulation (EU) 2024/2690.

If you are trying to understand what NIS2 actually requires you to do — not just what it says — this is the document that answers the question. This article summarises all 13 sections of the ENISA guidance, extracts the most actionable recommendations, and explains how it maps to your compliance obligations. Without requiring you to read 170 pages of official guidance yourself.

What Is the ENISA Technical Implementation Guidance?

The ENISA guidance is a non-binding companion document to the Commission Implementing Regulation (EU) 2024/2690 (the CIR). Where the CIR specifies what security measures entities must implement (and is legally binding), the ENISA guidance explains how to implement those measures in practice.

Think of it as an official, EU-endorsed how-to manual. ENISA reviewed current standards, drew on member state expertise through the NIS Cooperation Group, ran a public consultation (November 2024 – January 2025), and synthesised implementation approaches that are proportionate, risk-based, and auditable.

Key facts about the guidance:

• Published: 26 June 2025 (Version 1.0)
• Publisher: ENISA, in collaboration with the European Commission and EU Member States
• Full title: Technical Implementation Guidance on Cybersecurity Risk Management Measures
• Length: ~170 pages
• Legal status: Non-binding — recommended best practice, explicitly described as “not a legally binding document”
• Structure: Follows the exact 13-section structure of the CIR Annex
• Standards referenced: ISO 27001/27002, NIST CSF 2.0, BSI Grundschutz, ANSSI guidelines, IEC 62443, ETSI EN 319 401, CEN/TS 18026:2024
• Companion documents: Mapping Table (Excel, v1.2 — maps CIR requirements to ISO 27001, NIST CSF 2.0, and ETSI standards) and Cybersecurity Roles and Skills for NIS2 Essential and Important Entities

Critically, while the guidance is non-binding and “not intended to replace frameworks provided by Member States,” national competent authorities across the EU are widely expected to use it as their primary benchmark when assessing whether an entity has implemented “appropriate and proportionate security measures.” ENISA itself describes it as a “living document” subject to future updates as implementation experience accumulates. In practice, it is the closest thing to an official compliance standard that NIS2 currently has [1] [2].

For a full overview of the underlying directive obligations, see our NIS2 Directive explained guide. For the detailed legal requirements, see NIS2 requirements overview.

Who Is This Guidance For?

The CIR 2024/2690 applies specifically to a defined set of entity types, and the ENISA guidance is technically addressed to those same entities. However, ENISA explicitly recommends the guidance as useful for all NIS2 entities, regardless of sector or entity type.

Entities directly subject to the CIR (and for whom following the guidance is closest to mandatory in practice):

• DNS service providers
• Top-level domain (TLD) name registries
• Cloud computing service providers
• Data centre service providers
• Content delivery network (CDN) providers
• Managed service providers (MSPs)
• Managed security service providers (MSSPs)
• Online marketplaces
• Online search engines
• Social networking service platforms
• Trust service providers

Entities not directly subject to the CIR (but for whom ENISA recommends the guidance):

• All other essential and important entities under NIS2 — energy, transport, banking, healthcare, water, digital infrastructure, and more
• SMEs who lack internal cybersecurity expertise to interpret NIS2 requirements independently
• Organisations preparing for NIS2 audits or supplier assessments

For SMEs in particular, the ENISA guidance is valuable precisely because it translates abstract regulatory language into concrete actions and references established standards. It removes the interpretive burden that would otherwise require expensive external consultancy.

National authorities will also likely use this guidance when conducting supervisory reviews. If your implementation broadly aligns with what ENISA recommends, you are demonstrating good faith and proportionate effort — which matters when authorities assess compliance under Article 21 NIS2. Check whether your organisation falls in NIS2 scope before you begin.

How the Guidance Maps to CIR 2024/2690

The ENISA guidance mirrors the CIR Annex section by section. For every requirement in the CIR, the guidance provides three elements:

• Guidance — additional advice, explanation of concepts, and tips on what to consider when implementing each requirement
• Examples of evidence — what you could show to auditors or supervisory authorities to demonstrate compliance
• Tips — practical recommendations and common pitfalls to avoid

The table below shows the structural mapping between the CIR Annex, NIS2 Article 21 measures, and the key additions ENISA provides:

CIR Annex Section	Topic	Art. 21 Ref.	Key ENISA Additions
Section 1	Security Policy	21(2)(a)	Hierarchical policy framework; management approval; annual review cycle
Section 2	Risk Management	21(2)(a)	Asset-based methodology; threat intelligence integration; review triggers
Section 3	Incident Handling	21(2)(b)	SIEM/log management; severity matrix; playbooks; post-incident review
Section 4	Business Continuity	21(2)(c)	BIA-driven RTOs/RPOs; 3-2-1 backup rule; tabletop exercises
Section 5	Supply Chain	21(2)(d)	Tiered classification; right-to-audit; continuous monitoring; FOSS considerations
Section 6	Secure Development	21(2)(e)	Secure SDLC; SAST/DAST in CI/CD; vulnerability disclosure; CIS/DISA hardening
Section 7	Effectiveness Assessment	21(2)(f)	KPIs/KRIs per domain; quarterly cycle; independent audit annually
Section 8	Training and Awareness	21(2)(g)	Role-based matrix; phishing simulation; management-specific training
Section 9	Cryptography	21(2)(h)	Approved algorithm list; key lifecycle; post-quantum roadmap
Section 10	HR Security	21(2)(i)	Pre-employment screening; JML process; security in job descriptions
Section 11	Access Control	21(2)(i)(j)	Zero-trust principles; mandatory MFA; quarterly access reviews
Section 12	Asset Management	21(2)(i)	Automated discovery; 4-level classification; CMDB with ownership
Section 13	Physical Security	—	Security zones; environmental monitoring; visitor management

ENISA also publishes a companion Mapping Table (Excel format, v1.2 as of September 2025) that maps each CIR requirement to corresponding controls in ISO 27001:2022, NIST CSF 2.0, and ETSI EN 319 401. ENISA explicitly notes this mapping “should not be interpreted as a measure of equivalence” — it shows relevant requirements without assessing whether they fully cover the CIR requirements [1].

For the full text of each CIR requirement, see our NIS2 requirements overview.

Key Recommendations by Section

Here is what ENISA recommends for each of the 13 sections — the practical substance behind each requirement.

Section 1 — Security Policy

ENISA recommends a hierarchical policy framework: a top-level information security policy formally approved by senior management, linked to topic-specific policies (access control, incident response, cryptography, etc.). Policies should be reviewed on an annual cycle as a minimum, or upon significant incidents or infrastructure changes, with a designated policy owner for each document. A policy awareness programme should ensure all relevant staff have read and acknowledged applicable policies. ENISA specifically flags that policies should reflect the organisation’s actual risk environment rather than being generic templates — a point that national authorities will scrutinise. Necessary resources (staff, financial, processes, tools) must be explicitly allocated [1].

Section 2 — Risk Management

ENISA recommends a documented risk assessment methodology with explicit criteria for risk tolerance and four defined treatment options: avoidance, mitigation, transfer/sharing, and acceptance. The methodology should adopt an all-hazards approach addressing availability, integrity, authenticity, and confidentiality. Threat intelligence should be integrated — ENISA references MITRE ATT&CK and sector-specific threat reports as inputs. Review triggers go beyond the annual cycle: risk assessments should also be revisited after significant incidents, major infrastructure changes, or when new threat intelligence warrants it. Independent reviews covering people, processes, and technologies are expected at planned intervals [1].

Section 3 — Incident Handling

ENISA recommends centralised log management or SIEM as the foundation for detection capability. A categorisation system based on operational impact, data sensitivity, scope, and attack type should be established before an incident occurs. Pre-written playbooks for common incident types (ransomware, phishing, data breach, DDoS) are strongly recommended. Post-incident reviews should capture lessons learned and feed back into both the risk register and detection use cases. The guidance emphasises coherence between incident handling procedures and the NIS2 reporting timeline (24-hour early warning, 72-hour notification, 1-month final report) and business continuity plans [1].

Section 4 — Business Continuity

ENISA recommends a Business Impact Analysis (BIA) as the foundation for BCM, with documented Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs) per critical service. Backup strategy should follow the 3-2-1 rule: three copies, on two different media types, with one copy offsite — plus at least one immutable (write-protected) copy to protect against ransomware. Off-site backup integrity must be verified regularly. Crisis management is treated as a distinct process from business continuity, addressing threats to organisational viability. Tabletop exercises should be conducted at least annually. The guidance aligns with ISO 22301, ISO 22313, and NIST SP 800-34 Rev. 1 [1].

Section 5 — Supply Chain Security

ENISA recommends tiered supplier classification: categorise suppliers by their access to your systems and data, with enhanced requirements for critical and high-risk suppliers. Selection criteria should emphasise cybersecurity practices. Contracts with critical suppliers should include right-to-audit clauses and security incident notification requirements. Continuous monitoring of critical supplier security posture is recommended rather than point-in-time assessments only. Notably, ENISA acknowledges that contractual security obligations may not apply to Free/Open Source Software (FOSS) communities — a practical reality that procurement policies must account for. Entities should maintain an up-to-date registry of all direct suppliers and service providers [1].

Section 6 — Secure Development and Acquisition

This is the largest section in the ENISA guidance, covering multiple subsections: secure acquisition, Secure Software Development Lifecycle (SSDLC), configuration management, change management, security testing, patch management, network security, network segmentation, malware protection, vulnerability handling, and legacy systems. Key highlights: automated security testing (SAST/DAST) should be integrated into CI/CD pipelines. Configuration hardening should follow CIS Benchmarks or DISA STIGs with documented secure baselines. Critical systems should be reviewed monthly. A vulnerability disclosure policy is recommended for externally facing systems. For legacy systems that cannot be patched, compensatory measures including network segmentation, intrusion detection, and enhanced vulnerability scanning are required [1].

Section 7 — Effectiveness Assessment

ENISA recommends defining KPIs and KRIs per security domain — for example, mean time to detect (MTTD), mean time to respond (MTTR), percentage of systems with up-to-date patches, phishing simulation click rates. Methods include self-assessment, benchmarking, penetration testing, code review, and formal audits. An independent assessment should take place at least annually. Results should feed directly back into the risk management process and trigger corrective actions. Policies should be reviewed every two years at minimum [1].

Section 8 — Training and Awareness

ENISA recommends a role-based training matrix: security awareness training for all staff covering safe email, phishing recognition, mobile security, patching, and teleworking — plus specialist training for IT/security teams and management-specific training on NIS2 obligations and personal liability. A phishing simulation programme is explicitly recommended. New starters should receive security induction training promptly. Training effectiveness should be measured through pre/post assessments and click-rate trends. The guidance distinguishes between broad awareness raising (all employees) and targeted security training (those with security responsibilities) [1].

Section 9 — Cryptography and Key Management

ENISA recommends specifying type, strength, and quality requirements for data at rest and in transit, maintaining an approved algorithm list aligned with BSI Technical Guidelines, ANSSI recommendations, and NIST standards. A “cryptographic agility approach” is recommended — the ability to switch algorithms when vulnerabilities are discovered or standards change. Key lifecycle management should cover generation, storage, distribution, rotation, revocation, recovery, and destruction. Certificate management should include automated renewal tracking to prevent expiry-related outages. ENISA specifically flags the need to begin developing a post-quantum cryptography roadmap, acknowledging that migration timelines are long and planning should begin now [1].

Section 10 — HR Security

ENISA recommends pre-employment screening proportionate to role sensitivity, with enhanced vetting (background verification) for roles with access to critical systems or sensitive data. Security responsibilities should be documented in all job descriptions, not added as an afterthought. The Joiner-Mover-Leaver (JML) process is a key recommendation: defined procedures for provisioning access when someone joins, adjusting access when they change roles, and promptly revoking access when they leave. Responsibilities remain valid after employment changes or termination. A clear disciplinary process for security policy violations should be established and communicated [1].

Section 11 — Access Control

ENISA recommends applying zero-trust principles where feasible — defaulting to need-to-know, least-privilege access, and separation of duties. Mandatory MFA is required for all privileged access (admin accounts) and all remote access — no exceptions. Dedicated admin accounts must be separate from regular user accounts. Shared identities should only be permitted with explicit documented approval. Access to critical systems should be reviewed quarterly. Privileged Access Workstations (PAWs) are recommended for administrative tasks. Session management should include automatic termination after inactivity. A register of all granted access rights must be maintained [1].

Section 12 — Asset Management

ENISA recommends maintaining a complete, accurate, and continuously updated asset inventory — preferably using automated discovery tools rather than relying on manual spreadsheets. Assets should be classified using defined levels based on confidentiality, integrity, authenticity, and availability, with handling requirements per level. Asset lifecycle management should cover procurement through to secure disposal — including irretrievable deletion or physical destruction. Specific policies for removable media (with technical controls and encryption) are required. A CMDB or asset register should define an owner for every asset, creating clear accountability. Classification levels should be reviewed regularly [1].

Section 13 — Physical and Environmental Security

ENISA recommends defining physical security zones with perimeter-based access controls appropriate to the sensitivity of each area. Supporting utilities (power, cooling) should have redundancy and be monitored continuously, with emergency supply tested regularly. Environmental monitoring (temperature, humidity, water intrusion) should be in place for server rooms and data processing areas. Visitor management procedures — logging, escorting, and restricting access — should be documented and enforced. Physical access controls should integrate with logical and network access controls. All physical security measures should be reviewed and tested at planned intervals [1].

Practical Takeaways for SMEs

The ENISA guidance does not contain a dedicated SME chapter, but includes proportionality considerations throughout. If you are an SME trying to prioritise your NIS2 compliance effort, here is how to translate the guidance into an actionable roadmap.

Top 5 Things to Do Immediately (Phase 1)

1. Document your risk assessment methodology and perform an initial assessment. This is the foundation everything else builds on. Without a documented methodology, you cannot demonstrate proportionate security measures to a national authority. ENISA permits documented risk acceptance where mitigation costs exceed impact — but you must document the rationale.
2. Establish an incident detection and notification workflow. You need to detect, classify, and report a significant incident within 24 hours (initial notification) under NIS2. Define who gets alerted, on what criteria, and what the notification template looks like before an incident occurs.
3. Implement MFA on all admin and remote access accounts. This is the single highest-impact, lowest-cost security control you can implement. ENISA makes it mandatory for privileged and remote access — no exceptions.
4. Create and test backups with at least one immutable copy. Ransomware remains the dominant threat to SMEs. An immutable backup copy (air-gapped or write-once) is your recovery insurance. Test restoration — an untested backup is not a backup.
5. Classify your suppliers and assess your top 10 critical ones. NIS2 places supply chain obligations on entities. Identify which suppliers have access to your systems or data, prioritise the highest-risk ones, and document your assessment. Even a lightweight questionnaire is better than nothing.

Phase 2 — What You Can Defer (But Not Ignore)

These are valuable but not the first priority for resource-constrained SMEs:

• Advanced monitoring infrastructure (SIEM, SOAR)
• Automated asset discovery tools (a well-maintained spreadsheet is an acceptable starting point)
• Post-quantum cryptography planning
• Full zero-trust architecture deployment
• Dedicated Privileged Access Workstations

For SMEs, ENISA also permits simplified independent reviews with alternative impartiality measures, and allows derogations from specific requirements when “duly documented and substantiated.” The key is documentation: national authorities will look for evidence that you have considered each area and made proportionate decisions, not that you have implemented enterprise-grade controls [1].

For a structured checklist covering all 13 areas, see our NIS2 compliance checklist.

How Our Templates Align with ENISA Guidance

The NIS2 template pack available on this site was designed with the ENISA guidance as the primary reference. Every template addresses the specific documentation and process requirements ENISA identifies — including the “examples of evidence” that auditors and supervisory authorities will look for.

ENISA Guidance Section	Corresponding Templates
Section 1 — Security Policy	Information Security Policy (master), plus 8 topic-specific policy templates
Section 2 — Risk Management	Risk Assessment Methodology, Risk Register, Risk Treatment Plan
Section 3 — Incident Handling	Incident Response Plan, Severity Classification Matrix, 5 incident playbooks, Post-Incident Review template
Section 4 — Business Continuity	BIA template, BCP, DRP, Backup Policy, Tabletop Exercise scenario
Section 5 — Supply Chain	Supplier Classification Framework, Security Questionnaire, Supplier Assessment Report
Section 6 — Secure Development	Secure SDLC Policy, Change Management Procedure, Vulnerability Disclosure Policy, Configuration Baseline template
Section 7 — Effectiveness Assessment	Security KPI Dashboard template, Audit Plan, Penetration Test Brief
Section 8 — Training and Awareness	Training Matrix, Security Awareness Plan, Phishing Simulation Policy
Section 9 — Cryptography	Cryptography Policy, Key Management Procedure, Certificate Inventory
Section 10 — HR Security	HR Security Policy, JML Procedure, Background Check Process
Section 11 — Access Control	Access Control Policy, MFA Implementation Checklist, Privileged Access Procedure, Access Review Template
Section 12 — Asset Management	Asset Management Policy, Asset Register template, Asset Classification Scheme, Disposal Procedure
Section 13 — Physical Security	Physical Security Policy, Visitor Log template, Data Centre Security Checklist

Each template is pre-populated with the structures, criteria, and example content that ENISA recommends — so you are not starting from a blank document. The risk assessment templates include the threat categories ENISA specifies; the incident response templates follow the playbook format ENISA recommends; the policy templates include the review cycle and ownership fields ENISA flags as essential.

If you already hold ISO 27001 certification, our NIS2 vs ISO 27001 comparison shows exactly where the gaps lie and which templates close them.

Browse all available templates at our templates library.

Frequently Asked Questions

Is the ENISA NIS2 guidance mandatory?

No. The ENISA guidance is non-binding and represents recommended best practice rather than a legal requirement. However, it was developed in collaboration with the European Commission and the NIS Cooperation Group, and national competent authorities are expected to use it as a benchmark when assessing compliance. Entities that demonstrably follow the ENISA guidance are in a strong position to demonstrate appropriate and proportionate security measures under Article 21 NIS2.

Does following ENISA guidance guarantee NIS2 compliance?

Following ENISA guidance demonstrates a good faith effort and addresses the CIR requirements comprehensively. However, NIS2 compliance is ultimately assessed by national competent authorities on a case-by-case basis, taking account of the entity’s size, risk profile, and the proportionality of measures taken. The ENISA guidance is the strongest available reference point, but it is not a formal certification.

Where can I download the ENISA NIS2 guidance?

The guidance is available free of charge from the ENISA publication page. The page also provides the companion Mapping Table (Excel) and the related Cybersecurity Roles and Skills document published on the same date.

How often will ENISA update the guidance?

ENISA describes the guidance as a “living document” but has not published a fixed revision schedule. Updates are expected as practical implementation experience accumulates and as the threat landscape evolves. The Mapping Table has already been updated (from v1.0 to v1.2 between June and September 2025), so check the publication page for the latest versions.

Is the ENISA guidance different from the CIR?

Yes — they are complementary but distinct documents. The CIR 2024/2690 is the legally binding regulation specifying what security measures certain entities must implement. The ENISA guidance is a separate, non-binding document explaining how to implement those measures. The CIR defines the obligation; the ENISA guidance explains how to fulfil it.

Which entities must follow the CIR 2024/2690?

The CIR directly applies to DNS providers, TLD registries, cloud providers, data centres, CDN providers, MSPs, MSSPs, online marketplaces, search engines, social networking platforms, and trust service providers. ENISA recommends its guidance as useful for all NIS2 entities — not just those directly subject to the CIR. Check our NIS2 scope guide to determine whether the CIR applies to your organisation.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

1. ENISA, Technical Implementation Guidance on Cybersecurity Risk Management Measures, Version 1.0, 26 June 2025. Publication page.
2. ENISA, “Supporting NIS2 implementation through actionable guidance,” 26 June 2025. News article.
3. Commission Implementing Regulation (EU) 2024/2690, 17 October 2024. EUR-Lex full text.
4. Directive (EU) 2022/2555 of the European Parliament and of the Council (NIS2 Directive). EUR-Lex full text.