NIS2 in 2026: EU directive 2022/2555, 18 sectors, essential and important entities, fines up to EUR 10 million

Origins: from NIS to NIS2

Its predecessor, directive 2016/1148, was the first European horizontal regulation in the field. Before it, cybersecurity was regulated only sector by sector, chiefly in finance and telecommunications. After a few years of application the European Commission identified four weaknesses, each of which the new instrument answers.

The first was inconsistent transposition: member states understood key notions differently, including the definition of an essential service and the thresholds for incident significance, so the same entity might be covered in one state and free of obligations in another. The second was too narrow a scope, limited to seven sectors, leaving out waste management, food production and postal services among others. The third was sanctions, symbolic in some states relative to the scale of the risk. The fourth was that cybersecurity remained an IT department matter and did not engage the leadership of the organisation.

The timeline of the new directive is short, but four different dates are worth keeping apart. It was adopted on 14 December 2022, published in the Official Journal on 27 December 2022 and entered into force on 16 January 2023. The transposition deadline fell on 17 October 2024, and the following day the NIS directive was repealed. By 17 April 2025 member states were to draw up their first lists of covered entities.

The directive does not operate in isolation from other instruments. Commission Implementing Regulation (EU) 2024/2690 ^[2] of 17 October 2024 sets out the technical requirements for the article 21(2) measures and the thresholds above which an incident counts as significant - but only for digital service providers and trust service providers, not for every covered entity. Alongside it runs the CER directive (2022/2557) ^[3], which governs the physical resilience of critical entities and complements NIS2 rather than competing with it. Implementation guidance is published by ENISA ^[9].

Scope: eighteen sectors

NIS2 splits the covered sectors across two annexes, the first of the two criteria determining an entity's qualification. Annex I covers sectors regarded as highly critical and creates a presumption of the stricter regime; annex II covers the other critical sectors.

Annex I: highly critical sectors

1. Energy - electricity, district heating and cooling, oil, gas and hydrogen, including system operators, storage and distribution.
2. Transport - air, rail, water and road, including infrastructure managers and traffic management system operators.
3. Banking - credit institutions.
4. Financial market infrastructure - trading venue operators and central counterparties.
5. Health - healthcare providers, EU reference laboratories, entities conducting research on medicinal products, and manufacturers of critical medical devices during a public health emergency.
6. Drinking water - suppliers and distributors of water intended for human consumption.
7. Waste water - collection, disposal and treatment of urban, domestic and industrial waste water.
8. Digital infrastructure - internet exchange points, DNS service providers, top-level domain registries, cloud and data centre providers, content delivery networks, trust service providers and providers of public electronic communications networks and services.
9. ICT service management - managed service providers and managed security service providers.
10. Public administration - mandatory at central level; covering the regional level is left to the member state.
11. Space - operators of ground-based infrastructure supporting space services.

Annex II: other critical sectors

1. Postal and courier services.
2. Waste management.
3. Manufacture, production and distribution of chemicals.
4. Production, processing and distribution of food.
5. Manufacturing - of medical devices and in vitro diagnostics, computers and electronics, electrical equipment, machinery, vehicles and other transport equipment.
6. Digital providers - online marketplaces, search engines and social networking platforms.
7. Research - research organisations.

Eighteen sectors is a considerable widening on the seven covered by NIS. It is worth remembering, though, that belonging to a sector does not by itself settle whether the obligations apply - that follows only in combination with the size of the entity.

Essential and important entities

The second criterion is the size of the enterprise, measured against the definition in Commission Recommendation 2003/361/EC. A medium enterprise employs fewer than 250 people and has annual turnover not exceeding EUR 50 million or a balance sheet total not exceeding EUR 43 million. A small enterprise employs fewer than 50 people and stays under EUR 10 million, and a micro enterprise fewer than 10 people and EUR 2 million. Anything outside those thresholds is large.

