NIS2 requirements: what the Directive requires of entities

What NIS2 requires of an in-scope entity

Directive (EU) 2022/2555 imposes governance, risk-management, reporting and registration duties on essential and important entities, and those duties have applied through national transposition laws since 18 October 2024. A customer, contract or national authority asking for NIS2 compliance is therefore asking you to show that your management body approves and oversees the cybersecurity risk-management measures, that those measures meet Article 21, that you can report significant incidents on the required clock, and that your details are registered with the competent authority. The Directive sets the floor, but the national law sets your actual obligations, including the competent authority, registration portal and fine ceilings.

Your classification as essential or important is the first decision that shapes the duties. Both classes face the same Article 21 risk-management measures and Article 23 reporting duties, but essential entities face ex ante supervision while important entities face ex post supervision (Articles 32 and 33). Article 3(4) also requires you to give the competent authority your name, address, contact details including email addresses, IP ranges and telephone numbers, your Annex I or II sector and subsector, and the Member States where you provide services. Confirm with your national authority which registration process applies, which deadlines it sets, and whether your national law adds requirements beyond the Directive, since Article 5 allows Member States to set a higher level of cybersecurity.

Start by mapping each duty to an owner and a piece of evidence: management body approval records and training for Article 20, the policies and measures behind Article 21(2)(a) to (j), and a documented reporting process that can meet the 24-hour early warning, the notification and the one-month final report in Article 23(4). For digital providers and the other entities named in Implementing Regulation (EU) 2024/2690, confirm which technical requirements of that regulation apply to you. Ask your legal team or the national authority to confirm the exact obligations, because they are not fixed by the Directive text alone.

Which duties apply to every in-scope entity

Whether an entity is essential or important, the Directive attaches the same core duties to it. The cards below cover registration, management body accountability, the Article 21 measures, reporting and supervision, and each one names who inside the organization owns the work.

Registration and entity details

Article 3(4) requires an entity to give its competent authority its name, address and contact details, including email addresses, IP ranges and telephone numbers, its Annex I or II sector and subsector, and the Member States where it provides services. The owner is usually the compliance lead or legal function, working with IT to confirm the IP ranges. Check the registration portal and deadlines in your national transposition law, because the mechanism is set nationally.

Management body approval and oversight

Article 20(1) requires the management body of each essential and important entity to approve the cybersecurity risk-management measures taken under Article 21 and to oversee how they are implemented. The board or equivalent executive body carries this duty personally, so approval should appear in board minutes with the measures and their owners named. Confirm that the board receives regular reporting on open risks and remediation, not only a yearly policy sign-off.

Management body training

Article 20(2) requires members of the management body to follow training that gives them enough knowledge and skills to identify cybersecurity risks and assess how risk-management practices affect the entity's services. The board members themselves must complete it, and HR or the company secretary usually tracks attendance. Ask for a curriculum that covers the entity's actual systems and supplier dependencies, and keep dated records that a supervisor can inspect.

Article 21 risk-management measures

Article 21(1) requires appropriate and proportionate technical, operational and organizational measures to manage risks to network and information systems and to limit the impact of incidents on service recipients. Article 21(2) lists the minimum measures, starting with policies on risk analysis and information system security. The CISO or head of security owns the program, and each measure needs a documented owner, a current risk assessment and evidence that it operates in practice.

Staged incident reporting

Article 23(4) sets a staged timeline for significant incidents: an early warning without undue delay and within 24 hours of becoming aware, a notification with further detail, and a final report no later than one month after the notification. The final report must cover severity and impact, the likely threat or root cause, mitigation measures and any cross-border impact. The incident response lead owns the clock, so the 24-hour trigger and the named recipients should be in the response plan before an incident occurs.

Supervision and administrative fines

Essential entities face ex ante supervision and important entities face ex post supervision under Articles 32 and 33, and NIS2 creates no certificate of compliance. For infringements of Articles 21 or 23, Article 34(4) sets maximum fines for essential entities of at least EUR 10 000 000 or at least 2% of total worldwide annual turnover in the preceding financial year, whichever is higher. The executive team and legal function should own the response to inspections and information requests, and national law may set higher ceilings than the Directive.

