What NIS2 asks of a technical team

NIS2 is often discussed as a legal project. Most of what it asks for, though, ends up as work for the people who run systems: access, logging, backups, supplier records and an incident path that can meet a clock. This note reads the directive from that side. Which obligations apply to a given organisation, and how a member state has written them into national law, is a question for its lawyers. We only describe what the text asks engineers to make true.

The text and its dates

NIS2 is Directive (EU) 2022/2555. A directive does not apply on its own: each member state writes it into national law. Article 41 set 17 October 2024 as the date by which member states had to adopt those national measures, so the exact duties, supervisors and penalties depend on the country in which an organisation is established or provides services.

Management owns the measures

Article 20 requires the management bodies of essential and important entities to approve the cybersecurity risk-management measures and oversee their implementation, and to follow training. For a technical team this changes the conversation. A control that nobody senior has approved is a gap in itself, so the first artefact is usually a short register that names each measure, its owner and the person who approved it.

The list of measures

Article 21 lists the measures that must at least be covered. Read as engineering work, the list includes:

• risk analysis and information system security policies
• incident handling
• business continuity, including backup management and disaster recovery
• supply chain security, including the security of relationships with direct suppliers
• security in acquiring, developing and maintaining systems, including vulnerability handling
• basic cyber hygiene and training, cryptography, human resources security, access control and asset management
• multi-factor authentication where appropriate

Each item turns into something that either runs or does not: a restore that has been tested, an identity provider that enforces a second factor, a supplier register with an owner per entry. Policies matter, but a policy for a control that does not operate leaves the gap where it was.

The reporting clock

Article 23 sets the reporting sequence for a significant incident: an early warning within 24 hours of becoming aware of it, an incident notification within 72 hours, and a final report within one month of that notification. The legal team decides what counts as significant and who files. The technical team has to make the clock achievable.

In practice that means three things. Someone must be alerted at any hour and have the authority to start the clock. The logs that show what happened must already exist and be kept long enough. And the first facts, such as affected systems, start time and suspected cause, must be retrievable in hours, not reconstructed from chat messages days later.

Where to start

We start from the boundary the client's lawyers have set: the services and systems in scope. We then compare each measure in the list with what runs today and mark each gap as either a missing control or a missing record, because the two need different work. The output is a register an auditor can read and a backlog an engineer can pick up on Monday.

Suppliers deserve early attention. The supply chain measure means organisations in scope will ask their own technical suppliers for evidence, so a company outside the directive can still find its customers asking NIS2 questions. Having the answers written down before the questionnaire arrives is cheaper than writing them under a deadline.