Blog

NIS2 Article 21.2 b:

Incident management that works under pressure.

I've seen incident plans so polished they deserve their own shelf. The problem is, incidents rarely care about shelves. They happen when someone's off sick, when a supplier is "busy", and when the organisation is already exhausted. That's why NIS2 Article 21.2 b matters. It doesn't demand perfection. It requires a way to handle incidents that actually works in practice.

Robert Willborg

Co-founder and Chief Security Officer at OneMore Secure.

What incident and incident management mean under NIS2

NIS2 is unusually clear with its definitions. An incident is an event that compromises the availability, authenticity, accuracy, or confidentiality of data or the services provided via network and information systems. Incident management covers all actions and procedures aimed at preventing, detecting, analysing, and limiting, or responding to and recovering from an incident (European Union, 2022).

Common confusion: mixing up Article 21 and Article 23

This is a frequent mix-up. Article 21.2 b concerns the ability to manage incidents. The so-called reporting clocks (early warning within 24 hours, notification within 72 hours, and final report within 30 days) are found in Article 23. That doesn't mean Articles 21 and 23 are separate islands. On the contrary: an incident process that doesn't meet these deadlines is rarely a functioning process. However, it is legally correct to say that 21.2 b deals with incident management and 23 with reporting (European Union, 2022).

Swedish application: The Cybersecurity Act

In Sweden, the Cybersecurity Act (2025:1506) came into force on 15 January 2026, replacing the NIS1 law (Swedish Parliament, 2025). The Act is based on NIS2 and requires covered operators to have risk management measures in place, with incident management as a central element. The Swedish Civil Contingencies Agency explains that the law tightens requirements on risk analyses and security measures, and that management involvement carries greater weight (Swedish Civil Contingencies Agency, 2026).

What Article 21.2 b practically requires

I interpret the requirement like this: you must be able to demonstrate a repeatable, practiced, and learning incident process. Not just a document. A process. And this process needs to cover the entire chain: from detection, through triage and containment, to recovery and lessons learned. If you want a simple rule of thumb: what isn't practiced and measured doesn't exist.

To keep things clear and accessible, I use three words everyone can understand: detect, isolate, recover. If these three work in practice, the rest usually falls into place.

How Article 21.2 b links to other parts of Article 21

Incident management does not stand alone. It is connected to several other points in Article 21.2. Continuity and crisis management (21.2 c) determine how quickly you can restore services. Supply chain security (21.2 d) decides whether you get the right information in time. Vulnerability management and secure development (21.2 e) affect how often incidents occur. Effectiveness monitoring (21.2 f) shows if measures work. Training (21.2 g) ensures people act correctly under stress (European Union, 2022).

Risks of 'over-implementation'

One thing I want to be clear about. Incident management sometimes turns into a tools debate: 'We must have SIEM', 'we need a big SOC', 'we have to buy X'. That may be right for some. But NIS2 doesn't require specific tools. It requires proportionate measures that work. If you build an incident process so cumbersome it's never used, you've effectively created a new vulnerability.

Three suggestions that usually make a difference

I'll stick to three suggestions consistent with Article 21.2 b that can be implemented without creating a paperwork factory.

· Practice detection, isolation, recovery.

· Measure time, not texts.

· Build learning into operations.

Practice means running small, realistic scenarios and testing communication channels, decision-making, and technical steps. Measuring time means tracking time to detection, time to recovery, and how long critical services are down. Learning in operations means every incident results in concrete actions that are actually implemented and followed up. This is how you move from compliance to capability.

Final thoughts

Article 21.2 b is not a requirement to never be attacked. It is a requirement that you can handle reality. If you can show you detect, isolate, and recover — and learn from what happens — you are effectively on the right path. When it hits the fan, it's not the policy that saves you. It's muscle memory.