The real challenge of NIS2 is not the reporting timeline. It is making escalation decisions under pressure.
When discussing incident escalation under NIS2, the focus is almost always on reporting timelines. Organizations are preparing for the 24-hour early warning, the 72-hour incident notification, and the formal reporting obligations afterwards. These requirements are important, but they are also relatively straightforward. Timelines can be operationalized, measured, and audited.
The real challenge appears much earlier, usually within the first hours of an incident, when information is incomplete and pressure is already building. At that stage, the central question is not technical, but organizational: “When does a cybersecurity incident become “significant” enough to escalate and report?” Surprisingly little attention is given to that decision, despite it being one of the most difficult operational and governance problems introduced by NIS2.
Most companies already have an incident response process in place. They have an impact matrix, escalation procedures, crisis teams, and detection capabilities. Many have invested heavily in tooling, automation, and threat visibility. Yet even organizations with strong technical maturity often struggle when escalation decisions need to be made during a live incident. Not because they cannot detect malicious activity, but because escalation has consequences.
The moment an incident is formally escalated internally or reported externally, the mood changes. Legal teams become involved. Executive leadership becomes involved. Communication concerns rise. Customers, suppliers, regulators, and partners may eventually need to be informed. What started as a technical investigation has now become a business event with reputational implications.
Most companies neglect an important part of NIS2
Currently NIS2 discussions are mostly around compliance: reporting obligations, governance structures, required controls, and sector applicability. Those topics are important, but they are not where most companies will struggle operationally.
The real difficulty is interpretation. Companies are struggling with how to interpret incomplete evidence, uncertain business impact, and the meaning of “significant” in practical terms. The NIS2 directive intentionally avoids technical thresholds because incidents differ between sectors and organizations. From a regulatory perspective, that makes sense, but operationally it creates ambiguity.
The same technical incident can have entirely different implications depending on the environment in which it occurs. A ransomware infection affecting a development environment is totally different from the same ransomware infection affecting a manufacturing planning platform or a hospital scheduling system.
That distinction matters because it means significance cannot be determined through technical analysis alone. Companies that try to reduce NIS2 reporting decisions to static incident severity scores will likely run into problems quickly. Traditional severity models are designed to support operational prioritization, not to support regulatory judgment.
Why traditional incident severity models fail
Most organizations already classify incidents using categories such as low, medium, high, or critical. These classifications are useful because they help response teams prioritize resources and determine operational urgency. But they often fail when organizations try to use them to determine regulatory significance, because a technically severe incident is not automatically reportable under NIS2 and vice versa: an incident that appears technically contained may still become significant because of customer impact or broader systemic risk. What matters from a regulatory perspective is not only what happened technically, but also what the impact of the incident can be for operational continuity.
Security teams naturally assess incidents from a technical perspective. They focus on lateral movement, persistence mechanisms, privilege escalation, and evidence of exfiltration. Executive leadership and legal stakeholders often evaluate the same incident differently. Their concerns are usually operational disruption, contractual obligations, disclosure requirements, customer trust, and reputational exposure. Both are correct, but both are insufficient for NIS2. Under NIS2, organizations need escalation models that connect both worlds.
Why companies hesitate to escalate
In practice, escalation hesitation is seldomly caused by insufficient tooling or weak detection capabilities. The hesitation comes from the consequences attached to escalation itself: organizations understand that once an incident is formally escalated as potentially significant, there will be consequences. Documentation requirements increase, company visibility increases, legal exposure increases, etc. As a result, many organizations delay escalation while waiting for certainty, but most of the time that certainty doesn’t exist during the early phases of an incident.
Cybersecurity investigations work with probabilities. Early indicators are always incomplete and often fragmented. Initial assumptions regularly turn out to be incorrect as investigations continue. But many organizations still think escalation decisions should only happen once facts are fully established.
That approach doesn’t work under NIS2, so we need to redesign incident response processes to support decision-making despite incomplete information, not after uncertainty has disappeared.
The real challenge: decision-making in times of uncertainty
The goal of incident escalation under NIS2 is not to ensure that every reporting decision is perfect. That would be unrealistic during active incidents while the investigation is still ongoing. The real goal is to ensure that decisions are reasonable based on the information available at the time they were made.
We need to understand that technical severity alone is insufficient and that escalation ownership must be defined before incidents occur. That waiting for confirmed impact can create more risk than evaluating plausible impact early. And probably the most important: we need to acknowledge that uncertainty explicitly instead of treating it as a reason to postpone decisions.
To do this, we must separate operational urgency from regulatory significance very clearly. A SOC severity score should not automatically determine whether an incident becomes reportable. Technical severity measures operational risk. Regulatory significance requires a broader assessment that includes business dependency, customer impact, third-party exposure, legal implications, and systemic relevance.
We can only make that broader assessment if we define in advance how technical assessment, legal interpretation, executive accountability, and regulatory decision-making interact during crisis situations.
That does not mean every suspicious event becomes reportable. It just means that uncertainty itself is treated as a factor within the risk assessment process.
Practical guidance for escalation decisions
Companies need structured decision criteria that allow incidents to be assessed consistently across technical, operational, and regulatory dimensions.
At Cingulum, we encourage our customers to answer 4 questions simultaneously:
-
Can critical services become unavailable?
-
Can customers, suppliers, or partners be affected?
-
Can the incident fall within NIS2 reporting scope?
-
How reliable is the available information?
And while answering these 4 questions, one of the most overlooked aspects of incident governance is decision traceability. Companies should be able to reconstruct how escalation decisions were made during an incident: which information was available at the time, which assumptions influenced the assessment, who participated in the discussion, and why was the chosen course of action considered reasonable under the circumstances.
Regulators know that organizations cannot achieve perfect visibility during active incidents. What becomes difficult to defend is inconsistent reasoning, undocumented decision-making, or unclear accountability structures. In practice, weak documentation often creates more regulatory exposure than imperfect technical assessments.
Conclusion: NIS2 is redefining cybersecurity leadership requirements
One of the most underestimated consequences of NIS2 is that it changes the expectations for cybersecurity leadership.
Historically, incident response was primarily viewed as a technical operational capability. Success was measured through detection speed, containment effectiveness, and recovery time. These capabilities remain essential, but they are no longer sufficient.
Nowadays, cybersecurity leaders are expected to function as governance leaders, capable of balancing operational realities, regulatory obligations, reputational exposure, and business continuity concerns simultaneously.
For many companies, that will prove to be the most difficult problem.
About Cingulum
As part of The CRANIUM Group, Cingulum provides tailored cybersecurity solutions, combining expert knowledge and advanced technologies to help businesses stay secure, compliant, and resilient in an ever-evolving threat landscape.
The author of this blogpost is Willem Magerman, Expert Consultant & Lead Auditor at Cingulum.
-
Discover more about Cingulum at https://cingulum.eu
-
Discover more Easi partnerships on https://easi.net/en/partnerships
