NIS2 in 2026: 18 sectors, essential and important entities, fines up to EUR 10 million

Origins - from NIS to NIS2

The predecessor of NIS2, Directive 2016/1148, was the first horizontal EU cybersecurity directive. Before it, cybersecurity regulation was mainly sector-specific, particularly in finance and telecommunications. After several years of implementation, the European Commission identified four weaknesses, each of which is addressed by NIS2.

The first was inconsistent transposition: Member States interpreted core concepts differently, including the notion of an operator of essential services and incident-significance thresholds. The same kind of organisation could therefore be regulated in one Member State but not in another. The second problem was the limited sectoral scope, which left out areas such as waste management, food production and postal services. The third was weak enforcement in some jurisdictions. The fourth was governance: cybersecurity often remained an operational IT matter instead of being supervised by senior management.

NIS2 does not operate in isolation. Commission Implementing Regulation (EU) 2024/2690^[2] of 17 October 2024 specifies technical and methodological requirements for the measures in Article 21(2) and thresholds for significant incidents, but only for the categories of digital and trust-service providers covered by that regulation - not for every NIS2 entity. The CER Directive (EU) 2022/2557^[3] addresses the physical resilience of critical entities and complements rather than replaces NIS2. ENISA publishes implementation material that can be used when translating legal requirements into technical controls.^[9]

Scope - eighteen sectors

NIS2 divides the covered activities between two annexes. This is the first of the two main elements used to determine whether an organisation falls within scope. Annex I contains sectors of high criticality; Annex II contains other critical sectors.

Annex I - sectors of high criticality

• Energy - electricity, district heating and cooling, oil, gas and hydrogen, including system operators, storage and distribution.
• Transport - air, rail, water and road transport, including infrastructure managers and traffic-management operators.
• Banking - credit institutions.
• Financial market infrastructures - operators of trading venues and central counterparties.
• Health - healthcare providers, EU reference laboratories, entities carrying out research and development of medicinal products and manufacturers of critical medical devices during a public-health emergency.
• Drinking water - suppliers and distributors of water intended for human consumption.
• Waste water - collection, disposal and treatment of urban, domestic and industrial waste water.
• Digital infrastructure - internet exchange points, DNS service providers, TLD name registries, cloud-computing and data-centre service providers, content-delivery networks, trust-service providers and providers of public electronic communications networks or publicly available electronic communications services.
• ICT service management - managed service providers and managed security service providers.
• Public administration - central-government entities are covered under the directive; treatment of regional administration is left to Member States within the framework of the directive.
• Space - operators of ground-based infrastructure supporting space-based services.

Annex II - other critical sectors

• Postal and courier services.
• Waste management.
• Manufacture, production and distribution of chemicals.
• Food production, processing and distribution.
• Manufacturing - medical devices and in vitro diagnostic medical devices, computers and electronics, electrical equipment, machinery, motor vehicles and other transport equipment.
• Digital providers - online marketplaces, online search engines and social-networking services platforms.
• Research - research organisations.

The eighteen sectors represent a major expansion compared with the seven sectors covered by the first NIS Directive. Sectoral classification alone, however, does not settle the question. In most cases it must be combined with the size-cap rule and the exceptions in Articles 2 and 3.

Essential and important entities

The second main element is enterprise size. The SME rules require more than counting employees. A medium-sized enterprise is an enterprise with fewer than 250 employees and either annual turnover not exceeding EUR 50 million or an annual balance-sheet total not exceeding EUR 43 million. Small enterprises have fewer than 50 employees and do not exceed the applicable EUR 10 million thresholds; microenterprises have fewer than 10 employees and do not exceed EUR 2 million. Partner and linked enterprises must also be taken into account.

The logical structure of these thresholds matters. An enterprise with 120 employees and turnover of EUR 80 million may still fall within the medium-sized category if its balance-sheet total does not exceed EUR 43 million. That is why the simplified slogan "50 employees or EUR 10 million" is not sufficient for a legal classification.

Article 2(2) and Article 3 identify categories that can be covered regardless of size or under special criteria. These include, depending on the exact provision, certain providers of public electronic communications, trust services, DNS services and TLD registries, public-administration bodies and entities whose services are critical for public safety, security or health. A small organisation can therefore fall within NIS2 if it provides a service that the directive deliberately treats as critical irrespective of normal SME thresholds.

Essential and important entities are subject to the same core risk-management and incident-notification requirements. The principal difference is supervision and enforcement. Essential entities may be subject to ex ante supervisory measures, including inspections and audits without a prior indication of non-compliance. Supervision of important entities is primarily ex post and is triggered when there is evidence, indication or information suggesting non-compliance. The maximum administrative-fine thresholds also differ.

