NIS2 and your software suppliers: what both sides have to do

01Where NIS2 stands in autumn 2026

The NIS2 Directive (opens external site), Directive (EU) 2022/2555, was published in the Official Journal on 27 December 2022 and entered into force on 16 January 2023. Member States had to adopt and publish their national measures by 17 October 2024 and apply them from 18 October 2024, the day the first NIS Directive was repealed.

Because NIS2 is a directive, what binds an organisation is the national law that transposes it. Transposition has been uneven: some Member States applied their law on time, others only in 2025 or 2026, and the European Commission has started infringement procedures against Member States that missed the deadline. Registration duties, reporting portals and supervisors therefore differ per country.

02Essential and important entities

NIS2 applies to public and private entities in the sectors of Annex I (high criticality: energy, transport, banking, financial market infrastructures, health, drinking water, waste water, digital infrastructure, ICT service management, public administration and space) and Annex II (other critical sectors: postal and courier services, waste management, chemicals, food, manufacturing, digital providers and research). As a rule it covers medium-sized and large organisations. Some are in scope regardless of size, such as trust service providers, DNS service providers and central government entities.

Article 3 then sorts these organisations into two categories:

• Essential entities: mainly large organisations in Annex I sectors, plus entities that are essential regardless of size, such as qualified trust service providers, top-level domain registries, DNS service providers and central government entities. They are supervised proactively, which can include audits and on-site inspections.
• Important entities: the other organisations in scope of Annex I and II. Supervision is ex post: the authority acts when there are indications that the entity does not comply.

Both categories have the same core duties: risk-management measures (Article 21), incident reporting (Article 23) and management accountability (Article 20). The difference lies in supervision and in the fines. For infringements of Articles 21 or 23, national law must allow maximum fines of at least EUR 10 million or 2% of worldwide annual turnover for essential entities, and at least EUR 7 million or 1.4% for important entities, whichever is higher. Member States decide whether, and how far, fines apply to public administration entities.

Is your software supplier in scope itself?

Writing software is not, as such, a NIS2 sector. A supplier can still be in scope directly. Annex I covers managed service providers, and NIS2 defines them broadly: entities that install, manage, operate or maintain ICT products, networks, infrastructure or applications for customers, on site or remotely. A medium-sized or larger supplier that runs or maintains applications for its customers may therefore fall under NIS2 in its own right, as may cloud computing and data centre service providers. For these providers, Implementing Regulation (EU) 2024/2690 (opens external site) spells out the technical requirements in detail.

Most software suppliers, though, meet NIS2 through their customers, who turn their own supply-chain duty into contract clauses, questionnaires and audits. Software products are also covered by the Cyber Resilience Act (opens external site), Regulation (EU) 2024/2847: its reporting obligations for actively exploited vulnerabilities and severe incidents apply from 11 September 2026, and its other obligations from 11 December 2027.

03The ten minimum measures of Article 21

Article 21 requires appropriate and proportionate technical, operational and organisational measures, based on an all-hazards approach. They have to reflect the state of the art and relevant European and international standards, and be proportionate to the entity’s exposure to risk, its size and the likely severity of incidents. At a minimum they cover:

1. 01policies on risk analysis and information system security;
2. 02incident handling;
3. 03business continuity, such as backup management and disaster recovery, and crisis management;
4. 04supply chain security, including the security aspects of the relationships with direct suppliers and service providers;
5. 05security in the acquisition, development and maintenance of network and information systems, including vulnerability handling and disclosure;
6. 06policies and procedures to assess whether these measures are effective;
7. 07basic cyber hygiene practices and cybersecurity training;
8. 08policies and procedures on cryptography and, where appropriate, encryption;
9. 09human resources security, access control policies and asset management;
10. 10multi-factor or continuous authentication, and secured voice, video, text and emergency communications, where appropriate.

Points 4 and 5 are where suppliers come in. Article 21(3) asks entities to take into account the vulnerabilities specific to each direct supplier, the overall quality of its products and cybersecurity practices, and its secure development procedures. Your customers are expected to look at how you build software, not only at what you deliver.

04Management approves, oversees and answers for it

Under Article 20, the management bodies of essential and important entities must approve the cybersecurity risk-management measures, oversee their implementation and can be held liable for infringements. Their members must follow training, and entities are encouraged to train their employees regularly as well. For public bodies, national rules on the liability of public institutions and officials continue to apply.

