Securing network and information systems.
And proving that you do.

NIS2 is Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union. It is a Directive, not a regulation: it binds the Member States, each of which writes it into national law. What an organisation must do is therefore set by its national law, which follows the Directive and may go further.

It replaced Directive (EU) 2016/1148, the first NIS Directive, which covered far fewer sectors, left Member States to decide who was in scope, and was applied very unevenly. NIS2 sets a common size rule, adds sectors, harmonises the security measures and the incident reporting, makes management accountable, and gives supervisors real powers and fines.

The Directive and the Implementing Regulation

Article 21(2) of the Directive names ten risk-management measures in prose. Commission Implementing Regulation (EU) 2024/2690 turns them into an annex of thirteen numbered points with sub-requirements. It applies directly to a list of digital providers (DNS, top-level domains, cloud, data centres, content delivery, managed and managed security services, online marketplaces, search engines, social networks and trust services). For every other entity it is the most precise EU-wide reading of Article 21, and the one assessors cite.

Changes under discussion

In January 2026 the Commission proposed targeted amendments to NIS2, alongside a revision of the Cybersecurity Act, intended to simplify compliance and clarify the rules. Until any amendment is adopted and transposed, the Directive as written into national law applies; the measures and deadlines on this page are unchanged by the proposal.

Two things decide it: whether what you do is one of the eighteen sectors in Annex I or Annex II, and whether you are at least a medium-sized enterprise. A handful of entities are in scope whatever their size.

The size rule (Article 2(1))

The Directive applies to public or private entities of a type listed in Annex I or II that qualify as medium-sized enterprises under Commission Recommendation 2003/361/EC, or exceed its ceilings, and that provide their services or carry out their activities in the Union.

The figures are those of the Recommendation; partner and linked enterprises count towards them, so a small subsidiary of a large group is usually not small. Article 3(4) of the Recommendation's annex, which can let an enterprise keep SME status, does not apply for NIS2.

In scope regardless of size (Article 2(2))

• Providers of public electronic communications networks or publicly available electronic communications services.
• Trust service providers.
• Top-level domain name registries and DNS service providers.
• The sole provider in a Member State of a service essential to critical societal or economic activities.
• Entities whose disruption could significantly affect public safety, public security or public health, or create a significant systemic risk.
• Entities critical because of their specific importance at national or regional level.
• Public administration entities of central government, and at regional level where a risk-based assessment says so.
• Entities identified as critical entities under the Critical Entities Resilience Directive (EU) 2022/2557, and entities providing domain name registration services.

Who is excluded

The Directive does not apply to public administration entities that carry out their activities in national security, public security, defence or law enforcement, nor to the judiciary, parliaments and central banks. Member States may exempt specific entities in those fields.

Which country's law applies (Article 26)

As a rule, the Member State where the entity is established. Providers of public electronic communications fall under each Member State where they provide services. DNS, top-level domain and domain registration providers, cloud, data centre and content delivery providers, managed and managed security service providers, online marketplaces, search engines and social networks fall under the Member State of their main establishment in the Union; one established outside the Union must designate a representative in a Member State where it offers services.

Annex I lists eleven sectors of high criticality; Annex II lists seven other critical sectors. The annex you are in, together with your size, decides whether you are an essential or an important entity — not which measures apply.

Annex I — sectors of high criticality

Annex II — other critical sectors

Every in-scope entity is either essential or important (Article 3). The class changes how you are supervised and how large a fine can be. It does not change which security measures apply: all ten apply to both.

1. Question 1

   What do we actually do?

   Describe your activity in your own words and put it against the sectors and entity types above. Count every activity, not only the main one.

2. Question 2

   How big are we?

   Staff, turnover and balance sheet, including partner and linked enterprises. A rough answer is enough to start.

3. Question 3

   Where do we operate?

   Which Member States you are established in or provide services into. That decides whose law and whose authority.

4. Question 4

   Does a size-independent rule fit?

   Public communications, trust services, TLD or DNS, sole provider of an essential service, public administration, critical entity.