Ten cybersecurity 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 into account the state of the art, relevant standards, implementation costs and the risks faced by the entity. Article 21(2) develops this into ten minimum categories. The directive deliberately does not prescribe a product list or universal implementation frequency.

The first four categories form the management backbone. Point (a) requires policies on risk analysis and information-system security. Point (b) covers incident handling: detection, analysis, containment, eradication, recovery and lessons learned. NIST SP 800-61 Rev. 3^[12] provides a useful methodological view by treating incident response as part of cybersecurity risk management rather than a separate activity started only after an alert. Point (c) concerns business continuity, including backup management, disaster recovery and crisis management. Point (d) introduces supply-chain security, including security aspects of relationships between an entity and its direct suppliers or service providers.

The next three categories concern system life cycle and assurance. Point (e) covers security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure. Point (f) requires policies and procedures to assess the effectiveness of cybersecurity risk-management measures. Audits, penetration tests and vulnerability assessments can support this obligation, but the directive does not impose one universal testing frequency. Point (g) covers basic cyber hygiene and cybersecurity training, including organisational practices that reduce the likelihood that routine mistakes become incidents.

The final three categories concern cryptography, identity and communication. Point (h) requires policies and procedures regarding cryptography and, where appropriate, encryption. Point (i) concerns human-resources security, access-control policies and asset management. Point (j) covers, where appropriate, multi-factor or continuous authentication, secured voice, video and text communications and secured emergency communications systems.

A common error is to describe management training as an "eleventh measure" under Article 21. It is not. The regular training obligation for members of management bodies comes from Article 20(2) and is structurally separate. Article 21(4) additionally requires entities that find that they do not comply with the required measures to take all necessary, appropriate and proportionate corrective measures without undue delay.

Supply-chain security

Supply-chain security is one of the most consequential changes in NIS2 because it moves cybersecurity requirements beyond the perimeter of the regulated organisation. Article 21(2)(d) requires entities to address the security-related aspects of relationships with direct suppliers and service providers. Article 22 allows the Cooperation Group, the Commission and ENISA to carry out coordinated security-risk assessments of critical supply chains at Union level.

In practice, supply-chain governance has four layers. First, identify critical suppliers whose failure or compromise would materially affect the ability to deliver the regulated service. Second, assess the associated risk, including concentration risk and dependencies that are difficult to replace. Third, translate appropriate controls into contracts - for example incident-notification duties, minimum security requirements, evidence obligations and audit or assurance rights where justified. Fourth, perform ongoing oversight using evidence such as certificates, assurance reports, testing results and incident history.

NIS2 does not require every supplier to hold ISO/IEC 27001^[7] or SOC 2 certification and does not prescribe one universal contractual clause. Certification can be useful evidence, but it does not replace the assessment by the entity of whether the supplier, service and dependency are acceptable.

For the Polish IT market the indirect consequence matters most. Cloud, data-centre, content-delivery and managed-service providers - including managed security services - are listed in Annex I, and trust-service providers are covered regardless of size. A hosting company or integrator that previously had no duties may now be an essential or important entity in its own right, and independently of that it faces pressure from customers who must demonstrate oversight of their own supply chain. This is one of the strongest mechanisms in the whole directive, because it works without any action by a supervisory authority.

Incident notification - 24 hours, 72 hours, one month

Article 23 establishes a staged process for significant incidents. Article 23(3) defines a significant incident through two criteria: it has caused or is capable of causing severe operational disruption of 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 one of them is enough.

The clock runs from becoming aware of the significant incident, not from the technical start of the attack. The CSIRT or competent authority may also request an intermediate report at any time.

The duty is not limited to regulators. Where appropriate, Article 23 also requires entities to inform recipients of their services about significant incidents likely to adversely affect service provision and, in certain circumstances, about significant cyber threats and measures those recipients can take. The CSIRT or competent authority should, where possible, respond to the early warning within 24 hours and may provide technical support.

Numerical thresholds exist but have limited reach. Regulation 2024/2690^[2] defines them only for the digital and trust-service providers within its scope. For a cloud-computing provider an incident is significant, among other cases, where the service is completely unavailable for more than 30 minutes or its availability is reduced for more than one hour for more than 5 percent of users in the Union or more than one million users, whichever number is lower. These are two separate criteria, not one compound test. Other sectors have no numerical thresholds and must assess severity themselves.

The hardest operational question is when 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). A survey of security operations centres describes the functions of such a team and the recurring difficulties of running one^[13] - see the article on SOC 24/7. A notification process therefore has to exist before the incident: classification criteria, an on-call decision path, a way to collect minimum facts quickly and tested channels for communicating with the relevant authority.