The construction of the definition is a source of confusion, because the financial thresholds are joined by "or", not "and". A firm employing 120 people with EUR 80 million turnover therefore remains medium, so long as its balance sheet total does not exceed EUR 43 million - landing in the lighter category despite a turnover suggesting otherwise. Qualification also has to account for capital links, because the recommendation requires the data of partner and linked enterprises to be aggregated.

Combining the two criteria gives four situations. A large enterprise in an annex I sector is an essential entity. A medium enterprise in the same sector, and a large or medium enterprise in an annex II sector, are important entities. Small and micro enterprises are as a rule outside the scope - and it is that rule the directive qualifies most.

Article 2(2) of NIS2 names categories covered regardless of size: providers of public electronic communications networks and publicly available electronic communications services, trust service providers, top-level domain registries and DNS providers, some public administration entities, and entities designated by a member state as critical for national security, public order or public health. A one-person firm running a domain registry is therefore covered on the same footing as an energy operator.

Both categories carry identical substantive obligations - the same risk management measures and the same incident reporting regime. They differ in supervision and in sanctions. For essential entities supervision is ex ante: the authority may inspect or audit at any moment, without first establishing an infringement. For important entities it is ex post - triggered only once there is an indication of an infringement. The upper limits on fines differ too, as described below.

Ten risk management measures (article 21(2))

Article 21(1) requires essential and important entities to take appropriate and proportionate technical, operational and organisational measures, taking account of the state of the art, relevant standards and the cost of implementation. Paragraph 2 expands that into a catalogue of ten categories lettered a to j. It is a minimum catalogue and deliberately general - the directive names neither specific technologies nor frequencies, leaving that to risk analysis.

The first four categories build the management skeleton. Point (a) requires policies on risk analysis and information system security, point (b) incident handling covering detection, analysis, containment, eradication and lessons learned; a methodological treatment of that process is given by NIST SP 800-61 Rev. 3 ^[12], which treats response as part of risk management rather than a separate stage triggered by an alert. Point (c) concerns business continuity, including backup management, disaster recovery and crisis management. Point (d) introduces supply chain security, to which a separate section of this article is devoted.

The next three concern the system lifecycle and verification. Point (e) covers security in the acquisition, development and maintenance of systems, including vulnerability handling and disclosure. Point (f) requires policies and procedures for assessing the effectiveness of the measures adopted - the basis for audits, penetration testing and vulnerability scanning, though the directive imposes no frequency. Point (g) speaks of basic cyber hygiene practices and training, covering both hardening of workstations and servers and a programme of building staff awareness.

The last three descend to the technical level. Point (h) concerns policies on the use of cryptography and, where appropriate, encryption. Point (i) combines human resources security, access control policy and asset management. Point (j) is broader than its colloquial name suggests: it covers not only multi-factor or continuous authentication but also secured voice, text and video communications and secured emergency communication systems - the ability to coordinate when the primary communications infrastructure is unavailable or presumed compromised.

One widespread inaccuracy is worth correcting. Management training is sometimes listed as an eleventh measure under article 21. It is not: the duty of regular training for members of the management body comes from article 20(2) and is a separate construction, addressed to different people and enforced differently. Article 21(4) adds that an entity finding any measure unmet is to take corrective action without undue delay - so the duty operates between audits as well.

Supply chain security

Article 21(2)(d) together with article 22 form the most developed requirements on supplier risk in European law. The provision expressly covers security aspects in the relationship between an entity and its direct suppliers and service providers, which marks the boundary of responsibility: an organisation does not answer for the whole chain, but it must answer fully for its own link. Article 21(3) adds that in selecting measures, the vulnerabilities specific to each supplier and the overall quality of their practices are to be taken into account.

In practice that means four groups of activity. The first is identifying critical suppliers, meaning those whose failure or compromise would affect the ability to provide your own service. The second is assessing the associated risk, covering not only the technical dimension but also concentration - the situation where many processes cannot be moved to another supplier. The third is carrying the requirements into contracts: security clauses, audit rights and an obligation to report incidents. The fourth is ongoing oversight, based on reviewing certificates, audit reports and the supplier's incident history.

