A practical map of the NIS2 duties teams usually need to operationalize: scope classification, management-body accountability, Article 21 cybersecurity measures, Article 23 incident reporting, and evidence records.
Use it to turn the directive text and implementing regulation into an owner-backed requirements register for security, legal, risk, procurement, incident-response, and country operations teams.
Structured answer sets in this page tree.
Cited legal and guidance references.
NIS2 requirements start with entity classification and end with evidence. Before assigning controls, confirm whether the organization is an essential or important entity, which Annex I or Annex II sector applies, which Member State implementation controls the local duty, and whether a sector-specific EU law replaces overlapping NIS2 obligations because it is at least equivalent in effect.
Article 2 applies NIS2 to public or private entities of a type listed in Annex I or Annex II that qualify as medium-sized enterprises or exceed the medium-sized enterprise ceilings, and that provide services or carry out activities in the Union. The directive also includes specific size-independent categories, including public electronic communications providers, trust service providers, top-level domain name registries, DNS service providers, sole providers of essential services in a Member State, entities whose disruption could have significant effects, public administration entities, and critical entities under Directive (EU) 2022/2557.
Article 3 then classifies in-scope entities as essential or important. Large Annex I entities, qualified trust service providers, TLD name registries, DNS service providers, certain public communications providers, public administration entities, and entities identified by Member States under Article 2(2) can be essential. Other in-scope Annex I or Annex II entities that are not essential are important.
Article 20 requires Member States to ensure that management bodies of essential and important entities approve the cybersecurity risk-management measures used to comply with Article 21, oversee implementation, and can be held liable for infringements of Article 21. The same article requires management-body members to follow training and encourages regular employee training.
A requirements register should therefore name both the executive approval owner and the operational control owner. It should not treat governance as a policy formality; it should show how management reviews risk, approves measures, sees compliance-monitoring results, and receives incident or remediation updates.
Article 21 requires appropriate and proportionate technical, operational, and organisational measures to manage risks to network and information systems and to prevent or minimise incident impact on service recipients and other services. The measures must use an all-hazards approach and be proportionate to risk exposure, entity size, incident likelihood and severity, and societal and economic impact.
At minimum, the register should map Article 21(2)(a) through (j): risk analysis and information-system security policies; incident handling; business continuity, backup management, disaster recovery, and crisis management; supply-chain security for direct suppliers and service providers; secure acquisition, development, maintenance, vulnerability handling, and disclosure; effectiveness assessment; cyber hygiene and training; cryptography and encryption where appropriate; HR security, access control, and asset management; and multi-factor or continuous authentication plus secure communications where appropriate.
Article 23 requires essential and important entities to notify the CSIRT or competent authority, without undue delay, of significant incidents. A significant incident is one that has caused or is capable of causing severe operational disruption or financial loss for the entity, or considerable material or non-material damage to other natural or legal persons.
The notification workflow should preserve the directive's sequence: an early warning within 24 hours of becoming aware of the significant incident, an incident notification within 72 hours, intermediate reports if requested, and a final report not later than one month after the incident notification. For ongoing incidents, the entity provides a progress report at that time and a final report within one month of handling the incident. Trust service providers have a 24-hour incident-notification rule for significant incidents affecting trust services.
Commission Implementing Regulation (EU) 2024/2690 lays down technical and methodological requirements for Article 21(2) measures and further specifies significant-incident cases for 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, online marketplaces, online search engines, social networking services platforms, and trust service providers.
For those provider types, the requirements register should not stop at Article 21's high-level categories. It should use the regulation and ENISA guidance to detail the policies, risk framework, risk treatment, event detection, supply-chain policy, supplier register, secure acquisition, security testing, patch and vulnerability handling, cyber hygiene, cryptography, access control, asset classification, and physical or environmental security evidence that applies to the service.
A useful NIS2 requirements page should produce an evidence checklist, not a generic compliance statement. The evidence should connect each requirement to a legal source, service boundary, owner, implementation artifact, review cadence, and Member State authority path.
Keep the requirements register current when the entity changes services, sectors, EU countries, suppliers, digital provider status, incident process, or management-body approval route.
Covered essential and important entities need scope and classification records, management-body governance under Article 20, cybersecurity risk-management measures under Article 21, significant-incident reporting under Article 23, and any additional national or sector-specific requirements that apply in the relevant Member State.
Keep the legal source, Member State basis, entity classification, Article 21 control mapping, management approval, training records, supplier and service-provider evidence, security-test and remediation records, incident-clock logs, authority notifications, recipient communications, and review triggers.
Sorena can turn the NIS2 requirements on this page into source-linked scope decisions, Article 21 control mappings, incident-reporting workflows, owner assignments, and evidence requests.
Ask source-linked questions about NIS2 scope, Article 21 controls, Article 23 reporting, and implementation evidence using the cited sources on this page.
Review your NIS2 requirements register, source gaps, control evidence, and next implementation steps with Sorena.
"cybersecurity risk-management measures and reporting obligations"
"Technical Implementation Guidance"
"NIS2 Directive"
"relevant entities shall"