This changes the conversation with suppliers. A board that has to approve the measures wants evidence it can follow: which suppliers support which services, which risks remain, and what has actually been tested.

05Incident reporting: 24 hours, 72 hours, one month

Article 23 requires entities to report significant incidents to their CSIRT or competent authority. An incident is significant if it has caused, or can cause, severe operational disruption or financial loss for the entity, or considerable material or non-material damage to others. Reporting runs in stages:

Where appropriate, entities must also inform the recipients of their services without undue delay about significant incidents that are likely to affect those services. National laws add their own forms and portals.

The clock starts when the entity becomes aware of the incident. If the incident begins in a supplier’s system, the customer can only meet the 24-hour deadline when the supplier detects it, recognises it and passes it on within hours. Detection, logging and an agreed notification channel are therefore contract terms, not just engineering details.

06What a NIS2 customer will ask of its software supplier

In practice, Article 21 turns into technical measures and evidence that a supplier should be able to show without starting a project. The ones we see most often:

• A secure development lifecycle. Threat modelling for significant changes, peer review, automated security tests and dependency scanning in the pipeline, signed builds and a software bill of materials (SBOM) for each release.
• Vulnerability handling and disclosure. A published way to report vulnerabilities, response times agreed by severity, and a notice to the customer when a vulnerability affects their environment.
• Access control for supplier staff. Named accounts, multi-factor authentication, least privilege, time-limited elevated access and a log of every administrative action in the customer’s environment.
• Logging and incident evidence. Security-relevant events logged with reliable timestamps, kept for an agreed period and exportable, so the customer can answer the questions of the early warning and the final report.
• Incident cooperation. A named contact and channel, a notification time well inside the customer’s 24 hours, and support with root-cause analysis.
• Continuity and recovery. Backups proven by restoring them, recovery objectives aligned with the customer’s, and a rehearsed procedure.
• Supply-chain documentation. A current list of subcontractors and hosting locations, and of the main third-party components and services the solution depends on.
• An exit plan. Data export in usable formats, documentation and handover support, so the customer can change supplier without losing control of the service.

None of this is new to mature engineering teams. What NIS2 changes is that the customer must be able to demonstrate it. Our page on trust and compliance describes how we work as a supplier, including our information security management system certified to ISO/IEC 27001.

07A checklist for contracts and procurement

1. 01Map suppliers to services. Record which suppliers support which services in scope, and which have access to your systems or data.
2. 02Classify by criticality. Apply the heaviest requirements to suppliers that run or can change critical systems.
3. 03Write the measures into the contract. Security requirements, incident notification time and channel, vulnerability handling, logging and retention, audit or evidence rights, subcontracting rules and locations.
4. 04Ask for evidence, not declarations. Certificates with their scope, test results, an SBOM, the date of the last restore test.
5. 05Agree the exit up front. Data return, transition support and the period during which the supplier keeps the service running.
6. 06Rehearse together. Run an incident exercise with your critical suppliers, including the 24-hour early warning.
7. 07Review regularly. Suppliers, services and threats change; a supplier register updated once a year is out of date for most of the year.

08National law decides the details

Registration, reporting portals, forms, the competent authority and any additional requirements all come from national law. Some Member States link the Article 21 measures to a national framework or certification. As a rule, an entity falls under the Member State where it is established. Article 26 makes exceptions: public electronic communications providers fall under each country where they provide services, cloud, data centre and managed service providers and several other digital providers under the country of their main establishment, and public administration entities under the state that established them.

09What to watch in the coming months

• Your national transposition: registration deadlines, implementing decrees and the guidance of your authority.
• The Commission’s Digital Omnibus proposal (opens external site) of 19 November 2025, COM(2025) 837, which would route incident reports under NIS2, the GDPR, DORA and other laws through a single entry point run by ENISA. In October 2026 it was still before the European Parliament (opens external site)); until it is adopted and applies, current channels and deadlines remain.
• Coordinated EU risk assessments of critical ICT supply chains under Article 22, which entities must take into account when choosing supplier measures.
• The Cyber Resilience Act timeline for software products, with full application from 11 December 2027.

For financial entities, the Digital Operational Resilience Act replaces the NIS2 rules on ICT risk management, incident reporting and supervision; see our article on DORA and ICT third-party providers. The Commission keeps an overview of NIS2 and its implementing acts on its NIS2 policy page (opens external site).