Annex I and above the medium ceilings usually means essential; Annex I at medium size, or Annex II, usually means important. Then check your national law and your authority's guidance, which may designate entities or add detail. If in doubt, ask your national authority: many publish a self-assessment and a registration form.

Member States had to establish, by 17 April 2025, a list of essential and important entities and of entities providing domain name registration services, and review it at least every two years (Article 3(3)). To build it, entities submit at least:

• their name;
• their address and up-to-date contact details, including email addresses, IP ranges and telephone numbers;
• the relevant sector and sub-sector in Annex I or II, where applicable;
• where applicable, the Member States in which they provide services in scope.

Changes must be notified without delay, and in any event within two weeks. Digital providers whose jurisdiction is their main establishment (DNS, TLD, domain registration, cloud, data centre, content delivery, managed and managed security services, online marketplaces, search engines and social networks) also submit their details for the registry ENISA keeps (Article 27), including their main and other establishments in the Union.

How and when to register is set by national law: look for your authority's registration platform and deadline.

Article 20(1): Member States shall ensure that the management bodies of essential and important entities approve the cybersecurity risk-management measures taken to comply with Article 21, oversee their implementation and can be held liable for infringements of that Article.

Article 20(2): members of management bodies are required to follow training, and entities are encouraged to offer similar training to their employees regularly, so that they gain enough knowledge and skills to identify risks and assess cybersecurity risk-management practices and their impact on the services the entity provides.

That is the change that moved cybersecurity from an IT budget line to the board's agenda. In practice an auditor will look for the board's approval of the measures, minutes showing oversight, and training records for each member.

Article 21(1) requires appropriate and proportionate technical, operational and organisational measures to manage the risks to the network and information systems used for your operations or services, and to prevent or minimise the impact of incidents. The measures must ensure a level of security appropriate to the risk, taking into account the state of the art, relevant European and international standards, and the cost of implementation. Proportionality weighs your exposure to risk, your size, and the likelihood and severity of incidents, including their societal and economic impact.

Article 21(2) says the measures follow an all-hazards approach — protecting the systems and their physical environment from incidents — and include at least the ten below. Proportionality applies to the depth of each, never to which ones you cover: the ten are a floor, not a menu.

(a) Policies on risk analysis and information system security

A documented method for identifying and assessing risks, a risk register, decisions on treatment and acceptance, and an information security policy approved by management. Monitoring can show that a technical baseline is applied on every machine; the risk analysis itself is documentary.

An auditor asks for: the risk assessment method and the current register; evidence the policy is enforced on systems, not only written.

(b) Incident handling

Detecting, analysing, containing and responding to incidents, with roles, an incident log and reviews afterwards. The first detection time is what an assessor compares your reporting against.

An auditor asks for: the incident log; detection-to-notification times for past incidents; proof that the 24-hour, 72-hour and one-month deadlines were met.

(c) Business continuity, such as backup management and disaster recovery, and crisis management

Continuity and recovery plans with recovery time and recovery point objectives, backups that are protected and tested, and a crisis organisation. The control most often failed at audit is the tested restore: a backup that ran proves nothing until data came back.

An auditor asks for: the continuity and recovery plan with objectives stated; the date and result of the last restore test.

(d) Supply chain security

Security in your relationships with each direct supplier and service provider. Article 21(3) requires you to take into account each supplier's specific vulnerabilities, the overall quality of their products and cybersecurity practices, including their secure development procedures, and the results of EU coordinated risk assessments of critical supply chains.

An auditor asks for: a register of suppliers ranked by criticality; their risk assessments; security clauses in contracts.

(e) Security in acquisition, development and maintenance, including vulnerability handling and disclosure

Security requirements when buying and building systems, secure configuration, change management, patching, security testing, and a way to receive and act on vulnerability reports.

An auditor asks for: a vulnerability management policy with fix deadlines by severity, and evidence they are met — time from detection to fix.

(f) Policies and procedures to assess the effectiveness of the measures

Measuring whether the measures work: indicators, internal audits, reviews by management, and what changed as a result.