Management responsibility (Article 20)

Article 20 requires management bodies of essential and important entities to approve cybersecurity risk-management measures, oversee their implementation and be accountable for infringements by the entities in accordance with national law. Members of management bodies must also follow training regularly, and Member States are to encourage equivalent training for employees where appropriate.

The directive does not specify a universal number of training hours or a mandatory annual syllabus. The training should be sufficient to enable management to identify risks, assess cybersecurity risk-management practices and understand their impact on the services delivered by the entity.

This changes the governance model, because it shifts the burden of evidence. A CISO can design controls and an MSSP can operate monitoring, but the legal responsibility to approve, supervise and resource the risk-management system cannot simply be outsourced. Evidence should therefore include management decisions, risk-acceptance decisions, reporting cycles and training records rather than only technical configuration. The absence of such evidence is an infringement regardless of how well the technical safeguards work.

Personal liability does not follow directly from the directive. Article 32(5) leaves its shape to Member States, indicating two possible measures: a temporary prohibition on exercising managerial functions in respect of a natural person acting as chief executive officer or legal representative and, for essential entities, temporary suspension of an authorisation. For public-administration bodies the provision is without prejudice to national rules on the liability of officials.

Supervision and administrative fines

NIS2 creates different supervisory models for essential and important entities. For essential entities, competent authorities may use ex ante and ex post supervision, including on-site inspections, off-site supervision, regular and targeted security audits, ad hoc audits, security scans based on objective and fair criteria and requests for information or evidence. Important entities are generally supervised ex post where evidence, an indication or information suggests that the entity is not complying.

The directive sets minimum maximum fine levels. For essential entities, Article 34 requires Member States to ensure that administrative fines for infringements of Article 21 or 23 can reach at least EUR 10 million or 2% of total worldwide annual turnover of the undertaking to which the entity belongs, whichever is higher. For important entities, the corresponding level is at least EUR 7 million or 1.4% of worldwide annual turnover, whichever is higher. For large groups, the percentage threshold is usually the binding one.

The amount of an individual fine is not automatic. Authorities must consider factors such as the nature, gravity and duration of the infringement, previous relevant infringements, damage caused, intentional or negligent character, mitigating actions, applicable codes or certification mechanisms and the level of cooperation. NIS2 also identifies conduct that can justify particularly serious supervisory treatment, including repeated infringements, failure to notify or remedy significant incidents, failure to comply with binding orders, obstruction of audits and provision of false or grossly inaccurate information.

Supervisory measures can be more disruptive than a fine. Authorities can order an entity to cease conduct, implement audit recommendations, make aspects of an infringement public and, for essential entities in particularly serious cases, pursue temporary suspension of certification or authorisation and temporary prohibition of management functions where national implementation allows the measure.

The change of scale is easiest to see in comparison. The Polish Act on the National Cybersecurity System in its 2018 wording^[5] provided for penalties two orders of magnitude lower. After transposition, cybersecurity non-compliance becomes a regulatory risk comparable with data-protection compliance - with the difference that some sanctions can be addressed to a person rather than only to the organisation.

European cooperation

NIS2 strengthens the EU cooperation architecture. The Cooperation Group operates at strategic level, bringing together Member States, the Commission and ENISA to exchange good practices, develop guidance and support coordinated supply-chain risk assessments.

The CSIRTs Network connects the CSIRTs designated by Member States for operational cooperation, cross-border incident information exchange, mutual assistance and exercises. ENISA provides the secretariat and supports the work of the network.

Article 16 establishes EU-CyCLONe, the European cyber crisis liaison organisation network. It operates at political-strategic level alongside the operational CSIRTs Network and supports coordinated management of large-scale cybersecurity incidents and crises, including development of a shared situational picture for political decision-making. Separating the two levels is deliberate: in a serious cross-border incident the bottleneck is often not technical analysis but agreement between states.

The role of ENISA is broader than incident coordination. The agency supports Member States with implementation guidance^[9], exercises and cybersecurity expertise, and publishes threat-landscape assessments^[6] and foresight work^[10] useful for risk planning.

Relationship with DORA, CER, the GDPR, KSC and the AI Act

NIS2 is not the only regime that can apply to a regulated organisation. The most important overlap is the financial sector. DORA^[8], applicable since 17 January 2025, is treated as a sector-specific Union legal act for the purposes of Article 4 NIS2. Where its ICT risk-management, major ICT-related incident reporting, digital operational resilience testing and ICT third-party risk requirements are at least equivalent, those DORA rules apply instead of the corresponding NIS2 requirements. Financial entities should therefore not automatically duplicate the same incident notification under both regimes.

