NIS2 expands cybersecurity obligations across the EU, bringing more organizations under requirements for risk management, incident reporting and management oversight.
For organizations assessing their obligations, the starting point is to establish whether they are covered, which national rules apply, and what they need to implement. Security teams then need to translate those requirements into controls, operating procedures and evidence that the measures work.
This guide explains NIS2’s scope, its main cybersecurity requirements, where security testing fits, and how to organize implementation.
What is the NIS2 Directive?
The NIS2 Directive, Directive (EU) 2022/2555, establishes a common cybersecurity framework for covered entities across 18 sectors. It replaces the original NIS Directive with broader coverage, more detailed requirements and stronger supervision.
Its main obligations concern cybersecurity risk management, reporting significant incidents, and management accountability. EU Member States implement the directive through national legislation, so organizations must check the laws and competent authorities relevant to their activities.
NIS2 dates and national implementation
NIS2 entered into force on 16 January 2023. Member States were required to transpose it into national law by 17 October 2024, and NIS1 was repealed from 18 October 2024.
The transposition deadline should not be treated as a single company compliance deadline covering every jurisdiction. Applicable obligations, registration procedures and implementation dates must be checked against national legislation.
The European Commission maintains a national transposition overview.
2026 update: In January 2026, the European Commission proposed changes to clarify NIS2’s rules and simplify compliance. As of October 2026, these amendments have not been adopted. Organizations must continue following the existing requirements applicable in their country.
Does NIS2 apply to your organization?
A scope assessment needs to consider the organization’s sector, services, size and relevant exceptions. Operating in a listed sector does not automatically mean every business in that sector is covered.
Sectors covered by NIS2
The directive divides sectors between Annex I, covering sectors of high criticality, and Annex II, covering other critical sectors.
| Annex | Sectors |
|---|---|
| Annex I | Energy; transport; banking; financial market infrastructures; health; drinking water; wastewater; digital infrastructure; ICT service management between businesses; public administration; space. |
| Annex II | Postal and courier services; waste management; manufacture, production and distribution of chemicals; food production, processing and distribution; specified manufacturing activities; digital providers; research. |
Coverage depends on the entity types and activities defined in each annex. For example, the manufacturing category covers specified subsectors rather than manufacturing generally.
Company size and exceptions
As a general rule, NIS2 covers medium-sized and larger entities of the types listed in its annexes. The size assessment uses the EU SME definition, which considers employee numbers and financial criteria, including turnover and balance-sheet total.
It is not a requirement to have both more than 50 employees and turnover above €10 million. For example, an independent company employing exactly 50 people already exceeds the small-enterprise staff threshold.
Relationships with partner and linked enterprises can also affect the calculation. Organizations belonging to a group should assess the relevant aggregated figures rather than looking only at the local company.
Certain entities can be covered regardless of size, including DNS service providers, top-level domain registries, trust service providers, and providers of public electronic communications networks or publicly available electronic communications services. Other exceptions concern particular critical services and entities identified by national authorities.
A useful scope assessment should record:
- The services and activities that may bring the organization into scope.
- The relevant annex and entity type.
- The size calculation and any applicable exceptions.
- The jurisdiction and competent authority.
- The resulting classification and registration obligations.
Essential and important entities: what is the difference?
NIS2 classifies covered organizations as essential entities or important entities. Classification depends on size, entity type and specific designation rules.
Large Annex I entities generally fall into the essential category. Other covered entities generally fall into the important category, subject to exceptions. Annex I and Annex II should therefore not be treated as interchangeable labels for essential and important entities.
Both categories are subject to cybersecurity risk-management and incident-reporting obligations. The main differences concern supervision and enforcement.
| Area | Essential entities | Important entities |
|---|---|---|
| Cybersecurity risk management | Required | Required |
| Significant-incident reporting | Required | Required |
| Supervisory approach | Proactive and reactive supervision | Generally reactive supervision where authorities receive evidence or indications of non-compliance |
| Administrative fine framework for breaches of Articles 21 or 23 | Required maximum of at least €10 million or 2% of worldwide annual turnover, whichever is higher | Required maximum of at least €7 million or 1.4% of worldwide annual turnover, whichever is higher |
The turnover calculation concerns the undertaking to which the entity belongs and the preceding financial year. These are requirements for national penalty frameworks, rather than automatic fines for each breach. Applicable national law determines the precise enforcement arrangements.
What cybersecurity measures does NIS2 require?
Article 21 requires appropriate and proportionate technical, operational and organizational measures to manage cybersecurity risks and prevent or minimize incident impacts.
The measures must follow an all-hazards approach, taking account of risks to systems and their physical environment. Their implementation should reflect the organization’s exposure, size, service criticality and potential incident consequences.
The following table summarizes the required areas and suggests practical evidence organizations can retain. The evidence examples are starting points, not a universal audit checklist.
| Required area | Practical implementation and evidence examples |
|---|---|
| Risk analysis and information-system security | Maintain a risk assessment, approved security policies and assigned risk owners. |
| Incident handling | Establish response procedures, escalation contacts and incident records; exercise the process. |
| Business continuity and crisis management | Maintain backup and recovery arrangements, continuity plans and records of recovery exercises. |
| Supply-chain security | Assess direct suppliers, define contractual security expectations and track identified supplier risks. |
| Secure acquisition, development and maintenance | Establish security requirements, secure development practices and vulnerability-handling procedures. |
| Assessment of control effectiveness | Review and test relevant controls; document findings, corrective actions and follow-up results. |
| Cyber hygiene and training | Maintain awareness programmes and role-specific training records. |
| Cryptography and encryption | Define appropriate cryptographic policies and document their implementation. |
| Human resources, access control and asset management | Maintain asset inventories, access reviews, privileged-access controls and joiner, mover and leaver procedures. |
| Authentication and secure communications | Implement MFA or continuous authentication and secure communications where appropriate. |
These areas come from Article 21; the implementation examples illustrate how an organization could make its programme reviewable.
For each applicable measure, establish an owner, a review schedule and a way to identify outstanding actions. A policy should connect to the systems, people and processes it governs.
What are management’s responsibilities?
Management bodies of both essential and important entities must approve the cybersecurity risk-management measures and oversee their implementation. Member States must ensure that they can be held liable for infringements of Article 21, subject to the applicable legal framework.
Management-body members must also receive training so they can identify risks and assess cybersecurity practices and their impact on services.
To support that oversight, security teams should give management a clear view of:
- The critical services and systems at risk.
- Significant control gaps and remediation priorities.
- Resources needed to address those gaps.
- Testing and exercise results.
- Outstanding risks requiring a decision.
Record approvals and follow-up actions so responsibilities remain visible as the programme develops.
What are the incident-reporting requirements?
NIS2 requires covered entities to report significant incidents. Significance concerns severe operational disruption or financial loss, or considerable material or non-material damage to other people or organizations, including incidents capable of causing those effects.
The general reporting sequence starts when the entity becomes aware of a significant incident.
| Stage | General deadline | Main information |
|---|---|---|
| Early warning | Without undue delay, within 24 hours | Whether unlawful or malicious acts are suspected and whether there may be cross-border effects. |
| Incident notification | Without undue delay, within 72 hours | An initial assessment of severity and impact, updated information and available indicators of compromise. |
| Intermediate report | When requested by the CSIRT or competent authority | Relevant status updates. |
| Final report | Within one month of the incident notification | Incident description, severity, impact, likely cause, mitigation and relevant cross-border effects. |
If the incident is still ongoing when the final report is due, the entity submits a progress report and subsequently a final report within one month of handling the incident.
Trust service providers have a specific 24-hour incident-notification requirement for significant incidents affecting their trust services.
Organizations should identify their reporting authority, submission channel and internal approval process in advance. Exercises can reveal whether the team can classify an incident, collect the initial facts and submit a notification within the available time.
NIS2 also includes communication obligations towards affected service recipients in relevant circumstances. Regulatory reporting and customer communications should be planned together.
Where does penetration testing fit into NIS2?
NIS2 requires organizations to assess the effectiveness of their cybersecurity risk-management measures. Penetration testing can support that assessment by examining whether weaknesses can be exploited and how far an attacker could progress.
The directive does not prescribe one universal annual penetration test for every covered entity. Testing requirements must be assessed against applicable national rules, sector requirements and the organization’s risks.
Additional requirements for specified digital providers
Commission Implementing Regulation (EU) 2024/2690 sets technical and methodological requirements for specified providers, including:
- DNS providers and top-level domain registries.
- Cloud, data-centre and content-delivery-network providers.
- Managed service providers and managed security service providers.
- Online marketplaces, search engines and social-networking platforms.
- Trust service providers.
For covered entities, the regulation requires security-testing policies and procedures. The need, scope, frequency and type of tests must be established through risk assessment, with documented methods, results and mitigation of critical findings.
ENISA’s Technical Implementation Guidance provides non-binding implementation advice, evidence examples and mappings to standards. It should be used alongside the applicable requirements and national guidance.
For a detailed explanation, read Security Testing Requirements of NIS2 Implementing Regulation.
Making testing useful
A testing programme should answer specific questions about the services being protected. For example:
- Can an exposed application give access to sensitive administrative functions?
- Can a compromised user reach privileged systems?
- Does segmentation restrict access between relevant environments?
- Have remediation changes removed the identified exploitation path?
Agree the scope around those questions. Keep the report connected to remediation owners, deadlines and retest results, so findings lead to measurable changes.
For an example grounded in Blaze’s assessments, see Common Oil, Gas and Energy Vulnerabilities Found in 2025 Pentests.
How to organize NIS2 implementation
A practical implementation programme can follow six steps.
1. Establish scope and jurisdiction
Document the organization’s activities, classification and applicable national requirements. Identify the competent authority and any registration procedures.
2. Assess the current gaps
Compare existing governance, controls and procedures with the applicable requirements. Record what exists, what needs improvement and where evidence is missing.
3. Assign owners and priorities
Give each action an owner and target date. Prioritize weaknesses according to their potential impact on critical services, alongside mandatory implementation deadlines.
4. Implement and exercise the measures
Update technical controls, supplier processes, incident handling and continuity arrangements. Exercise procedures with the people who will use them.
5. Validate and remediate
Choose assessments suited to the risk: configuration reviews, vulnerability assessments, penetration tests, recovery exercises or other relevant evaluations. Track corrective actions and verify significant fixes.
6. Maintain the programme
Review the programme after incidents, major changes and scheduled assessments. Update risk decisions, policies and evidence as services and dependencies evolve.
Budget for the programme as a whole: staff time, technical improvements, supplier reviews, training, exercises, assessments and remediation. Estimates should reflect the organization’s starting point and complexity.
How does NIS2 relate to DORA, the CRA and ISO 27001?
These frameworks address different activities and can overlap within the same organization.
| Framework | Main focus | Relationship to NIS2 |
|---|---|---|
| DORA | Digital operational resilience in the financial sector | Acts as sector-specific legislation for covered financial entities where its relevant requirements displace corresponding NIS2 provisions. |
| Cyber Resilience Act | Cybersecurity of products with digital elements | Addresses product obligations; an organization may also have NIS2 obligations concerning its operations and services. |
| ISO/IEC 27001 | An information security management system | Can support organized risk management and evidence, but certification alone does not establish NIS2 compliance. |
NIS2 and DORA were aligned to provide coherence between the general and financial-sector frameworks. Organizations should assess the applicable provisions rather than assuming that all requirements apply twice.
ENISA's guidance includes mappings to standards such as ISO/IEC 27001. Those mappings help reuse existing work while identifying requirements that need separate attention.
Read Blaze's guides to DORA and the Cyber Resilience Act for more detail.
Frequently asked questions
Can a small company fall under NIS2?
Yes. Although the general scope rule concerns medium-sized and larger entities, exceptions bring certain entities into scope regardless of size. Group relationships can also affect the size assessment.
Does NIS2 require annual penetration testing?
There is no universal annual penetration testing requirement in the directive for every covered entity. Applicable national or sector rules may impose more specific obligations. For entities covered by Implementing Regulation 2024/2690, testing decisions must be based on risk assessment.
Does ISO 27001 certification make an organization NIS2 compliant?
Certification can support implementation, but organizations must still assess their applicable NIS2 requirements, including reporting, management responsibilities and national procedures. ENISA's mappings provide a useful starting point for that comparison.
Can suppliers outside NIS2's direct scope be affected?
Yes. Covered entities must address security risks involving direct suppliers and service providers. Suppliers may consequently receive security questionnaires, contractual requirements or requests for assessment evidence. Those requests should be distinguished from the supplier's own statutory obligations.
Validate the security measures supporting your NIS2 program
Blaze helps organizations assess applications, infrastructure and cloud environments, investigate exploitation paths, and verify remediation.
Testing scope should reflect the services you need to protect and the controls you need to evaluate. Findings and retest results can then support the broader governance and evidence program.
