NIS2 Readiness Checklist: Preparing for NIS2 Obligations

Many organisations in scope of NIS2 still cannot say which national law applies to them, who on the management body has approved their security measures, or whether they could send an early warning within 24 hours of spotting a significant incident. Directive (EU) 2022/2555 had to be transposed by 17 October 2024, and supervisors in transposed Member States now expect evidence, not plans. This checklist is a working template for [Organisation] to test readiness against the core obligations: management body accountability (Article 20), cybersecurity risk-management measures (Article 21) and incident reporting (Article 23). Where the requirements are detailed in Commission Implementing Regulation (EU) 2024/2690 and ENISA's technical implementation guidance, the checks follow them. It is written for CISOs, compliance leads and executives preparing for supervision.

How to use this template

• Replace text in square brackets, such as [Organisation], [Member State], [Competent authority] and [Control owner], with your own terms.
• Work through the sections in order: section 1 decides which national law, authority and supervisory regime apply, and that changes the detail of everything that follows.
• Mark each check as Met, Partly met or Not met, record where the evidence is held, and give every gap an owner and a due date.
• Article references point to Directive (EU) 2022/2555. Your binding obligations come from the national law that transposes it, which may add detail or go further. If you are a DNS, TLD, cloud, data centre, CDN, managed service, managed security service, online marketplace, search engine, social network or trust service provider, Implementing Regulation (EU) 2024/2690 sets the technical requirements directly.
• This template is not legal advice. Confirm scope and obligations with counsel and your competent authority.

1. Scope, classification and registration

• [Organisation] has assessed whether its activities fall within the sectors in Annex I (high criticality) or Annex II (other critical sectors) of the Directive, for each legal entity in the group.
• Size has been assessed against the medium and large enterprise thresholds, and any rule that brings in entities regardless of size (for example DNS service providers, TLD registries or sole providers of a critical service) has been checked.
• The classification as an essential or important entity is documented, because supervision differs: essential entities face proactive supervision, important entities mainly supervision after the fact.
• The national transposing law in each [Member State] where [Organisation] operates is identified, with its current status taken from an official source. The European Commission's transposition page (last updated 1 July 2025 when checked) records reasoned opinions sent on 7 May 2025 to 19 Member States for failing to notify full transposition, so status varies by country and must be rechecked.
• For digital infrastructure and digital provider entity types, the Member State of main establishment is determined.
• Registration with [Competent authority] or the national registry is complete, and the details are kept current.
• Subsidiaries, suppliers and customers that may themselves be in scope are listed, because their obligations flow into contracts. See the NIS2 Directive Guide.

2. Governance and management body accountability (Article 20)

• The management body has formally approved the cybersecurity risk-management measures, with the decision minuted on [Date].
• The management body oversees implementation through a standing report from [CISO] at least [quarterly], covering risks, incidents and open gaps.
• Members of the management body have completed cybersecurity training, with records kept, and a schedule exists for refresher training.
• Members understand that the national law can hold them liable for infringements, and the D&O insurance position has been reviewed.
• The information security policy is approved by management and reviewed at least annually, as Implementing Regulation 2024/2690 requires for entities it covers (Annex point 1.1.2).
• Security roles are formally assigned, conflicting duties are segregated, and at least one person responsible for security reports directly to management (Annex point 1.2).
• Cybersecurity is a standing item on the board risk register. See the DORA and NIS2 Overlap Mapping Guide if [Organisation] is also a financial entity under DORA.

3. Risk management and security policy (Article 21(2)(a) and (f))

• A documented risk management framework exists, with a method to identify, analyse and rank risks to network and information systems, using an all-hazards approach.
• A risk treatment plan lists the chosen measures, owners and residual risk acceptance, and is reviewed at least annually.
• Topic-specific policies (access control, cryptography, supplier security, backup, incident handling) are listed in the main policy with owners.
• A policy and procedure exist to assess the effectiveness of the measures: what is measured, how, how often and by whom.
• Independent reviews of security are carried out by people with appropriate competence; where size prevents full independence, an alternative is documented.
• Existing certifications or frameworks (ISO/IEC 27001:2022, NIST CSF 2.0) have been mapped to the requirements using the ENISA mapping table, remembering that ENISA states the mapping does not show equivalence. See the ISO 27001 Certification Guide.

4. Incident handling and reporting (Articles 21(2)(b) and 23)

• An incident handling policy defines roles, classification criteria, escalation paths and communication rules.
• Monitoring and logging cover network and information systems, with log content, retention and alert thresholds defined.
• Criteria for a "significant incident" are documented. Entities covered by Implementing Regulation 2024/2690 use its thresholds, including direct financial loss above EUR 500 000 or 5% of annual turnover (whichever is lower) and recurring incidents that together become significant.
• A reporting runbook names who decides, who submits and how to reach [CSIRT or competent authority], and meets the stages: early warning within 24 hours of becoming aware, incident notification within 72 hours, and a final report no later than one month after the notification, with intermediate reports on request.
• Templates for each report stage are prepared and stored where the on-call team can reach them out of hours.
• A rule exists for informing service recipients without undue delay when an incident is likely to affect them.
• The reporting timeline has been tested in an exercise in the last 12 months. See the Incident Response Plan Template and the Data Breach Notification Checklist where personal data is also involved.

