For a long time cybersecurity was a matter for power stations, hospitals and large corporations. The German NIS2 Implementation Act (NIS2-Umsetzungsgesetz) has changed that. It has been in force since 6 December 2025 and mainly amends the BSI Act. According to the Federal Office for Information Security (BSI), around 29,500 organisations now fall under the rules, compared with about 4,500 before.

This article explains what the act requires and, above all, what it means for the software in your business. It is not legal advice. Whether and how your company is affected is something to clarify with a lawyer or information security specialists (as of September 2026).

Who is affected

The act distinguishes two groups: “important entities” and “essential entities” (in German, “wichtige” and “besonders wichtige Einrichtungen”). Whether a company belongs to one of them depends on two things.

  • The sector. The act lists 18 sectors, including energy, transport, health, water, digital infrastructure, waste management, food, chemicals and parts of manufacturing, such as machinery and electrical equipment.
  • The size. As a rule, a company counts as an important entity from 50 employees or more than 10 million euros in annual turnover and balance sheet total. As a rule, it counts as an essential entity from 250 employees or more than 50 million euros in turnover and 43 million euros in balance sheet total.

Different rules apply to some entities, and some are covered regardless of their size. The BSI therefore offers a self-assessment tool (Betroffenheitsprüfung) to check whether your company falls under the act. That is the first step if you work in one of the sectors.

What is required

  • Registration with the BSI. Companies in scope must register through the BSI portal, which opened on 6 January 2026. For companies already in scope when the act took effect, the deadline was 6 March 2026. Anyone who missed it still has to register.
  • Reporting significant security incidents. Reporting happens in stages: an early warning within 24 hours, a notification within 72 hours and a final report after one month. That only works if it is settled beforehand who reports and how to recognise a significant incident.
  • Risk management measures. These include incident handling, backup and recovery, supply chain security, access control, training and multi-factor authentication. There is no transition period for these measures.
  • Management responsibility. Management must approve the measures and oversee their implementation. It must take part in training regularly and can be held liable for failures. Cybersecurity can no longer be handed over entirely to IT.

Suppliers feel it too

For many businesses this is the key point. Even if your company is not covered by the act, your customers often are. They have to keep an eye on the security of their supply chain and pass requirements on to suppliers and service providers.

This shows up in information security questionnaires, in new clauses in framework agreements or in the question of how quickly you would report a security incident. Those with good answers stay suppliers. Those without them are at a disadvantage when the next order comes up.

What your software needs to be able to do

Many of the measures concern the organisation. But a large part depends on the systems you work with, including software you have had developed yourself.

Permissions by role

Every employee sees and changes only what they need for their work. Permissions are checked in the system, not merely hidden in the interface. When someone leaves, their access is blocked the same day. How to define roles sensibly is described in the article Roles and permissions.

Two-factor sign-in

A password alone is no longer enough, especially for access from outside. Check which of your systems can require a second confirmation, for example through an app on a phone, and whether it is switched on.

Logs

Who signed in when, who changed which data, who deleted something? Without a log, an incident can neither be detected nor investigated, and the report to the BSI remains vague.

Updates and security updates

All software is made up of many components, and security updates for them are released regularly. For each system, settle who installs the updates and how quickly. What ongoing maintenance involves is covered in the article Software after launch.

Backups that have been restored at least once

A backup is only worth something if it can be restored. Test that, and record how long recovery takes. A backup that sits on the same network as the data is of little help in a ransomware attack. Where your software and its backups are best kept is described in the article Cloud or your own server.

Third-party access

Service providers who access your systems through remote maintenance are part of your supply chain. Each of these accesses should be known, assigned to a person and possible to switch off when it is not needed.

The risk often lies in old software

The biggest gaps are rarely in the new system but in the application nobody has maintained for years: custom software whose developer can no longer be reached, a database on an outdated server, an application with one shared password for everyone. Such systems get no security updates, and often nobody knows exactly who has access.

For these systems the question is whether they can be secured and maintained or whether they should be replaced. What to do when nobody is responsible for a piece of software any more is covered in the article Taking over software without its developer. How to tell that a system should be replaced is described in the article Signs your system is at its end.

When you have new software developed, raise these points from the start: permissions by role, logs, two-factor sign-in and a defined route for updates. How we approach development is shown on our page on tailored business software.

Checklist

  • Have you used the BSI self-assessment to check whether your company falls under the act?
  • If so: is the registration with the BSI done?
  • Is it settled who detects, assesses and reports a security incident?
  • Which of your customers fall under NIS2, and which requirements do they pass on to you?
  • Does every system have permissions by role, and is access blocked immediately when someone leaves?
  • Is two-factor sign-in switched on wherever it is available?
  • Who installs the security updates, for each system?
  • Has the backup been restored at least once?
  • Which systems no longer receive updates, and what will happen to them?