An auditor asks for: a measurable trend over time, not a screenshot; evidence of periodic review and its outcome.

(g) Basic cyber hygiene practices and cybersecurity training

Patching, hardening, removal of default accounts, closed unused ports, and training for everyone appropriate to their role.

An auditor asks for: the technical hygiene baseline and current compliance against it; training records per person, with dates.

(h) Policies and procedures on cryptography and, where appropriate, encryption

Which algorithms and key lengths are approved, where encryption is required (at rest, in transit), and how keys are generated, stored, rotated and destroyed.

An auditor asks for: the cryptography policy; evidence of key lifecycle, especially rotation; encryption state of systems and connections.

(i) Human resources security, access control policies and asset management

Background checks where appropriate, joiner-mover-leaver processes, least privilege, periodic access reviews, and an inventory of assets with owners and classification.

An auditor asks for: evidence that leavers' access was removed, with dates; the last access review and who signed it; the asset inventory.

(j) Multi-factor or continuous authentication, secured communications and emergency communications

Multi-factor or continuous authentication, secured voice, video and text communications, and secured emergency communication systems, where appropriate.

An auditor asks for: multi-factor coverage by account type, exported from the identity provider; the exceptions and who approved each.

When you find a gap (Article 21(4))

An entity that finds it does not comply with the measures must take all necessary, appropriate and proportionate corrective measures without undue delay. A gap you found, recorded and closed is evidence of a working programme; a gap you hid is an infringement.

Adopted on 17 October 2024, the Implementing Regulation lays down the technical and methodological requirements of the Article 21 measures, and when an incident is significant, for: DNS service providers, top-level domain registries, cloud computing service providers, data centre service providers, content delivery network providers, managed service providers, managed security service providers, providers of online marketplaces, online search engines and social networking platforms, and trust service providers.

Being a regulation, it applies to them directly, without transposition. For everyone else it is the best available technical reading of Article 21, and the European Union Agency for Cybersecurity (ENISA) publishes technical implementation guidance for it.

The thirteen points of the annex

An essential or important entity must notify its national CSIRT or competent authority, without undue delay, of any significant incident. Where appropriate, it also notifies the recipients of its services of significant incidents likely to affect them, and tells recipients potentially affected by a significant cyber threat what they can do about it.

What makes an incident significant

An incident is significant if (Article 23(3)):

• it has caused or is capable of causing severe operational disruption of the services or financial loss for the entity; or
• it has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage.

For the digital providers it covers, the Implementing Regulation makes this concrete. An incident is significant if, among others, it caused or could cause financial loss above €500,000 or 5% of annual turnover, whichever is lower; the exfiltration of trade secrets; the death of a person or considerable damage to a person's health; or a successful, suspectedly malicious and unauthorised access to systems capable of causing severe operational disruption. Each type of provider also has service thresholds — for a cloud service, for example, being completely unavailable for more than 30 minutes. Incidents that recur at least twice in six months with the same apparent root cause count together.

The stages and their deadlines

The CSIRT or authority answers the early warning within 24 hours with initial feedback and, on request, guidance on mitigation. Reporting does not in itself make the entity more liable. Entities outside scope, and in-scope entities for incidents, threats and near misses that are not significant, may also notify voluntarily (Article 30).

What has to exist before the incident

• Monitoring that records the first detection with its time.
• A written way of deciding whether an incident is significant, and who decides.
• The contact details and forms of your CSIRT or authority, and who files.
• Templates for the early warning, the notification and the final report.
• A log of every incident, significant or not, with the decisions and the times.

Supply chain security is measure (d), with Article 21(3) asking you to weigh each direct supplier's vulnerabilities, product quality and secure development. The Cooperation Group, with the Commission and ENISA, can carry out coordinated security risk assessments of critical ICT supply chains (Article 22), whose results you must take into account.

Member States may require entities to use particular ICT products, services and processes certified under European cybersecurity certification schemes (Article 24), and encourage the use of European and international standards (Article 25).

