NIS2 and your development team: what changes in practice

NIS2 is the EU directive that sets cybersecurity duties for organisations in sectors such as energy, healthcare, transport, government and digital infrastructure. Each member state writes it into its own law, and by now Belgium, Germany and the Netherlands all have one in force. If your organisation is in scope, or you build software for one that is, your development team gets requirements on secure development, vulnerability handling, access, logging and incident reporting. A good team already does most of this, but now you also have to be able to prove it.

Whether your organisation is in scope is a legal question. Have someone who knows the law in your country check it.

What NIS2 asks

NIS2 is Directive (EU) 2022/2555, which member states had to transpose by 17 October 2024. It applies to medium-sized and large organisations in the sectors it lists, and that includes providers of managed services and managed security services.

Three articles carry the most weight. Under Article 20, the management body approves the security measures, oversees how they are carried out and has to follow training. It can also be held liable. Article 21 requires appropriate measures against risk and lists the topics they must cover at a minimum. Article 23 sets out how to report significant incidents.

The fines are substantial. For essential entities, the maximum is at least 10 million euros or 2 percent of worldwide annual turnover, whichever is higher. For important entities, it is 7 million euros or 1.4 percent.

Each country has its own law

Because NIS2 is a directive, the rules that bind you are national. Three examples:

The Netherlands was late with its transposition. On 8 July 2026 the European Commission announced it was referring the country to the Court of Justice for not notifying its transposition, one day after the Dutch Senate passed the law. The BSI expects around 29,500 organisations in Germany to fall under the new rules, and the Dutch government counts more than 8,000. Details such as registration deadlines differ, so check the rules in every country where you operate.

Even if you are not in scope yourself

Your company may be out of scope while one of your clients is in scope. Article 21 requires that client to weigh the security of its supply chain, including how its suppliers handle secure development. So expect questionnaires, contract clauses and sometimes an audit.

Your client wants to know how you handle vulnerabilities and how fast you pass on an incident. They have only 24 hours for an early warning, so "we will let you know within a week" is not an answer that helps them. Agree on a deadline in hours.

What changes for your development team

Article 21 lists ten topics, seven of which affect your development team directly.

Write down what you do, who does it and how often. Keep the evidence too: the review in the pull request, the restore test report and the overview of who has access to what. Aleksa covers restores in backups and disaster recovery, and the supply chain of your code is the subject of supply chain attacks on npm and PyPI.

Reporting within 24 hours takes preparation

The 24 hours start when you become aware of the incident. Within that window, someone has to say whether it looks malicious and whether it may have cross-border impact. That only works if logs are stored centrally and kept long enough, and if someone knows how to search them.

Decide in advance who does the first analysis, who informs the management body and who files the report. Rehearse it once with a made-up scenario. If you work with an external or remote team, include those people in the plan, with names and phone numbers.

Our developers work from Serbia, in the same time zone as the Netherlands and Germany, on managed laptops with SSO and two-factor authentication. Our way of working is aligned with the GDPR and NIS2 (see how we work), and that helps with your client's questionnaire. The report itself stays the responsibility of the organisation that is in scope.

Not the same as the Cyber Resilience Act

If you build a product with software that is sold in the EU, the Cyber Resilience Act (CRA) applies as well. Since 11 September 2026, manufacturers have to report actively exploited vulnerabilities in their products. The main obligations, such as the product requirements, apply from 11 December 2027.

NIS2 is about your organisation, the CRA about your product. A development team may have to deal with both.

Where I would start

As a fractional CTO, I would work in this order:

1. Establish whether your organisation or your main clients fall under NIS2 in their country.
2. Make a list of systems, data, dependencies and suppliers, with an owner for each.
3. Turn on MFA everywhere and remove old accounts.
4. Write down the incident process and rehearse it.
5. Record how you receive, assess and patch vulnerabilities, and keep track of what you did.

The first two steps mostly take time, and after that you know where the gaps are.

Sources

• Directive (EU) 2022/2555 (NIS2) on EUR-Lex
• CMS: Belgium, NIS2 enters into force
• BSI: NIS2 implementation act in force (German)
• Dutch government: Cyberbeveiligingswet in force (Dutch)
• European Commission: Netherlands referred to the Court of Justice
• European Commission: Cyber Resilience Act