By Theodoros Kavouras, Manager in Cybersecurity Consulting of ADACOM
It is Monday morning. Your SOC picks up anomalous lateral movement at 08:47. By 09:15, it is clear this is not a false positive. Someone is inside. The containment decision sits on the table, the communications team is asking what to say, legal wants to know if customers need to be notified, and a senior executive is asking how long this has been going on.
Nobody has a clear answer. Nobody has a pre-agreed answer. And the clock that determines your regulatory standing and your business continuity is already running.
What NIS2 Actually Requires
The NIS2 Directive establishes a three-stage notification timeline for significant incidents. Organizations must issue an early warning to their national competent authority within 24 hours of becoming aware of a significant incident. A formal notification follows within 72 hours, including an initial assessment of severity, impact, and indicators of compromise. A final report is due within one month.
The critical phrase is "becoming aware." Regulators do not measure the clock from the moment you contain the incident or confirm its full scope. Awareness triggers the timeline. That distinction is where most IR plans quietly break down.
Where Organizations Actually Fall Apart
Most organizations have an IR plan. Very few have tested whether that plan holds up during the first ninety minutes of an actual incident, when pressure is highest, and information is most incomplete.
The first failure point is usually escalation. Without pre-agreed definitions of what constitutes a significant incident under NIS2, the initial alert enters a grey zone. Is this significant enough to trigger the notification process? Who makes that call? In organizations without a tested escalation path, that question travels up the chain. Thirty minutes pass. An hour. The 24-hour window is now 22 hours, and no one has yet confirmed that the notification process has started.
The second failure point is roles and accountability ownership. Incident response under pressure is not a technical exercise; it is a coordination exercise. The CISO needs containment data from the SOC, legal needs a summary for the notification draft, the communications lead needs to know what can be said externally, and the executive team wants a status update that does not exist yet because no one has been designated to produce it. When these roles are not defined in advance, the IR lead serves as the default coordinator for all parallel workstreams. Progress stalls across all of them simultaneously.
The third failure point is the notification process itself. Producing a meaningful early warning within 24 hours requires more than knowing an incident occurred. The notification needs to cover the nature of the incident, affected systems, and estimated impact, initial indicators of compromise, and containment actions taken or underway. Without pre-drafted templates, that document becomes a writing exercise conducted under legal scrutiny, in real time, while the incident is still active. Most teams underestimate how long it takes to draft, review, and approve a regulatory notification when there is no template to build from.
Finally, the fourth failure point is third-party communication. Enterprise relationships now routinely carry contractual notification obligations. If a breach affects customer data or shared infrastructure, clients and partners may have their own regulatory timelines that depend on your timely notification. An IR plan that does not define who notifies which partners, within what timeframe, and through which channel leaves that entire workstream unassigned.
Third-party communication is not unique to NIS2. Under DORA, for example, financial entities are required to maintain contractual arrangements with ICT providers that include incident notification clauses. Failing to meet those obligations is not only a commercial problem; it creates downstream compliance exposure for the organizations you work with.
What connects all four failure points is the same root cause: decisions that should have been made before the incident are being made during it. Each one costs time. Collectively, they can cost the 24-hour window entirely.
What the Gap Actually Costs
The consequences of the IR gap are tangible and can be financial, operational, and reputational. They compound each other.
Breach containment costs rise sharply when response is uncoordinated. Every hour of uncontrolled access extends the potential blast radius. The IBM Cost of a Data Breach Report consistently shows that organizations with tested IR plans and dedicated IR teams contain incidents significantly faster and at materially lower total cost than those without.
In addition to containment costs, affected businesses must account for regulatory penalties. In an NIS2 context, fines for significant entities can reach EUR 10 million or 2% of their global annual turnover. For essential entities, those thresholds double. An untested plan is not an operational risk in the abstract; it is a quantifiable financial liability.
The operational drag extends well beyond the security team. When escalation paths are unclear and communication templates do not exist, the incident pulls finance, legal, customer service, and executive leadership into an uncoordinated response simultaneously. Productivity losses in prolonged incidents are rarely measured but consistently significant.
Reputational damage is shaped more by the quality of the response than by the incident itself. Organizations that communicate proactively and meet regulatory deadlines are treated differently by media, customers, and regulators than those that appear reactive or opaque. A tested IR plan gives organizations the operational capacity to respond in a way that conveys control. The absence of one typically produces the opposite signal at the worst possible moment.
Research in crisis communications consistently shows that customers distinguish between the incident and the response. When an organization's public statements match its operational actions, when promised notifications arrive on time, and updates reflect reality, customer relationships tend to survive even significant breaches. The damage to trust comes not from the incident itself but from the gap between what an organization says it is doing and what it actually can do.
What a Tested Plan Actually Changes
A documented IR plan in a shared drive is not an IR capability. The operational difference between a plan that exists and a plan that works is visible in four specific areas:
- Pre-agreed escalation triggers that eliminate the grey zone around what constitutes a significant incident
- Pre-defined roles that distribute workstreams before the pressure starts
- Pre-drafted notification templates that remove the writing exercise from the critical path
- Rehearsed third-party communication protocols that protect both the organization and its partners.
Most organizations discover their IR plan's weakest points during a tabletop exercise. The ones that do not run exercises discover them during an actual incident, with the clock already running and the regulator's inbox waiting.
The difference is not marginal. A tabletop surfaces the gaps in a controlled environment. Each of those gaps, found in an exercise, becomes a two-hour fix. Found during a live incident, each one becomes a compounding delay inside a timeline that offers no slack.
When time is of the essence during an incident, make sure you can buy as much time as possible by having a tested, actionable IR plan.
Is your Incident Response plan ready for the 72-hour clock?
ADACOM's Incident Response services help organizations build, test, and maintain IR capabilities that meet NIS2 requirements and protect business continuity.
Talk to our team → Contact Us Now, at https://www.adacom.com/contact-us