NIS2 Requirements Guide: What EU Organizations Need to Do

NIS2 requirements for in-scope organizations fall into four working areas: management accountability under Article 20, cybersecurity risk-management measures under Article 21, significant-incident reporting under Article 23, and evidence that those measures are actually in place. Article 21 names ten minimum security areas, but NIS2 is risk-based rather than a universal technology checklist.

For compliance work, the EU Directive is only one layer. Each organization also needs to check the national law and competent authority that apply in the Member State with jurisdiction over it. The core duties come from the same Directive, while registration, supervision, procedures, and enforcement can differ by country. The European Commission tracks national NIS2 implementation here.

Current-law note: This guide reflects Directive (EU) 2022/2555 as in force on 24 August 2026. The Commission proposed targeted amendments in January 2026, but that legislative procedure is still ongoing.

What are the main NIS2 requirements?

The shortest useful answer is that NIS2 asks an organization to know whether it is in scope, put management in charge of the security program, cover the ten Article 21 risk areas, report significant incidents on time, and be able to show supervisors how the program works. The table below keeps those pieces in one place.

Who must meet NIS2 requirements?

NIS2 covers organizations in 18 critical sectors identified by the European Commission, including energy, transport, health, digital infrastructure, public administration, manufacturing, food, chemicals, postal services, digital providers, and research. The common size rule brings medium-sized and larger entities in covered sectors into scope, but several categories are covered regardless of size, and Member States can identify other entities under the Directive's criteria.

That is why headcount alone is a poor scope test. A company can sit below a familiar employee threshold and still be covered because of the service it provides, its role in critical infrastructure, or a national designation. Article 3 of the Directive also separates covered organizations into essential and important entities.

The classification matters for supervision and enforcement, but it does not give important entities a lighter version of Articles 20, 21, and 23. Both categories need governance, risk-management measures, and incident reporting.

Read the NIS2 Essential Entity vs. Important Entity guide to own the classification test and the supervision differences.

What does NIS2 Article 21 require?

Article 21 of the NIS2 Directive requires essential and important entities to take appropriate and proportionate technical, operational, and organizational measures to manage cybersecurity risk and reduce the impact of incidents. The measures follow an all-hazards approach and must cover at least ten areas.

"Appropriate and proportionate" matters. A regional manufacturer and a pan-European cloud provider do not need identical security programs. The organization's size, exposure, likely incident impact, current technology, relevant standards, and implementation cost all affect what a reasonable control looks like.

This is the requirements list most people mean when they search for "NIS2 technical requirements." It is still only the top layer. Commission Implementing Regulation (EU) 2024/2690 adds more detailed technical and methodological requirements for specified digital infrastructure, ICT service management, digital provider, and trust service entities. ENISA's implementation guidance gives those entities practical examples and evidence mappings.

For other organizations, Article 21 remains risk-based. It does not say every company must buy the same tools, run the same architecture, or copy one control catalog.

Read the NIS2 Article 21 Measures: Full Breakdown dedicated page to cover implementation choices, evidence, and the boundary between the Directive and the 2024 implementing regulation.

What does NIS2 require from management?

Article 20 puts a specific job on the management body: approve the cybersecurity risk-management measures used to meet Article 21 and oversee their implementation. Members of the management body must also receive cybersecurity training.

In practice, that makes a vague "security is handled by IT" model hard to defend. Management needs enough information to approve the program, understand material gaps, ask what is still exposed, and follow whether agreed measures are actually being implemented.

The Directive also requires Member States to provide for management-body liability for infringements of Article 21, subject to national law. The exact liability mechanism therefore needs a country-specific check rather than a blanket statement about personal fines or management bans.

See NIS2 Management Liability: Article 20 to cover approval, oversight, training, and the national law boundary in more detail.

What are the NIS2 incident reporting requirements?

NIS2 uses a staged reporting process for significant incidents. Under Article 23, the standard sequence is an early warning within 24 hours of awareness, an incident notification within 72 hours, and a final report no later than one month after the incident notification.

An incident is significant when it has caused or can cause severe operational disruption or financial loss for the entity, or when it has affected or can affect other people or organizations through considerable material or non-material damage.

