NIS2 for EU organisations and their software suppliers in India

01NIS2 at the end of 2026

Directive (EU) 2022/2555, the NIS2 Directive (opens external site), was published on 27 December 2022 and took effect on 16 January 2023. Transposition had to be finished by 17 October 2024, with the national rules applying from 18 October 2024; on that date the original NIS Directive ceased to apply.

A directive binds organisations only once national law has transposed it, and that happened at different speeds. Some Member States were on time; others adopted their law in 2025 or 2026, and the Commission opened infringement procedures against those that were late. Registration, reporting portals and supervisors therefore vary by country, which an Indian supplier with customers in several Member States will see in every contract.

02Essential and important entities

The directive reaches public and private entities in two annexes. Annex I lists sectors of high criticality, among them energy, banking, health, transport, digital infrastructure, ICT service management, drinking and waste water, financial market infrastructures, public administration and space. Annex II lists other critical sectors, among them manufacturing, food, chemicals, digital providers, research, waste management, and postal and courier services. Medium-sized and larger organisations are the usual target, but certain entities are covered whatever their headcount: central government entities, DNS service providers and providers of trust services, for example.

Article 3 divides them into two groups:

• Essential entities: for the most part large organisations in Annex I sectors, together with those that count as essential at any size, for instance central government entities, DNS service providers, TLD name registries and qualified trust service providers. Supervisors act proactively and may audit or inspect on site.
• Important entities: everyone else in scope under Annex I or II. Supervision is reactive: the authority steps in once there are signs of non-compliance.

Both groups carry the same three core duties: the Article 21 measures, Article 23 reporting and the Article 20 accountability of management. Supervision and fines are where they part. When Article 21 or 23 is breached, national law must let the authority fine an essential entity up to EUR 10 million or 2% of global annual turnover at least, and an important entity up to EUR 7 million or 1.4% at least, taking the higher figure in each case. Member States decide for themselves whether, and how far, public administration entities can be fined.

When an Indian supplier is in scope itself

Software development is not, by itself, a NIS2 sector. A supplier may still be covered directly, because Annex I includes managed service providers and NIS2 draws that category widely: any entity that installs, manages, operates or maintains a customer’s ICT products, networks, infrastructure or applications, on site or from a distance. An Indian supplier of medium size or above that runs or maintains applications for EU customers may therefore be covered on its own account, and so may providers of cloud and data centre services. Their technical requirements are spelled out in Implementing Regulation (EU) 2024/2690 (opens external site).

Providers established outside the Union face one further rule. DNS service providers, TLD name registries, domain name registration services, cloud computing, data centre and content delivery network providers, managed service and managed security service providers, online marketplaces, online search engines and social networking platforms that offer services in the EU without being established there must designate a representative in one of the Member States where they offer those services (Article 26(1)(b) and (3)). An Indian managed service provider with EU customers and no EU establishment should check this point first.

Most Indian software suppliers, though, feel NIS2 through their EU customers, who translate their supply-chain duty into contract clauses, security questionnaires and audits. Software products also fall under Regulation (EU) 2024/2847, the Cyber Resilience Act (opens external site). Its duty to report actively exploited vulnerabilities and severe incidents starts on 11 September 2026; the rest of the regulation follows on 11 December 2027.

03The ten minimum measures in Article 21

Article 21 asks for technical, operational and organisational measures that are appropriate and proportionate, take an all-hazards approach, follow current good practice and relevant standards, and match the entity’s risk exposure, its size and the probable severity of incidents. The minimum set is:

1. 01policies for risk analysis and for the security of information systems;
2. 02handling of incidents;
3. 03business continuity, covering backups, disaster recovery and crisis management;
4. 04security of the supply chain, including security in each relationship with a direct supplier or service provider;
5. 05security when systems are acquired, developed and maintained, including how vulnerabilities are handled and disclosed;
6. 06policies and procedures for checking whether the measures actually work;
7. 07basic cyber hygiene, and training in cybersecurity;
8. 08policies and procedures for cryptography and, where it fits, encryption;
9. 09security of personnel, access control and the management of assets;
10. 10multi-factor or continuous authentication, plus secure voice, video, text and emergency communication channels where appropriate.

Items 4 and 5 bring suppliers into the picture. Article 21(3) asks the entity to take account of each direct supplier’s particular vulnerabilities, the overall quality of its products and security practice, and the way it develops software securely. An EU customer is therefore expected to look at how an Indian supplier builds software, not only at what it delivers.

04Management signs off and is liable

Under Article 20, the management bodies of essential and important entities approve the cybersecurity risk-management measures, oversee their implementation and can be held liable for infringements. Board members are required to take training, and the directive encourages entities to offer regular training to staff too. For public bodies, national rules on how public institutions and officials are held liable still apply.

That changes how a customer talks to its suppliers. A board that must sign off the measures wants a trail it can follow: which supplier supports which service, what residual risk remains, and which controls were actually tested. An Indian supplier that can answer in the customer’s format, without launching a separate project, becomes the easier one to keep.