Article 22 adds a European mechanism. The Cooperation Group, together with the Commission and ENISA, may carry out coordinated risk assessments of designated critical supply chains for ICT services, systems and products. The results are not a binding prohibition, but they genuinely shape purchasing decisions across the Union.

For the Polish IT market the indirect consequence matters most. Providers of cloud services, data centres, content delivery networks and managed services - including security services - belong to annex I sectors, and trust service providers are covered regardless of size. A hosting firm or an integrator that had no obligations at all may therefore be an essential or important entity in its own right and, independently of that, feels pressure from clients who have to demonstrate oversight of their supply chain. It is one of the strongest transmission mechanisms in the whole directive, because it works without any involvement from a supervisory authority.

Incident reporting: 24 hours, 72 hours, one month

Article 23 uses the notion of a significant incident and defines it in paragraph 3 by two criteria: the incident 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. Meeting either is enough.

Reporting has three main stages, and the deadlines run from becoming aware of the incident, not from its occurrence. Within 24 hours the entity submits an early warning to the relevant CSIRT, indicating where applicable whether the incident is suspected of being caused by unlawful or malicious acts and whether it could have cross-border impact. Within 72 hours it submits the incident notification, containing an initial assessment of severity and impact and, where available, indicators of compromise. No later than a month after that notification it submits a final report: a detailed description of the incident, the type of threat or root cause, the mitigation measures applied and any cross-border impact. Where the incident is ongoing, a progress report takes the place of the final one, which follows a month after handling ends. Independently of that, the CSIRT or the authority may request an intermediate report at any time.

The obligation does not end with the authority. Article 23(1) requires, where appropriate, notifying recipients of the service of a significant incident that may adversely affect its provision, and paragraph 2 of a significant cyber threat together with the measures recipients can take. It is worth noting the directive also provides for traffic the other way: the CSIRT is to respond to an early warning within 24 hours where possible and may provide technical support.

Numerical thresholds exist but have limited reach. Regulation 2024/2690 ^[2] sets them only for digital service providers and trust service providers. For a cloud provider an incident is significant if, among other things, the service is completely unavailable for more than 30 minutes, or its availability is limited for more than an hour for more than 5 per cent of users in the Union or for more than a million users - whichever number is smaller. Those are two separate criteria, not one compound test; confusing them leads to under-reporting. The other sectors have no numerical thresholds and must assess severity for themselves.

The greatest operational difficulty remains establishing the moment the organisation "became aware". That is a judgement, not a technical fact, so the procedure should state in advance whose classification starts the clock - usually the moment the monitoring team classifies an event as an incident meeting the criteria of article 23(3). The functions of such a team and the typical difficulties in running one are set out in a review of security operations centres ^[13] (see the SOC article). The second difficulty is incomplete information in the first day, but the directive assumes exactly that: an early warning is a signal, not a report. The third is the multiplicity of addressees where an incident affects recipients in several member states.

Responsibility of the management body (article 20)

Article 20 is one of the furthest-reaching changes in the whole directive, because it moves cybersecurity from the operational level to the management body. Paragraph 1 imposes three linked duties: approving the risk management measures adopted to comply with article 21, overseeing their implementation, and bearing responsibility for infringements of that duty. Paragraph 2 adds an obligation to undergo regular training allowing risks to be identified and risk management practices assessed, and encourages similar training for staff.

The construction matters because it shifts the burden of proof. Approval of a policy by a resolution of the management body, a documented reporting cycle and records of training attended are evidence nobody previously had to gather and that a supervisory authority can now check directly. The absence of such evidence is an infringement regardless of how well the technical controls work.

Personal liability does not follow directly from the directive - article 32(5) leaves its shape to member states, naming two possible measures: a temporary ban on holding management functions on a natural person acting as chief executive or legal representative and, for essential entities, temporary suspension of authorisation to operate. For public administration entities the provision is without prejudice to national rules on official liability. The Polish amendment to the KSC act ^[4] introduces its own sanctions regime, phased in on the schedule described below.