What the management body must approve, oversee and learn

What does approving the Article 21 cybersecurity measures mean in practice?

Approval means a named management body formally adopts the cybersecurity risk-management measures the entity has chosen to meet Article 21, and records that decision. Article 20(1) requires Member States to ensure that management bodies of essential and important entities approve these measures and oversee their implementation. In practice, the board or equivalent body should see a written risk-management policy covering the Article 21(2) areas, the risk assessment behind it, the budget and the owners of each measure, and then minute its approval. A signed approval without the underlying document will not satisfy a supervisor, so keep the approved version, its date and any later changes together. Confirm with your national competent authority how it expects this approval to be recorded, because transposition laws set the exact form.

What oversight evidence do supervisors expect from management?

Supervisors look for proof that the management body does more than approve a policy once. Article 20(1) also requires oversight of implementation, so the evidence should show recurring review. Useful records include board or committee minutes that show cybersecurity on the agenda, status reports on open risks and remediation, decisions taken on those reports, and budget or resource decisions linked to the measures. Keep a register of risk acceptance decisions signed by a member of management. Gaps appear when minutes say only that security was noted. Ask your competent authority which records it treats as sufficient, and check ENISA's non-binding examples of evidence for the technical measures, since they show what supervisors may ask to see.

What training does Article 20(2) require for management body members?

Article 20(2) requires members of the management body to follow training so that they gain enough knowledge and skills to identify cybersecurity risks and to assess risk-management practices and their effect on the entity's services. The Directive does not prescribe a course, hours or a certificate. The training should fit the entity: its sector, its services, its main risks, and the decisions the board actually makes, such as budget, supplier selection and incident response. Record who attended, when, the content covered and the date of the next refresher. Ask providers what the sessions cover against the risk areas in your entity's own risk assessment, and treat any course that promises a legal compliance certificate with caution, since NIS2 creates no certificate.

Can management members be held personally liable for NIS2 infringements?

Management members can face personal consequences under NIS2, but the exact rules depend on national transposition laws. Article 20 makes management bodies responsible for approving and overseeing the Article 21 measures, and it provides that natural persons in management roles can be held responsible for breaches of that duty, with temporary bans from management functions available in serious cases. Fines under Article 34 apply to the entity. Whether a specific board member faces personal exposure, and how it is enforced, is set by each Member State's law. Have legal counsel review your national transposition text and the company's directors and officers cover, and confirm with the competent authority how it applies the liability and suspension provisions.

Who should own the management body's NIS2 duties day to day?

The management body keeps the decisions, but someone must prepare the material and track follow-up. Typically a CISO, security officer or a designated executive prepares the risk report, the measure status and the training plan, and the board approves and reviews them. An outside vCISO or consultant can prepare these papers, but cannot replace the board's approval or the entity's accountability for its controls. Document the split in the governance section of the policy so that each duty has one owner and one reviewer. Ask any provider to state in writing which deliverables it prepares and which decisions remain with your management body.

How often should the board review NIS2 cybersecurity measures?

The Directive does not set a fixed review interval for the management body, so the frequency should follow the entity's risk profile and the pace of change in its environment. A common approach is a scheduled review at least annually for approval of the policy and risk assessment, with interim reporting whenever a significant incident, major system change or new supplier risk occurs. Confirm the expected cadence with your competent authority and any sector regulator, since national rules or sector laws may set stricter expectations. Record the schedule in the governance policy so supervisors can see that oversight is planned, not ad hoc.

Does management training cost money, and what drives the price?

Yes, training has a cost, but the Directive does not set the amount, and no supplied figure is available for it here. The main components are the provider's fee for designing or delivering sessions, the time board members spend away from other duties, and any internal staff time to prepare materials and track attendance. Costs rise with bespoke content tied to your own risk assessment, multiple sessions for new members, and in-person delivery. Costs fall when training is delivered as a short briefing within an existing board meeting. When requesting quotes, ask for the outline mapped to your risk areas, the number of sessions, whether refresher training is included, and how attendance records are returned to you.