05Reporting: 24 hours in the EU, six hours in India

Article 23 obliges entities to report significant incidents to their CSIRT or competent authority. An incident counts as significant when it has caused, or could cause, serious disruption or financial loss for the entity, or considerable damage, material or otherwise, to other people or organisations. Reports come in stages:

Where appropriate, entities must also warn the users of their services promptly about significant incidents likely to affect them. Each national law adds its own forms and portals.

India runs a faster clock for its own reporting. The CERT-In Directions of 28 April 2022, issued under section 70B(6) of the Information Technology Act, 2000, require listed cyber incidents to be reported to the Indian Computer Emergency Response Team (CERT-In) within six hours of noticing them, and require ICT logs to be retained and system clocks synchronised. Where both regimes apply, they run in parallel: a report to CERT-In does not inform the EU customer, and the customer’s early warning depends on how fast the supplier tells it.

The customer’s 24 hours start when it becomes aware. If the incident begins inside a supplier’s systems, the deadline is achievable only if the supplier spots it, recognises what it is and passes it on within hours. That is why detection, logging and the notification route belong in the contract and not only in the runbook.

06What an EU customer will ask of a software supplier in India

In practice Article 21 becomes a set of technical controls, and proof of them, that a supplier should be able to show on request rather than through a new project. The requests that come up most:

• Secure development. Threat models for significant changes, code review by a second engineer, automated security and dependency checks in CI, signed builds, and an SBOM (software bill of materials) shipped with every release.
• Vulnerability handling and disclosure. A public route for reporting vulnerabilities, response times by severity, and a prompt warning to the customer when a vulnerability touches its environment.
• Controlled access for supplier staff. Personal accounts, MFA, least privilege, elevated rights that expire, and a trail of every admin action taken in the customer’s systems, whether the engineer works from Europe or from India.
• Logs and incident evidence. Security events captured with trustworthy timestamps, kept as long as agreed and exportable, so the customer can fill in the early warning and the final report; the clock synchronisation the CERT-In Directions require already helps here.
• Incident cooperation. One named contact, one agreed channel, a notification time comfortably inside the customer’s 24 hours, and help with root-cause analysis.
• Continuity and recovery. Backups proven by restore tests, recovery targets that match the customer’s, and a procedure that has been rehearsed.
• Supply-chain records. A current register of subcontractors, hosting sites and the key third-party components and services the solution relies on.
• An exit plan. Exports in formats the customer can reuse, documentation and handover help, so that switching supplier never means losing control of the service.

Mature engineering teams already do most of this. NIS2’s contribution is that the customer must now be able to demonstrate it. Our trust and compliance page sets out how FromNine works as a supplier, including our ISO/IEC 27001 certified information security management system.

07Checklist for contracts and procurement

1. 01Link suppliers to services. Note which suppliers support which in-scope services, and which can reach your systems or data.
2. 02Rank by criticality. The strictest requirements go to suppliers that run critical systems or can change them.
3. 03Write the controls into the contract. Security requirements, how fast and through which channel incidents are notified, vulnerability handling, log retention, rights to audit or to evidence, rules on subcontracting, and delivery locations, India included where relevant.
4. 04Ask for proof, not promises. Certificates and their scope, test results, an SBOM, the date the last restore was tested.
5. 05Settle the exit at the start. How data comes back, what transition help is given and for how long the supplier keeps the service running.
6. 06Rehearse together. Hold an incident drill with critical suppliers that includes the 24-hour early warning.
7. 07Review on a cycle. Suppliers, services and threats keep changing; a register refreshed once a year is stale for most of that year.

08National law settles the details

Registration, portals, forms, the competent authority and any extra requirements come from national law, and some Member States link the Article 21 measures to a national framework or certification scheme. The default rule is that an entity answers to the Member State in which it is established. Article 26 makes exceptions: public electronic communications providers answer to every country they serve; cloud, data centre and managed service providers and certain other digital providers answer to the country where their main establishment is; and public administration entities answer to the state that created them.

09Developments to follow

• The transposition in each country where your customers operate: registration deadlines, implementing decrees and the authority’s guidance.
• The Commission’s Digital Omnibus proposal (opens external site), COM(2025) 837 of 19 November 2025, under which incident reports required by NIS2, the GDPR, DORA and other acts would go to a single ENISA entry point. In October 2026 it was still with the European Parliament (opens external site)); until it is adopted and applies, today’s channels and deadlines stand.
• EU-level coordinated risk assessments of critical ICT supply chains (Article 22), which entities must factor in when they select measures for suppliers.
• The Cyber Resilience Act timetable for software products, fully applicable on 11 December 2027.

For EU financial entities, the Digital Operational Resilience Act replaces these NIS2 provisions on ICT risk, incident reporting and supervision; our article on DORA and ICT third-party providers explains it. The Commission’s NIS2 policy page (opens external site) summarises the directive and its implementing acts.