If the incident is still ongoing when the final report would be due, the entity provides a progress report at that point and a final report within one month after handling the incident. Trust service providers also have a specific 24-hour rule for the incident notification affecting their trust services.

The legal clock creates an operational problem: reporting cannot begin after the technical investigation is finished. Detection, escalation, legal or compliance assessment, evidence collection, and regulator communication need to run in parallel.

Free guide

Build the reporting clock into the incident plan

Use Q-Sec's NIS2 Incident Response Plan template to map escalation, the 24-hour early warning, the 72-hour notification, and evidence collection.

Get the NIS2 Incident Response Plan

Read NIS2 Incident Reporting Timeline: 24 Hours, 72 Hours, and One Month. The dedicated page will own the detailed reporting workflow.

Do essential and important entities have different NIS2 requirements?

The core organization-facing duties are largely the same. Both essential and important entities are subject to Articles 20, 21, and 23. The bigger difference is how authorities supervise and enforce those duties.

Essential entities can face proactive as well as reactive supervision under Article 32. Important entities are generally supervised after evidence, indications, or information suggest possible non-compliance under Article 33.

The Directive also sets different minimum required maximum fine levels for infringements of Articles 21 or 23. For essential entities, Member States must provide for a maximum of at least €10 million or 2% of worldwide annual turnover, whichever is higher. For important entities, the level is at least €7 million or 1.4%, whichever is higher. Article 34 contains the full conditions.

Those figures are not automatic penalties for every breach. National law, the circumstances of the case, supervisory measures, and the factors set out in the Directive affect the actual enforcement outcome.

What evidence should a NIS2 program be able to produce?

NIS2 does not publish one universal folder of documents that proves compliance. What matters is whether the organization can show that required measures exist, have owners, operate in practice, and are reviewed. Articles 32 and 33 give competent authorities powers to request information, documents, audit results, or other evidence depending on the entity and the national regime.

A useful test is simple: if a control is important enough to rely on, can the organization show what it covers, who owns it, when it was last reviewed, what happened when it failed, and what changed afterward?

This is evidence hygiene, not a statutory document checklist. The right evidence depends on the organization, the risk, the national law, and any sector-specific requirements.

Who usually owns the work inside the organization?

NIS2 does not make the security team the sole owner of compliance. Article 20 puts approval and oversight with management, while Article 21 reaches into procurement, HR, business continuity, system development, access management, supplier relationships, and incident handling. The practical program therefore crosses several teams.

The exact split will change by company. What should not change is the ability to name an owner. If an Article 21 measure exists only because "IT handles it," management has little visibility into whether the control is complete, tested, or even still operating as intended.

What does NIS2 not require?

A useful requirements guide also needs a boundary. NIS2 is specific about the areas organizations must cover, but it does not prescribe one identical security program for every entity.

• It does not require every organization to buy the same SIEM, EDR, SOC service, or other product. Tools are means of meeting a risk need, not the legal requirement itself.
• It does not provide one official universal document pack. Policies and records matter because they show how measures are governed and operated, not because a particular filename appears in the Directive.
• It does not let an organization transfer accountability to a provider. A managed service can perform monitoring, investigation, evidence collection, or other work, but the entity still owns its legal duties and business decisions.
• It does not make every national compliance process identical. The Directive sets the common baseline, while Member State law adds the local authority, procedure, registration, and enforcement layer.

This distinction is useful when a team starts turning a legal requirement into a procurement list. The first question should be what risk or duty needs to be covered. The product or service decision comes after that.

How do the NIS2 requirements connect during a real incident?

Consider a manufacturer in scope that discovers compromised administrator credentials on a production system. The first NIS2 question is not "Which article applies?" Several duties start touching the same event at once.

The incident-handling process under Article 21 needs to detect and investigate the activity. Access-control measures matter because privileged credentials are involved. Business-continuity planning matters if containment could stop production. If a remote service provider is part of the intrusion path, supply chain security enters the picture too.