The ten Article 21 measures and what evidence each needs

Article 21(1) requires appropriate and proportionate measures to manage risks to network and information systems and to prevent or minimize the impact of incidents, across all hazards. Article 21(2) lists ten minimum measures, grouped below by the evidence they produce. The Article 21 measures page and Implementing Regulation 2024/2690 add technical detail where the entity is a digital provider.

Risk analysis and security policies

Article 21(2)(a) requires written policies on risk analysis and information system security, which form the base the other nine measures rest on. An assessor will ask for a documented risk methodology, a current risk register tied to the entity's services, and policies approved by the management body under Article 20. Check that each policy names an owner, a review date and the systems it covers, and confirm with your competent authority which evidence it accepts for approval.

Incident handling and continuity

Measures (b) and (c) cover incident handling and business continuity, including backup management, disaster recovery and crisis management. Evidence includes an incident response procedure, a log of past incidents with how each was handled, tested backups with restore records, and recovery plans with recovery targets the entity has set. These steps feed the Article 23 reporting clock, so detection and triage must be fast enough to support the 24-hour early warning.

Supply chain and secure development

Measures (d) and (e) cover supply chain security and security in acquisition, development and maintenance, including vulnerability handling and disclosure. Entities need supplier security assessments, contract clauses covering security and incident notice, a secure development lifecycle with code review and testing, and a process to receive, triage and patch vulnerabilities. Digital providers should read the specific requirements in Implementing Regulation 2024/2690 before setting these processes.

Effectiveness checks and hygiene training

Measure (f) requires policies and procedures to assess whether the other measures work, and measure (g) covers basic cyber hygiene practices and cybersecurity training. Evidence includes a schedule of control testing, such as internal audits, security scans and penetration tests, with findings and closure records. Training attendance and course content for staff should also be kept. Confirm whether test results reach the management body, which must oversee the measures under Article 20.

Cryptography and access control

Measure (h) covers policies on cryptography and encryption, while measure (i) covers human resources security, access control policies and asset management. Evidence includes an encryption standard listing approved algorithms and key lengths, key management records, joiner-mover-leaver procedures, periodic access reviews and an up-to-date asset inventory. Each item should trace to a named system owner so an assessor can match the policy to the live configuration.

Multi-factor and secured communications

Measure (j) asks for multi-factor or continuous authentication where appropriate, secured voice, video and text communications, and secured emergency communication systems within the entity. Evidence includes an MFA coverage report for remote access, administrative and privileged accounts, configuration records for encrypted communications, and a tested fallback channel for emergencies when primary systems fail. Confirm with your assessor which systems count as in scope.

How the 24-hour, one-month reporting clock works

The sequence turns an incident into a timed record of what happened, what was done and what comes next, so authorities receive an early signal quickly and a detailed account within one month of notification. Each stage produces a document you can show a supervisor.