In practice: keep a register of suppliers and service providers with their criticality, assess the critical ones, put security clauses in contracts (incident notification, audit rights, sub-processors, exit), and know which supplier software runs on your systems.

Each Member State designates one or more competent authorities and a single point of contact. Their powers depend on the class of entity.

Authorities must take the circumstances of each case into account: the seriousness and duration of the infringement, previous infringements, the damage caused, whether it was intentional or negligent, the measures taken to prevent or mitigate it, adherence to codes of conduct or certification, and cooperation.

These apply to infringements of Article 21 (the measures) or Article 23 (reporting). The Directive sets the minimum of the maximum: national law may set higher caps, add periodic penalty payments, and decide whether and how public administration entities are fined.

Natural persons responsible for an essential entity, or acting as its legal representative, can be held liable for breach of their duty to ensure compliance (Article 32(6)), and management bodies can be held liable under Article 20.

Where an infringement also involves a personal data breach, the authority informs the data protection supervisor; if a GDPR fine is imposed for the same conduct, no second NIS2 fine is imposed for it (Article 35).

NIS2 is not only a set of obligations for entities. It also creates the structures those obligations report into, which is worth knowing before an incident rather than during one.

Because NIS2 is a Directive, the obligations reach you through your national law. Member States follow the Directive but differ on registration platforms and deadlines, the authorities involved, the size of fines above the minimum, the treatment of public administration, and extra sectors they add. Several transposed late, and the Commission opened infringement procedures against those that had not notified their laws by the deadline.

Romania transposed NIS2 by Government Emergency Ordinance (OUG) no. 155/2024, approved by Law no. 124/2025. The national competent authority and CSIRT is the National Cyber Security Directorate (DNSC), where in-scope entities register and report incidents. Check DNSC's current guidance for the registration deadline, forms and reporting channel.

For any Member State: find the national law, the competent authority for your sector, its registration platform and its incident reporting channel. Those four facts are the first page of any NIS2 file.

1. Step 1

   Establish scope and class

   Run the four-question check; confirm with your national authority; register where required.

2. Step 2

   Make management own it

   Board approval of the programme, a named owner, management training, and a reporting rhythm to the board.

3. Step 3

   Know what you have

   Inventory of systems, data, cloud accounts, suppliers and the people with privileged access.

4. Step 4

   Assess the risks

   A method, a risk register, and decisions on treatment, measured against the ten measures and the 13 points.

5. Step 5

   Switch on continuous monitoring

   Events, vulnerabilities, hardening and sign-ins from every system, kept as evidence. Silence must be visible.

6. Step 6

   Prepare for incidents

   Detection, significance criteria, the 24 h / 72 h / one-month process, templates and contacts, then a rehearsal.

7. Step 7

   Close the technical gaps

   Multi-factor authentication, patching deadlines, hardening, segmentation, encryption, tested backups.

8. Step 8

   Write what must be written

   Policies, roles, continuity plans, supplier terms, cryptography and access policies — short, approved, used.

9. Step 9

   Train

   Management and staff, by role, with records.

10. Step 10

    Measure and review

    Indicators and trends, management review, corrective action without undue delay — and repeat.

Good evidence has three properties: it is recorded continuously, not written up the week before an inspection; it is tied to the numbered requirements, so an inspector can follow it line by line; and it includes what was wrong and whether it was fixed, not only the good news.

Other providers sell you cloud and servers and leave the security to you. TotulDigital's Cyber Security Compliance module watches your servers, your Cloud Office and your cloud accounts continuously, and turns what it sees into evidence mapped to NIS2 and the Implementing Regulation — alongside eleven other frameworks.

Two principles hold throughout. A control is shown as evidenced only where monitoring observes it; what it cannot see shows as no data, never as passed. And the module observes and reports — it never changes your systems: your team or your IT supplier fixes what it finds, and the next scan shows whether the fix worked. It gives you evidence for your auditor and regulator; it does not replace legal advice or a certification audit.

• Directive (EU) 2022/2555 (NIS2)
• CIR (EU) 2024/2690 Technical Annex
• ENISA Implementation Guidance