CER^[3] has a different function. NIS2 deals with cybersecurity and network-and-information-system resilience; CER addresses all-hazards resilience of critical entities, with strong emphasis on physical and organisational continuity. The frameworks are complementary and require cooperation between competent authorities.

The GDPR is also complementary but protects a different interest. An incident can qualify both as a significant NIS2/KSC incident and as a personal-data breach, but neither classification follows automatically from the other. If both thresholds are met, the organisation may have two independent notification workflows with different recipients and legal tests.

In Poland, the key operational relationship is with the Act on the National Cybersecurity System. Since 3 April 2026, Polish entities determine their duties under the amended KSC rather than relying on the directive as if it were a stand-alone domestic rule. The AI Act can add further requirements where an organisation uses or supplies regulated AI systems, but it does not replace NIS2/KSC cybersecurity duties.

Transposition in Poland

Poland transposed NIS2 through the Act of 23 January 2026 amending the Act on the National Cybersecurity System and certain other acts, published as Journal of Laws 2026 item 252^[4]. The amendment replaced the old operator-of-essential-services model with essential and important entities, expanded the sectoral scope and introduced a new register and registration model.

The Polish public-sector rules include specific categories and thresholds that do not follow directly from the generic NIS2 SME model. For example, 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, under Annex 1 to the Act in the "Public entities" sector. That is a qualification threshold, not an exemption: a smaller office is simply not an essential entity on that basis, but it may still be covered as an important entity or through its organisational units. Classification therefore has to be made under the exact national annex and cannot be inferred from the private-sector size rules of the directive alone.

The transition is staged. The amendment entered into force on 3 April 2026. Entities that already met the relevant criteria on that date generally have 12 months to implement the Chapter 3 duties, taking the main deadline to 3 April 2027. An essential entity generally has 24 months for its first statutory audit, which for that initial cohort points to 3 April 2028, subject to transitional rules for former operators of essential services. Later entrants calculate their deadlines from their own date of becoming subject to the Act. The periodic audit duty applies only to essential entities; an annual review of the information security management system is required of an important entity that is a public entity.

The new Polish penalty regime is also subject to a transition. The provisions identified in Article 35 of the amending Act, covering the principal new KSC administrative-fine provisions, apply after two years from the entry into force of the amendment - that is, from 3 April 2028^[4]. This is separate from the earlier deadlines for implementing operational duties: an organisation should not treat the penalty transition as permission to postpone measures that become legally required earlier.

The delay in transposition had consequences. The European Commission opened infringement proceedings against Member States that had not notified full transposition on time, Poland among them, and the entry into force of the amendment was the response to that situation.

What to prepare now

The starting point is legal classification. The organisation should document the relevant sector and entity type, calculate size using the applicable aggregation rules, identify exceptions and record the date from which it meets the criteria. A short classification memorandum is more useful than an unsupported statement that "we are" or "we are not" subject to NIS2 - and a negative result also needs to be documented, because the absence of the analysis is itself a common audit finding.

The next step is a gap analysis mapping existing governance, processes and technical measures to the ten categories in Article 21(2), while also applying the exact requirements of the Polish KSC - see the article on the KSC and NIS2 audit. Where Implementing Regulation 2024/2690 applies to the specific type of digital or trust-service provider, its detailed technical and methodological requirements should be added to the audit criteria.^[2]

Implementation should prioritise capabilities with long lead times: incident monitoring and response, a tested reporting path, identity and privileged-access security, cryptographic governance, business continuity and recoverability, vulnerability management and supply-chain governance. The last of these often takes longest because material contract changes require cooperation from suppliers rather than a unilateral configuration change.

The organisational layer should progress in parallel: ownership of cybersecurity, reporting to the management body, management decisions on risk and resources, and documented management training. The aim is not to create a document set for inspection, but to ensure that people can execute the process when a real incident, supplier failure or security weakness occurs.

Common mistakes are predictable. The first is waiting until the end of the transition period before starting work. The second is assuming that an ISO/IEC 27001 certificate^[7] equals NIS2 compliance. The third is ignoring the supply chain. The fourth is treating procedures as documents instead of tested operational capabilities: a notification procedure nobody has rehearsed does not work, and a 24-hour deadline leaves no time to learn it. The fifth is failing to involve the management body in actual risk decisions.

Costs vary too strongly by organisation size, architecture and starting point for universal figures to be meaningful. The most expensive areas are often monitoring and response capability - whether built internally or purchased as a service - and supplier-risk remediation. Both should be decided early because they have long implementation cycles.