At the same time, the team needs to decide whether the incident meets Article 23's significance threshold. If it does, the reporting clock begins from awareness of the significant incident. Management may need a rapid view of operational impact and residual risk while compliance or legal staff prepare the regulator-facing information and the technical team keeps investigating.

This is why treating NIS2 as ten separate boxes is awkward in practice. The measures meet each other during the messy parts: an outage, a compromised supplier account, a failed recovery, or an incident whose scope is still changing while a reporting deadline is approaching. A workable program defines those handoffs before they are needed.

Are NIS2 requirements identical in every EU country?

No. NIS2 creates a common EU baseline, but Member States transpose that baseline into national law and run their own competent authorities, registration processes, supervision, and enforcement. Article 5 also allows Member States to maintain or adopt provisions that provide a higher level of cybersecurity.

For a company operating across Europe, the sensible model is therefore two-layered. First map the common Directive requirements. Then map the national rules for each entity or service in scope. This is where registration deadlines, local reporting portals, authority names, and procedural details belong.

The European Commission NIS2 transposition tracker is the right starting point for the country layer. National authority guidance should then be checked before the organization sets a reporting or registration procedure.

For a group with entities in several Member States, that usually means keeping one common control framework while recording the local differences separately. The security measure may stay the same across the group; the authority, registration route, notification form, or enforcement process may not. That separation keeps the security program coherent without pretending Europe has one administrative procedure.

How do you turn NIS2 requirements into a workable program?

Start with ownership and evidence, not with a shopping list of security products. A practical sequence looks like this:

• Confirm scope, jurisdiction, and entity classification. Record why NIS2 applies and which national law and authority matter.
• Give management a real approval path. Define what the management body approves, what it receives for oversight, and who reports material gaps.
• Map the ten Article 21 areas to current controls. Mark what exists, what is partial, what is missing, and who owns each gap.
• Test the incident clock. Run a scenario and see whether the team can classify a significant incident, escalate it, collect evidence, and prepare the required information inside the legal timetable.
• Bring suppliers into the same risk model. Identify direct suppliers and service providers that can affect critical systems or service delivery, then decide how they are assessed and reviewed.
• Build an evidence trail into normal work. Connect each requirement to an owner, a control, the records that prove it operates, and a review point.

That sequence exposes a common problem quickly. Many organizations already have a firewall, backups, MFA, security policies, and some form of monitoring. The gap appears between those pieces: unclear ownership, weak evidence, untested reporting, or controls that nobody has checked recently.

Final thoughts: A NIS2 program should make ownership easy to see

A useful NIS2 program lets someone trace a requirement to the risk it addresses, the person who owns it, the control that performs the work, the evidence that proves it, and the point at which it is reviewed. When one of those links is missing, the weakness is usually operational before it is regulatory.

That is also the cleanest way to keep NIS2 from becoming a policy-writing project. Security teams can see what needs to change. Management can see what it is approving. Compliance teams can see what can be proved.

Frequently asked questions about NIS2 requirements

How many NIS2 requirements are there?

There is no single official "NIS2 requirements list." Article 21 names ten minimum cybersecurity risk-management areas, while Articles 20 and 23 add management and incident-reporting duties.

What are the NIS2 technical requirements?

Article 21 sets risk-based security areas rather than one universal control catalog. Commission Implementing Regulation (EU) 2024/2690 adds detailed technical requirements for specified digital and trust-service entities.

Does NIS2 require ISO 27001 certification?

No. NIS2 does not require every covered organization to hold ISO/IEC 27001 certification. ISO 27001 can support parts of a NIS2 program, but NIS2-specific governance, reporting, scope, and national duties still need to be addressed.

Does NIS2 require a SIEM or SOC?

No specific SIEM or SOC product is universally required. Organizations need security measures, monitoring, incident handling, and evidence appropriate to their risks. The operating model and tools depend on the environment.

Does NIS2 require penetration testing?

NIS2 requires organizations to assess the effectiveness of cybersecurity risk-management measures, but it does not impose one universal penetration-testing schedule on every entity. National or sector-specific rules can add detail.

What are the NIS2 reporting deadlines?

For a significant incident, the standard sequence is a 24-hour early warning, a 72-hour incident notification, and a final report no later than one month after that notification.