ENISA’s NIS360 2026: NIS2 sector maturity, and where supervisors will likely look next

22 June 2026

Summary

The ENISA NIS360 is the EU cybersecurity agency’s annual assessment of how mature and how critical each high-criticality sector under the NIS2 Directive is. The 2026 edition, published on 28 May 2026, reports that sector maturity is steadily rising while criticality stays stable. The report places ICT service management, space, and several infrastructure sectors in a defined “risk zone.” If your product serves (or operates as) a managed service provider, a cloud or data-centre operator, or a digital infrastructure entity, the report signals where supervisory expectations are tightening. Read it as a map of where NIS2 enforcement attention will concentrate next.

What happened

On 28 May 2026, the European Union Agency for Cybersecurity (ENISA) published the third edition of its NIS360 report. The NIS360 is an assessment tool, not a binding instrument: it supports national authorities and policymakers in gauging the cybersecurity maturity and criticality of the sectors of high criticality identified under Annex I of the NIS2 Directive (Directive (EU) 2022/2555).

The methodology scores each sector across two dimensions. Maturity is built from four components: legislation and its effectiveness, companies and their preparedness, authorities and their institutional capacity, and sectoral ecosystem structures and their effectiveness. Criticality is ranked using systemic relevance, exposure, and the impact of disruption. ENISA draws on evidence from in-scope organisations, their national supervisors, and EU-level data.

The headline findings:

  • Maturity is rising. Trust services, aviation, and financial market infrastructures moved into the high-maturity band. Gas, road, maritime, and health strengthened within the moderate band.
  • Criticality is stable. Banking, electricity, aviation, space, and digital-by-default services such as telecoms, cloud, and data centres remain the most critical. Space joined this group, reflecting its growing role across other sectors. Railway rose in criticality, driven by its role in military logistics and heightened threat exposure.
  • The risk zone. ENISA defines a risk zone as sectors with lower-than-average maturity and a criticality that exceeds their maturity. The 2026 risk zone holds health, railway, maritime, ICT service management, space, public administrations, and drinking and waste water. Railway, drinking water, and waste water entered the zone this year; gas began moving out.

ENISA attributes rising maturity to cybersecurity legislation, increased political attention, and progress on specific maturity dimensions. Its 2025 NIS Investments study found that legislation has been a key driver of cybersecurity investment. Progress remains uneven across and within sectors, held back by skills shortages, sector-specific characteristics, and organisational size.

Why this matters for software businesses

The NIS360 is not law, but it reveals supervisory priorities for you.

Two of the sectors it tracks specifically address software companies. Annex I of NIS2 brings ICT service management (managed service providers and managed security service providers) and digital infrastructure (cloud computing services, data-centre services, content delivery networks, DNS, and trust services) directly into scope as essential or important entities. If you are one of these, the report tells you where you sit. 

It is worth noting that ICT service management is in the risk zone: its criticality runs ahead of its maturity, which is exactly the gap supervisors are mandated to close. Cloud and data-centre services sit among the most critical of all. Expect additional regulatory pressure if you operate in this space.

If you do not fall into either of these classes, you may unfortunately still be affected through the supply chain of customers in other critical sectors. If so you should anticipate pressure from sector players that are also in the risk zone.

NIS2 requires in-scope entities to manage the security of their supply chains and direct suppliers (article 21). A bank, hospital, or energy operator that must raise its own maturity will push that obligation down to the software vendors it depends on. This will reach you through security questionnaires, contractual security clauses, and evidence requests.

The maturity gap ENISA measures at sector level becomes a procurement requirement at your organisation’s level. You’ll need to support through your sales channel if you don’t want your sales cycles to lengthen considerably.

For product teams in your organisation, the report translates into engineering and governance priorities, and not just paperwork that can be supplied from within a legal or sales function. Most importantly:

  • NIS2’s risk-management measures (Article 21) expect technical and organisational controls proportionate to risk: access control, encryption, secure development and configuration, vulnerability handling, and business continuity.
  • The incident-reporting duty (Article 23) expects an early warning within 24 hours and a full notification within 72 hours of a significant incident, which only works if your product already produces the telemetry, logging, and detection signals that let you recognise an incident in time.

Build those obligations into the software development lifecycle: detection and logging by design, an incident workflow wired to the reporting clock, supplier security terms in your contracts, and retained evidence that a supervisor or a customer’s auditor can inspect. Retrofitting any of this after a significant incident is the expensive path.

Practical actions

Now:

  • Confirm whether your entity is in scope of NIS2 as an essential or important entity in ICT service management, digital infrastructure, or another Annex I/II sector. Assign a named owner for the result.

Next (within 6 months):

  • If you are in scope, map your current controls to the Article 21 risk-management measures and close the obvious gaps (logging, vulnerability handling, access control, supplier security).
  • Stand up or test an incident-reporting workflow that can meet the 24-hour early-warning and 72-hour notification windows.

Ongoing:

  • If you sell into critical sectors in the risk zone, expect security clauses and evidence requests in procurement; prepare a reusable evidence pack rather than answering each questionnaire from scratch.

Keep in mind

  • There is no published indication from ENISA that risk-zone placement will, by itself, trigger sector-specific supervisory action; the report is an input to authorities, not a mandate.
  • The Commission’s implementing rules on technical and methodological requirements bind only specific digital and infrastructure entities; how national supervisors will read the NIS360 against those rules is not yet settled in published guidance.

Suggested internal owner

Primary owner: Security (CISO or equivalent).
Should also involve: Legal, Compliance/risk, Product management, Engineering, and Procurement.
Rationale: Scope determination and the Article 21/23 control set are security-led, but contractual flow-down and supplier evidence require legal and procurement at the table.

Questions for software teams

  • Does our entity fall within an Annex I or Annex II NIS2 sector, and have we registered where required?
  • Do our cloud, data-centre, or managed-service offerings put us in the risk zone ENISA describes?
  • Can our product detect and surface a significant incident fast enough to meet a 24-hour early warning?
  • Do our logs and audit trails produce evidence a customer’s auditor or a supervisor would accept?
  • Are NIS2-aligned security obligations written into our contracts with direct suppliers?
  • If a critical-sector customer sends a security questionnaire tomorrow, can we answer it from a maintained evidence pack?

Sources and further reading

All URLs verified on 2026-06-22.

Disclaimer

This article reports a legal or regulatory development and explains its potential implications for software businesses, or highlights another development that may be relevant for legal or regulatory purposes. It does not constitute legal advice. The application of any legal requirement to your specific situation depends on facts, jurisdiction and context that this article cannot assess. If you would like to ascertain whether this development affects your product or business, seek advice from a lawyer who is qualified in the relevant jurisdiction(s).