The practical consequences for an organisation are predictable. Whoever is responsible for information security gains a reporting line direct to the management body, policies stop being IT department documents, and budget decisions require justification tied to specific requirements. The management body also has to have a defined role in handling an incident, above all in external communication and strategic decisions.

Administrative fines

The upper limits differ by category of entity. For essential entities, article 34(4) requires member states to provide for a maximum fine of at least EUR 10,000,000 or at least 2 per cent of the total worldwide annual turnover of the undertaking in the preceding financial year, whichever is higher. For important entities article 34(5) provides analogously for EUR 7,000,000 or 1.4 per cent. For large corporate groups that means the percentage threshold, not the fixed sum, is what binds in practice.

The amount is not, however, arbitrary. Article 32(7) requires competent authorities to respect the rights of the defence and to take eight factors into account: the seriousness of the infringement and the importance of the provisions breached, its duration, relevant previous infringements by the entity, the material and non-material damage caused including the effect on other services and the number of users affected, whether the act was intentional or negligent, the measures taken to prevent or mitigate the damage, adherence to approved codes of conduct or certification mechanisms, and the degree of cooperation with the authority. The provision also names five infringements to be regarded as serious in every case: repeated infringements, failure to notify or remedy significant incidents, failure to remedy deficiencies contrary to binding instructions, obstruction of audits or monitoring, and supplying false or großly inaccurate information about the article 21 measures or the article 23 notifications.

Alongside fines the directive provides non-financial measures, often more painful in practice: an order to cease the infringement, an order to implement audit recommendations, publication of the infringement and, for essential entities, temporary suspension of authorisation or a ban on holding management functions.

The scale of the change is clearest in comparison. The Polish national cybersecurity system act in its 2018 wording ^[5] provided for fines of a few hundred thousand zloty - two orders of magnitude lower. After transposition, breaching cybersecurity duties becomes a regulatory risk comparable to breaching data protection law, with the difference that part of the sanction can be addressed to a person rather than only to the organisation.

European cooperation

NIS2 expands the cooperation structure, in which four kinds of body operate with clearly separated roles. The Cooperation Group, composed of representatives of the member states, the Commission and ENISA, works at the strategic level: exchanging good practice, issuing methodological guidance and running coordinated supply chain risk assessments.

The CSIRTs network links national incident response teams and works operationally. Poland is represented in it by the national teams operating under the KSC act. The network serves the exchange of information about cross-border incidents, mutual technical assistance and joint exercises.

New in article 16 is EU-CyCLONe, the European cyber crisis liaison organisation network. It works at the political and strategic level, alongside the operational CSIRTs network, and is to coordinate management of a crisis of European scale and build a shared situational picture for political decisions. Separating those two levels is deliberate: experience shows that in a serious cross-border incident the bottleneck is often not technical analysis but agreeing decisions between states.

ENISA's role is strengthened in the directive. The agency supports member states methodologically, publishes technical guidance on the article 21 measures ^[9], runs European exercises, manages cybersecurity certification schemes and publishes an annual threat landscape ^[6] and foresight studies ^[10] useful in multi-year planning.

Relationships with DORA, CER, the GDPR, the KSC act and the AI Act

NIS2 is not the only regulation a typical organisation is subject to, and overlapping regimes are a source of conflicting interpretations. The clearest case is the financial sector. DORA ^[8], applicable since 17 January 2025, is lex specialis to NIS2: for ICT risk management, incident reporting, digital resilience testing and oversight of third-party providers, a bank applies DORA rather than the provisions transposing NIS2. Outside those areas it remains under the general regime (see the DORA article).

The CER directive ^[3] is a sibling regulation rather than a competing one: NIS2 concerns digital resilience, CER physical resilience. An energy operator is usually subject to both, and the authorities competent under each are obliged to exchange information.