Record when awareness begins
The clock starts when the entity becomes aware of a significant incident, so the first task is to fix that moment in writing. The incident lead, supported by the security team, opens an incident record with the date, time and source of the first signal, such as a monitoring alert, a supplier notice or a staff report. Confirm with your national competent authority or CSIRT how awareness is defined in your national law, because the transposition text sets the exact trigger. The record is complete when it shows a timestamp that can be defended later.
Classify the incident as significant
Before the early warning is due, the incident lead decides whether the event meets the significance criteria. For digital providers covered by Implementing Regulation (EU) 2024/2690, the regulation sets specific criteria. Other entities should apply the criteria in their national transposition law and any guidance from their authority. The team records the facts that support the decision, including the services affected and the likely impact on service recipients. The step is done when a signed classification note exists, whether the incident is significant or not.
Send the early warning within 24 hours
Under Article 23, an essential or important entity must submit an early warning without undue delay and in any event within 24 hours of becoming aware of a significant incident. The early warning is short. It states that a significant incident has occurred and records whether it may be caused by unlawful or malicious acts or could have cross-border effects, based on what is known at that point. The reporting lead sends it through the channel named in national law and keeps the sent copy with the timestamp. The step is done when the confirmed submission is on file within the deadline.
Submit the incident notification
The notification stage follows the early warning and adds a fuller assessment of the incident, including its initial severity and impact and any indicators the team has found. The content, timing and format are set by the Article 23 provisions and by national law, so confirm them with your authority before an incident occurs. The step is complete when the notification is submitted and logged. The reporting page covers this stage in detail, including the duties toward service recipients.
Gather facts for the final report
Over the following weeks, the team collects the evidence the final report must contain. This includes the severity and impact of the incident, the type of threat or the likely root cause, the mitigation measures already applied and those still ongoing, and any cross-border impact. Incident responders, system owners and, where relevant, suppliers provide the inputs, and the lead reconciles them with the timeline. The step is done when each required element has a source document, such as log extracts, change records or forensic notes.
Submit the final report within one month
Under Article 23, the final report is due no later than one month after the incident notification. It describes the incident in detail, covering severity, impact, threat type or likely root cause, mitigation applied and ongoing, and cross-border impact. Management reviews the report before submission, and the reporting lead files it through the channel set by national law. The step is complete when the filed report, its approval record and the submission receipt are stored together.
Keep the timeline as audit evidence
Once the final report is filed, the incident file becomes evidence for the supervisor. It should hold the awareness record, the significance decision, the early warning, the notification, the supporting facts and the final report, in order. Ask your authority which retention period applies and whether it expects the file in a specific format. The step is done when a reviewer can follow the sequence from awareness to final report without asking the team for missing records.

What happens when an entity falls short

NIS2 creates no certificate of compliance. No body issues a NIS2 certificate that proves an entity meets Article 21 and Article 23, so a regulator cannot be satisfied by a badge or a report alone. Instead, national competent authorities oversee compliance through inspections, security audits, security scans and information requests, and they can impose administrative fines when an entity infringes the Directive. Essential entities face ex ante supervision, meaning authorities can check compliance before a failure occurs, while important entities face ex post supervision, which typically starts after an incident or a signal that something has gone wrong. The reader should treat evidence as the thing an authority will ask for, not a certificate it will accept.

For essential entities, Article 34(4) sets maximum administrative fines for infringing Article 21 or Article 23 of at least EUR 10 000 000 or at least 2% of total worldwide annual turnover in the preceding financial year, whichever is higher. The 2% figure scales with the group's global revenue, so a large group's exposure can exceed the fixed amount by a wide margin. These are ceilings, not automatic penalties, and the actual maximum that applies to an entity comes from its national transposition law, which may set a higher level of cybersecurity than the Directive. Confirm with the competent authority in each Member State where you provide services which fine ceilings and enforcement powers apply to your entity.

The practical decision for management is whether the evidence exists before an inspection starts. Ask who will hold the policies, risk analysis, incident records and management body approvals that an authority would request, and how quickly they can be produced. Plan for information requests with short deadlines and for scans or audits that test controls you have described in your own documentation. Your compliance cost estimate should therefore include the work to keep evidence current, not only the work to build controls once. Check the enforcement powers in your national law with counsel, and record that check so the management body can show it oversaw the question.

Who owns each NIS2 duty: the entity, a partner and the authority

The in-scope entity carries every NIS2 obligation under its national transposition law. Article 20(1) requires that the management body approves the Article 21 risk-management measures and oversees their implementation, and Article 20(2) requires its members to train so they can assess cybersecurity risk. Outside help does not move these duties to a vendor.

Management body: approves the risk-management measures, oversees their implementation and completes the required training.
Security owner: holds the day-to-day responsibility for policies, risk analysis and the incident response process.
Operations teams: run the controls, patching, access management, backups and logging that generate the evidence.
Incident reporting: the entity itself submits the early warning, notification and final report to its competent authority.
Contracts and suppliers: the entity decides which providers it uses and keeps the records of how they were assessed.

