NIS2 compliance checklist: who is in scope, what Article 21 requires and the evidence auditors accept
NIS2 is Directive (EU) 2022/2555, the EU's cybersecurity law for essential and important entities. It widened the 2016 NIS Directive to 18 sectors, pulled in medium-sized companies, made management personally accountable and set hard incident-reporting clocks. Member states had to transpose it by 17 October 2024 (Article 41), and it reaches any covered entity providing services in the EU, including the EU operations of US and UK companies.
This checklist follows the directive in the order a supervisor reads it: scope (Articles 2 and 3), the management duty (Article 20), the ten risk-management measures (Article 21), the reporting clock (Article 23), then registration, supervision and fines (Articles 27, 32 to 34). For each measure we name the evidence an auditor accepts. Security testing is one line on the list, under measure (f).
Step 1: confirm you are in scope, and which tier
The sector test. NIS2 applies to entities of a type listed in Annex I (sectors of high criticality) or Annex II (other critical sectors). Annex I covers energy, transport, banking and financial market infrastructure, health, drinking and waste water, digital infrastructure, ICT service management, public administration and space. Annex II covers postal and courier services, waste management, chemicals, food, manufacturing of medical devices, electronics, machinery and vehicles, digital providers such as marketplaces, search engines and social networks, and research.
The size test. Article 2(1) applies the directive to Annex I and II entities that are medium-sized or larger under Commission Recommendation 2003/361/EC and provide services or carry out activities in the Union. Medium-sized starts at 50 staff, or turnover and balance sheet above EUR 10 million; large starts at 250 staff.
Where size does not matter. Article 2(2) brings in, regardless of size, public electronic communications providers, trust services, TLD registries and DNS providers, sole providers of an essential service, entities whose disruption could hit public safety or create systemic risk, and central government. Article 2(4) adds domain name registration services.
Essential or important. Under Article 3(1), large Annex I entities are essential, as are qualified trust service providers, TLD registries, DNS providers and central public administration regardless of size. Article 3(2) makes every other Annex I or II entity that meets the size cap important.
Checklist item. Record sector, headcount, turnover, the member states where you provide services and the resulting tier.
Step 2: put the management duty in place (Article 20)
NIS2 moves cybersecurity to the boardroom. Article 20(1) requires the management body of an essential or important entity to approve the Article 21 risk-management measures and oversee their implementation, and states that it can be held liable for infringements of that article. Article 20(2) requires board members to follow training, and asks entities to offer similar training to employees regularly.
Evidence auditors accept. A board minute approving the measures by reference to a named policy set and date. A standing agenda item or quarterly report showing oversight. Training records per board member with content, provider and date. Supervisors look for the approval record first.
Step 3: implement the ten Article 21(2) measures
Article 21(1) requires "appropriate and proportionate technical, operational and organisational measures" to manage the risks to your network and information systems, proportionate to your exposure, size and likely incident impact. Article 21(2) says the measures include at least these ten.
(a) Policies on risk analysis and information system security. Evidence: a documented risk method, a dated risk register for the systems that deliver your service, and a security policy with management's approval record.
(b) Incident handling. Evidence: a response plan with roles, severity levels, escalation paths and the Article 23 reporting steps, an incident log, and an exercise record.
(c) Business continuity, including backup management, disaster recovery and crisis management. Evidence: recovery objectives per critical system, dated restore test results, and a crisis exercise report.
(d) Supply chain security, including the security aspects of relationships with direct suppliers and service providers. Evidence: a supplier inventory ranked by criticality, security clauses in contracts, and assurance from the suppliers that matter most (Article 21(3) asks you to weigh each supplier's specific vulnerabilities).
(e) Security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure. Evidence: secure procurement criteria, secure development practices, a patch process with timelines and compliance figures, and a published channel for outsiders to report vulnerabilities.
(f) Policies and procedures to assess the effectiveness of cybersecurity risk-management measures. Evidence: a written assessment programme naming methods and frequency, and the dated results it promised. Detailed below.
(g) Basic cyber hygiene practices and cybersecurity training. Evidence: a hygiene baseline mapped to your systems, and staff training completion records.
(h) Policies and procedures regarding the use of cryptography and, where appropriate, encryption. Evidence: a cryptography policy stating what is encrypted at rest and in transit, plus a key inventory.
(i) Human resources security, access control policies and asset management. Evidence: screening and joiner-mover-leaver procedures, an access policy with the latest review, and an asset inventory covering the systems in scope.
(j) Multi-factor or continuous authentication, secured voice, video and text communications and secured emergency communication systems, where appropriate. Evidence: MFA coverage figures for remote access, admin accounts and email at minimum, and an emergency communications plan.
Article 21(4) adds: if you find you do not comply, you must take corrective measures without undue delay. A documented gap left open is a gap a supervisor can act on.
The checklist at a glance: measure, evidence, owner
The owner column is a typical split; adjust it, but give every row a name. Evidence without an owner decays; an owner without evidence fails the audit.
| Article 21(2) measure | Evidence to produce | Typical owner |
|---|---|---|
| (a) Risk analysis and information system security policies | Risk method, dated risk register, approved security policy | CISO or security lead |
| (b) Incident handling | Response plan, incident log, exercise or incident record | Security operations lead |
| (c) Business continuity and crisis management | Continuity plan, restore test results, crisis exercise report | Operations or continuity lead |
| (d) Supply chain security | Ranked supplier inventory, contract clauses, supplier assurance | Procurement with CISO |
| (e) Acquisition, development, maintenance, vulnerability handling | Procurement criteria, secure development practice, patch figures, disclosure channel | Engineering lead |
| (f) Assessing effectiveness of measures | Assessment programme, dated test and audit results, remediation records | CISO with internal audit |
| (g) Cyber hygiene and training | Hygiene baseline, training completion records | IT operations with HR |
| (h) Cryptography and encryption | Cryptography policy, key inventory | Security architect |
| (i) HR security, access control, asset management | HR procedures, access review, asset inventory | HR with identity and access lead |
| (j) MFA and secured communications | MFA coverage figures, emergency communications plan | IT operations |
Step 4: build the incident reporting clock into your plan (Article 23)
Article 23 requires essential and important entities to notify their CSIRT or competent authority of any significant incident: one that caused or could cause severe operational disruption or financial loss, or considerable damage to others (Article 23(3)). Article 23(4) sets the clock:
- Early warning within 24 hours of becoming aware, stating whether you suspect malicious action and whether there may be cross-border impact.
- Incident notification within 72 hours, updating the early warning with an initial assessment of severity and impact and any indicators of compromise.
- Intermediate report on request from the CSIRT or authority.
- Final report within one month of the incident notification: detailed description, likely root cause, mitigation applied, cross-border impact.
- Progress report if the incident is still ongoing at that point, with the final report within one month of handling it.
Evidence auditors accept. A procedure for deciding an incident is significant, a prepared early-warning template, your CSIRT's contact details inside the response plan, and the timeline of one exercise that produced the 24-hour notice. Teams that have drilled it meet the clock.
Step 5: register, know your national law and your supervisor
NIS2 is a directive, not a regulation. Each member state turns it into national law and may add stricter rules. Article 41 required states to adopt their measures by 17 October 2024 and apply them from 18 October 2024. Not every state finished on time, so take your deadlines from the national law that covers the services you provide.
Registration. Article 3(3) requires each member state to list its essential and important entities; Article 3(4) requires entities to supply name, address, contact details including IP ranges, sector and the member states served. For eleven digital entity types, among them cloud, data centre, managed service and online platform providers, Article 27 adds an ENISA registry with a deadline of 17 January 2025; entities outside the Union give their designated representative's address.
Supervision. Essential entities face proactive supervision under Article 32: inspections, security audits, security scans, and requests for information and evidence. Important entities are supervised after the fact under Article 33, once the authority has an indication of non-compliance. Both allow warnings, binding instructions, orders to comply and public disclosure of infringements. For essential entities, Article 32(5) lets the authority, if other measures fail, suspend a certification or authorisation and request a temporary ban on the chief executive or legal representative exercising managerial functions until the breach is fixed.
Fines. Article 34(4) requires a maximum fine for essential entities of at least EUR 10,000,000 or at least 2 percent of total worldwide annual turnover in the preceding financial year, whichever is higher, for infringements of Articles 21 and 23. Article 34(5) sets the ceiling for important entities at at least EUR 7,000,000 or 1.4 percent, whichever is higher.
Where security testing fits: measure (f), and what to book
Measure (f) asks for policies and procedures to assess the effectiveness of your risk-management measures. The directive names no method. In practice auditors accept three kinds of evidence: internal audits against your own policies, independent reviews or certifications, and technical testing that shows whether the controls hold against an attacker. A penetration test is the technical half. Read NIS2 penetration testing for the detailed requirements.
What to test. The systems that deliver the service that put you in scope: the internet-facing perimeter, the customer-facing applications and APIs, and the internal network an attacker reaches after a foothold. On our platform those are external network, web application and internal network tests.
What the record should show. A dated report per asset with scope, each finding's severity and CVSS score, a remediation trail with owners and dates, and a retest confirming the fix. Budget Security delivers the report within 48 hours after the test ends; the findings workspace tracks each finding to closure. The retest is a paid add-on of one tester-day.
Cost. $985 per tester-day for US clients (€849 per day for EU clients), no setup or project-management fee, prices excluding VAT, payment after the report is delivered. A perimeter plus one application typically runs 3 to 5 tester-days. The pentest pricing calculator returns your figure; ordering creates a quote, not a payment.
A 90-day plan: the order that works
From a standing start, this order produces defensible evidence fastest.
- Days 1 to 15: scope and mandate. Confirm sector, size, tier and national law. Register where required. Have the board approve the policy set and minute it. Output: scope memo, board minute, registration confirmation.
- Days 16 to 45: foundations. Build the asset inventory and risk register (a, i). Write the response plan with the Article 23 clock and CSIRT contacts (b). Enforce MFA on remote access, admin accounts and email (j). Output: inventory, register, response plan, MFA report.
- Days 46 to 70: continuity and supply chain. Set recovery objectives, run a restore test and a tabletop crisis exercise (c). Rank suppliers and collect assurance from the top tier (d). Publish the disclosure channel and patch timelines (e). Output: continuity plan, supplier register, disclosure page.
- Days 71 to 90: assess and correct. Run the first penetration test on the perimeter and applications and an internal audit against the policies (f). Set the cryptography policy (h) and hygiene baseline with training (g). Track every finding to closure and retest (Article 21(4)). Output: test report, audit report, remediation log, retest record.
After day 90 it becomes a cycle: review the register yearly, test after every significant change and at least yearly, repeat management training, keep the incident drill fresh.
FAQ
NIS2 compliance checklist: frequently asked questions
Is NIS2 a law in my country?
Does NIS2 apply to US companies?
Does NIS2 require ISO 27001?
How often do I need to test under NIS2?
What is the difference between essential and important entities?
What is the difference between NIS2 and DORA?
What does management personally risk under NIS2?
Ready to tick off measure (f)?
Scope the perimeter, applications and internal network that deliver your in-scope service and see the tester-day plan and price before you commit. OSCP-certified testers, start within 7 days, report within 48 hours after the test ends.