With data protection law the relationship is complementary but leads to a double reporting duty. Ransomware encrypting personal data is simultaneously a significant incident under NIS2 and a personal data breach, which starts two independent clocks towards two different authorities. The internal procedure should anticipate that, because in practice what usually fails is not the notification itself but the coordination of the two paths (see the GDPR article).

In Poland, though, the relationship with the national cybersecurity system act matters most: since 3 April 2026 entities apply the amended act rather than the directive directly (see the KSC article). Separately, the AI Act does not replace cybersecurity requirements but adds to them requirements specific to high-risk AI systems; an entity using such a system in an essential service satisfies both regimes in parallel (see the AI Act article).

Transposition in Poland

Transposition was effected by the act of 23 January 2026 amending the act on the national cybersecurity system and certain other acts (Journal of Laws 2026 item 252) ^[4]. It replaced the former category of operator of essential services with a two-tier split into essential and important entities, carried all eighteen sectors into national law, and changed how status is established: instead of an administrative decision of the authority, entities register themselves.

For the public sector the employment criterion matters most. A municipal office is an essential entity if it employs at least 50 people in full-time equivalent terms on employment contracts, as at 1 January of the given year - so annex 1 to the act provides in the "Public entities" sector. It is not a population threshold and it is not an exemption threshold: a smaller office does not qualify as an essential entity on that basis, but it may be covered as an important entity or through its organisational units. Voivodeship and regional government offices are covered regardless of headcount.

The schedule spreads the obligations over several years, and four dates are worth keeping apart. The amendment entered into force on 3 April 2026. Entities that already met the criteria on that day are to discharge the chapter 3 obligations by 3 April 2027. The first article 15 audit falls for that same group on 3 April 2028, and subsequent ones take place at least every three years, counted from the signing of the previous report, which goes to the competent authority. Entities meeting the criteria later count those deadlines from their own date. The periodic audit duty applies only to essential entities; an annual review of the information security management system is instead required by the act of an important entity that is a public body.

The delay in transposition did not pass without consequence. The European Commission opened infringement proceedings against states that had not notified full transposition on time - Poland was among them, and the amendment entering into force was the answer to that.

What to prepare now

The starting point is establishing your own status. That means checking sector membership against both annexes, calculating enterprise size taking capital links into account, and documenting the result - including where it comes out negative, because the absence of such an analysis is itself often the subject of inspection findings. Only then does a gap analysis make sense, mapping existing policies, procedures and controls onto the ten categories of article 21(2) (see the KSC and NIS2 audit article).

The order of the remaining work follows from the statutory schedule rather than convenience. The chapter 3 obligations are due from 3 April 2027, so by then the things with the longest lead time have to be working: monitoring and incident handling together with a reporting procedure and tested contact channels, multi-factor authentication for remote access and privileged accounts, a cryptography policy together with key management, and a business continuity plan with a documented backup restore test. Putting the supply chain in order usually takes longest, because it requires renegotiating contracts and therefore the other side's agreement.

The organisational layer runs in parallel: appointing someone responsible for information security with a reporting line to the management body, setting the reporting cycle, and planning and documenting training for members of that body as article 20(2) requires. An independent compliance audit closes it, giving a reference point before the first statutory audit.

The commonest mistakes in this period repeat. The first is putting work off until the obligations become due - the transition period is often too short for changes requiring contract renegotiation or architectural rebuilding. The second is assuming an ISO/IEC 27001 certificate ^[7] is enough; it is a good base, but it covers neither the reporting deadlines nor the management body duties, and its evidential value reaches only the scope of the certificate. The third is skipping the supply chain. The fourth is treating procedures as documents rather than actions: an incident reporting procedure nobody has rehearsed does not work in practice, and with a 24-hour deadline there is no time to learn it on the day. The fifth is the absence of real engagement from the management body, which no quality of technical implementation replaces.

Costs depend on the starting point and the scale of the organisation strongly enough that quoting ranges without knowing the actual state would be false precision. The largest items are usually monitoring and response capability - built in house or bought as a service - and putting supplier relationships in order. Both are worth deciding early, because both have the longest lead time.