5. Business continuity, backup and crisis management (Article 21(2)(c))

• A business continuity and disaster recovery plan exists, based on a business impact analysis with recovery time and recovery point objectives.
• Backups are complete, protected from unauthorised access, held off-network and off-site, checked for integrity and restored in tests at planned intervals.
• Redundant resources (power, connectivity, key suppliers) are identified for critical services.
• A crisis management process names roles, decision rights and how [Organisation] communicates with authorities during a crisis.
• Recovery from ransomware has been rehearsed end to end. See the Ransomware Prevention Guide and the Business Continuity Plan Template.

6. Supply chain security (Article 21(2)(d))

• A supply chain security policy sets criteria for selecting and contracting suppliers and service providers.
• A supplier register records each direct supplier, the services and data it touches, and its criticality.
• Contracts with critical suppliers include security requirements, incident notification, audit or assurance rights, vulnerability handling, subcontracting rules and data return or deletion at exit.
• Supplier security is monitored and reviewed, with results recorded.
• Managed service and managed security service providers with privileged access are treated as the highest risk tier, with their access accounts inventoried. See the Third-Party Risk Management Guide.

7. Secure systems, vulnerabilities and cryptography (Article 21(2)(e) and (h))

• Security requirements are applied to acquired ICT products and services and to in-house development across the lifecycle.
• Configuration baselines exist and changes are controlled, documented and tested.
• Patches are applied promptly based on risk, with a process for emergency patches.
• Vulnerabilities are monitored, scanned and handled, and a coordinated vulnerability disclosure route is published. See the Vulnerability Management Guide.
• Networks are segmented and protected against malware.
• A cryptography policy covers data at rest and in transit, approved algorithms and protocols, and the full key lifecycle: generation, storage, rotation, revocation, backup, destruction and logging.

8. People, access control, MFA and assets (Article 21(2)(g), (i) and (j))

• Recurring awareness training covers staff and management, and role-based training is given to those with security responsibilities, with effectiveness checked.
• Basic cyber hygiene practices are defined and checked (patching, secure configuration, password and MFA use, backups).
• Human resources security covers background checks for sensitive roles, security responsibilities in contracts and post-employment duties.
• Access is granted on least privilege and need to know, with separation of duties, and reviewed at regular intervals.
• Multi-factor or continuous authentication is used where appropriate, at minimum for remote access, administrative access and critical systems. See the MFA Guide.
• Privileged and administrative accounts use separate credentials and segregated administration systems. See the Privileged Access Management Guide.
• Shared accounts are limited, and service accounts, API keys and other non-human identities have a named owner, a purpose and a rotation date. See the Service Account Security Guide.
• Secured voice, video and text communications and secured emergency communications are available where appropriate.
• An accurate asset inventory exists, assets are classified by protection need, and removable media are controlled.

Implementation guidance

Sequence: complete section 1 first, because classification, national law and authority drive everything else. Then section 2, since management approval is both an obligation and the lever for funding the rest. Then section 4, because a failed 24-hour early warning is the most visible gap to a supervisor. Sections 3 and 5 to 8 can run in parallel.

Evidence: ENISA's technical implementation guidance (June 2025) gives, for each requirement of Implementing Regulation 2024/2690, guidance, examples of evidence and tips, such as formal appointment of security roles, a documented incident handling policy, samples of log files and a risk register. ENISA states the guidance is non-binding and that demanding every listed item would be a very strict approach to supervision, so use it to choose proportionate evidence.

Small vs large entities: a medium-sized important entity can assign security roles to existing staff and rely on an existing ISO/IEC 27001 ISMS for most of sections 3 and 5 to 8. A large essential entity should expect audits and on-site inspections and needs dedicated roles, an independent review function and documented test results. Penalties under the Directive reach a maximum of at least EUR 10 million or 2% of worldwide turnover for essential entities and EUR 7 million or 1.4% for important entities, whichever is higher.

Watch for change: on 20 January 2026 the Commission proposed targeted amendments to NIS2 to simplify compliance. Check their legislative status and your national law before each annual review.

Metrics to track readiness: percentage of checks Met; time from detection to early warning in exercises; critical suppliers with security clauses in contract; privileged and non-human accounts with an owner and MFA or rotation in place; backups restored successfully in tests; and open risk treatment actions past due.

References: EUR-Lex: Directive (EU) 2022/2555 (NIS2) · EUR-Lex: Commission Implementing Regulation (EU) 2024/2690 · ENISA: NIS2 Technical Implementation Guidance · European Commission: NIS2 Directive · European Commission: NIS2 Directive FAQs · European Commission: NIS2 transposition

This template summarises obligations under Directive (EU) 2022/2555 and Implementing Regulation (EU) 2024/2690 and is not legal advice; adapt it to your national law. Related NHI Mgmt Group resources: NIS2 Directive Guide · DORA and NIS2 Overlap Mapping Guide · Incident Response Plan Template · Third-Party Risk Management Guide · Ransomware Prevention Guide