NIS2 in plain language: what "detect and respond" actually requires

By André Beran · Cybersecurity Architect & Co-Founder, Graydaxe

NIS2 uses a lot of words for "appropriate measures." Read the directive and the national implementations and you will find risk management, governance, supply chain, reporting timelines. All of it matters. But when it reaches the security team, most of it comes down to one practical thing: you have to detect an incident, respond to it, and be able to show that you did.

I have spent 15+ years assessing security tools — SIEM, XDR, vulnerability management. When I look at a setup against what NIS2 expects, the same quiet gap tends to turn up. The logs are flowing. The dashboards look busy. The tooling was bought, deployed, and then left to run. Ask the simple question — would this catch a real attack, and in time? — and the honest answer is often "we're not sure."

That uncertainty is what NIS2 is really pushing on. Below are the three questions I keep coming back to. None of them is about buying more tooling.

A SIEM detects what it has rules and data for. The real question is whether those rules cover the techniques an attacker would actually use against you — and whether the right log sources are even reaching the collector. In many assessments the coverage map has holes nobody planned: a critical system that logs nowhere, an identity provider that isn't watched, a detection rule that was switched off during a noisy week and never turned back on. Coverage is not "do we have a SIEM." It is "do we see the things that would hurt us."

A platform that fires a thousand alerts a day is not the same as a platform that helps you respond. When everything is an alert, nothing is. The practical test: if a real incident happened tonight, would it rise above the daily noise — or sit in a queue with five hundred low-value notifications until Monday? Tuning alert quality, fewer and sharper and prioritised, is unglamorous work. It is also exactly the work that decides whether you notice in time.

NIS2 is explicit about responsibilities. When the alert fires at 2am, someone has to act — and everyone should already know who. This is the part that is least about technology and most about people. The teams that handle incidents well decided the roles in advance: who triages, who escalates, who talks to management, who keeps the record. The teams that struggle find out in the moment, and the finger-pointing starts. Defined in advance, and written down, is not bureaucracy. It is what lets people act under pressure.

So how do you know where you stand?

This is where many teams get stuck. The issue is rarely a lack of products. It is the lack of an honest, evidenced picture of where the current setup actually stands — against the threats you face, and against what NIS2 now expects.

That is the gap we built GrayCheck to close. It is a vendor-neutral assessment — we don't sell SIEMs, so we have no reason to push one — that looks at your tool on the running system, not by self-assessment. It scores the current state against 100+ criteria across 10 domains, built on 15+ years of hands-on practice and mapped to frameworks like NIS2 and ISO 27001. The criteria are deterministic and weighted; our AI engine, GrayD, assists the assessors and checks the results for inconsistencies — AI-assisted, not AI-replaced. What you get back is a maturity picture: your biggest gaps, and the next steps to close them.

See → Assess → Improve. That is the whole idea: see clearly, assess honestly, improve where it counts.