Before engaging any partner, confirm in writing which of these duties your management body will keep, and who in your organization signs off each one.

Where NIS2 programs usually stall

Most NIS2 programs do not fail on the technical controls. They stall earlier, on questions of who is in scope, which national law applies and whether management and the evidence can prove the duties were met. The cards below cover the delays we see most often and a practical way to avoid each one.

Unclear entity classification

Before any Article 21 measure is scoped, the entity must know whether it is essential or important under Article 3 and which Annex I or Annex II sector and subsector it belongs to. Classification drives supervision: essential entities face ex ante supervision and important entities face ex post supervision. Write the sector, subsector and Member States of service in one document, and check it against the entity details the competent authority will ask for.

No national law check

NIS2 is a directive, so the obligations, registration portals and fine ceilings that bind an entity come from its national transposition law, which may set a higher level than the Directive. Teams that build a program only from the Directive text often find out late that a local rule adds deadlines or duties. Confirm the national law, its competent authority and its registration route before the program plan is approved.

Governance evidence missing

Article 20 expects the management body to approve the Article 21 risk-management measures and oversee their implementation, and its members must follow training. Many programs have technical controls but no minutes showing approval, no record of who was trained and no owner who reports back. Schedule a board decision on the measures, keep the signed approval and training records, and set a recurring agenda item for progress.

Reporting clock not tested

Under Article 23 an early warning is due within 24 hours of becoming aware of a significant incident, and a final report within one month of the notification. A written procedure that nobody has run tends to fail on the first real event, when the on-call engineer, the legal team and the management contact each wait for another to decide. Run a tabletop exercise against the 24-hour clock, record how long each decision took and fix the gaps before an actual incident.

Supplier duties not flowed down

An in-scope entity remains responsible for its supply chain risks, yet contracts with cloud hosts, managed service providers and software vendors often lack incident notification terms, audit rights or security requirements. The gap usually surfaces during a supervisory information request. Review each critical supplier contract, add notification timelines that fit your own 24-hour clock and confirm that the supplier can produce the logs and attestations you will need.

Evidence scattered across tools

Supervisors ask for proof that a measure exists and works, and that proof usually sits in a ticketing system, a patch tool, a SIEM, an identity provider and several spreadsheets. When it is scattered, staff spend the audit window rebuilding history instead of answering questions. Assign each Article 21 measure an owner and an evidence location, and set a schedule for exporting and dating that evidence so it can be produced on request.

NIS2 requirements questions buyers ask

Does NIS2 have a certificate I can obtain?

No. NIS2 creates no certificate of compliance. National competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines, as set out in Articles 32 to 34 of the Directive. Your evidence is the set of documents, configurations, logs and records that show you manage risk under Article 21 and report under Article 23. Some customers ask for ISO/IEC 27001:2022 certification as a proxy, but that certificate is issued by an accredited certification body and does not, by itself, prove NIS2 compliance. Ask any provider who claims to issue a "NIS2 certificate" which body accredited them and what the document actually attests.

Are all the Article 21 measures binding, or can we pick some?

Article 21(1) requires appropriate and proportionate technical, operational and organizational measures, and Article 21(2) lists the minimum areas that must be covered, from risk analysis and incident handling to supply chain security, vulnerability handling, cryptography and access control. Proportionality lets you scale how deep each measure goes according to your risk, size and exposure, but it does not let you skip an area that applies to your entity. The detail for digital sectors comes from Commission Implementing Regulation (EU) 2024/2690, and the national law that transposes NIS2 in your Member State may add requirements. Confirm both with your competent authority and your legal adviser, because the obligations you carry depend on that national text.

What does the 24-hour early warning mean in practice?

The 24-hour clock starts when you become aware of a significant incident, and Article 23(4)(a) requires an early warning without undue delay and in any event within 24 hours. Awareness is the trigger, so the clock can start before you understand the full impact. In practice, the early warning should be a short, pre-approved message to your national CSIRT or competent authority, sent by someone who has authority to submit it at any hour. Teams usually need a defined triage step, named decision makers, contact details that work out of hours, and a template. Your reporting process must also fit the later 72-hour notification and the one-month final report, which are covered on the incident reporting pages.

Can our own team handle NIS2 compliance without outside help?

Many organizations can, especially when they already run an information security management system and have staff who understand risk assessment, access control and incident response. The obligations fall on the entity, and management must approve the Article 21 measures and oversee them under Article 20. Work that usually stays in-house includes risk decisions, policy approval, accountability for incidents and the final reporting judgment. Internal teams often need outside support for a gap analysis against Article 21, for building technical evidence, for testing controls and for training management body members. Estimate your internal effort by listing each Article 21 area, the owner, the evidence you already produce and the gaps. Then compare that list with your team's capacity before you decide.

What can an implementation partner do for NIS2, and what can it not do?

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, and it runs security testing. For NIS2, that means preparing systems, controls and evidence for your assessments. DeployOpen does not issue audit reports, attestations or certifications, and it cannot accept responsibility for your compliance decisions. Those decisions stay with your management body. Independent auditors and certification bodies are the parties that issue reports or certificates. Engagements are normally fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support or continuous testing can follow under a retainer. Ask any partner to show you which deliverables it produces and which decisions it leaves to you.

How do the proposed COM(2026) 13 amendments change our NIS2 duties?

The Commission proposed targeted amendments to NIS2 on 20 January 2026 under COM(2026) 13, including a new small mid-cap category. The proposal still needs approval by the European Parliament and the Council, and Commission pages updated through July 2026 describe it as a proposal. Until it is adopted and transposed, the current Directive and your national law set your obligations, so do not plan around the proposal as if it were in force. Monitor the outcome, because a change in category could alter which supervisory regime applies to you. Check your entity classification against the current text with your national authority and legal adviser when the amendments move forward.

Do national laws change the NIS2 requirements that apply to us?

Yes. NIS2 is a directive, so your concrete obligations, competent authority, registration portal and fine ceilings come from the national transposition law in each Member State where you operate. Article 5 allows Member States to adopt or keep rules that ensure a higher level of cybersecurity, so a national law can add to the Directive. The Article 34(4) ceiling for essential entities is at least EUR 10 000 000 or at least 2% of total worldwide annual turnover in the preceding financial year, whichever is higher, but your national law defines what applies to you. Confirm the transposition status and your national requirements before you scope the program.

How DeployOpen prepares NIS2 systems and evidence

NIS2 asks in-scope entities to run appropriate and proportionate risk management, governance and incident reporting, and the obligations come through national transposition laws. DeployOpen prepares the systems, controls and evidence behind those duties on self-hosted open-source platforms inside your own infrastructure. Your organization keeps ownership of its controls, and independent authorities and auditors judge compliance.

How we scope

Scope is agreed in writing before work starts, listing the systems, entities and Article 21 areas covered.
We confirm which national transposition law and competent authority apply to the entity before scoping controls.
Ongoing support, upgrades and continuous testing can be added as a retainer after the initial fixed-scope work.

How we build

We plan and implement self-hosted open-source platforms for logging, access control, backup and vulnerability management in your environment.
We harden, integrate and customize these platforms so they produce the records a supervisor would ask to see.
Security testing of applications, APIs, cloud and infrastructure checks whether the implemented measures hold in practice.

How we hand over

We document configurations, procedures and evidence sources so your team can show how each measure is operated.
Governance material, such as records of management body approval and training, is prepared for your leadership to review and own.
Reporting workflows for the 24-hour early warning, notification and final report are documented and can be exercised with your team.

How we support

Your organization owns its controls and decisions, and we confirm the scope of what our work does and does not cover.
We do not issue audit reports, attestations or certificates, because only independent auditors or assessors can do that.
Before a supervisory review or assessment, confirm with your counsel and the competent authority what evidence they expect.