A few years ago, in the middle of an incident I was called into, someone with a business card that said “COO” asked me a question I still think about: “Can you tell me, in the next twenty minutes, whether it’s safe to keep the production line running?” I did not have twenty minutes worth of certainty. I had a partial memory image, a couple of suspicious outbound connections, and a hunch. The COO didn’t want a hunch, he wanted a decision, and eventually he made one himself because the forensic answer wasn’t coming fast enough. That gap, between what the evidence supports and what the business needs to decide right now, is where most incident response actually happens, and it’s the gap that NIS2 has just made legally binding.

cover

In brief

  • NIS2 forces organizations to make consequential business decisions, like whether to isolate or shut down a process, before the forensic investigation is anywhere near complete.
  • The directive’s notification clock (24 hours, 72 hours, one month) doesn’t wait for certainty, and neither does the cost of downtime.
  • Few organizations have actually quantified what an hour of outage costs them, which means they can’t reliably judge whether an incident crosses NIS2’s severity threshold in the first place.
  • Commission Implementing Regulation (EU) 2024/2690 sets concrete financial thresholds (500,000 euros or 5% of annual turnover for certain sectors) that only mean something if you already know your numbers.
  • Treating incident response as a pure IT function, rather than a governance decision with a named business owner, is the structural failure that turns every incident into an improvised negotiation.

The downtime nobody put a price on

Ask most mid-sized organizations what an hour of downtime actually costs them and you’ll get a shrug, or a number invented on the spot to sound appropriately serious. This isn’t a minor gap in the risk register, it’s a fundamental one. Acronis estimates that unplanned OT downtime alone drains 1.4 trillion dollars a year from the world’s largest industrial companies, and the same research notes that under NIS2 a “significant incident” doesn’t require a full production stoppage: loss of operational visibility, loss of control, or the inability to restore safely all qualify as conditions that can trigger the 24-hour reporting clock, regardless of whether a single machine actually stopped moving. For Italian SMEs, BullTech’s own figures put the daily cost of a manufacturing stoppage between 8,000 and 25,000 euros, before reputational damage, contractual penalties, and the inevitable GDPR notification pile on top.

The point isn’t the precision of any single figure. It’s that an organization which has never sat down and calculated its own downtime cost per critical process is flying blind exactly when it needs the clearest possible view: at the moment someone has to decide whether the incident in front of them counts as “severe operational disruption” under the law, or just an unpleasant Tuesday. A proper Business Impact Analysis, the kind that assigns a real euro figure to an hour of each critical process being down, isn’t paperwork for the compliance folder. It’s the only tool that lets someone make a fast, defensible decision instead of a guess dressed up as authority.

NIS2 turns severity into a countdown, not a debate

Directive (EU) 2022/2555, the NIS2 Directive, defines a significant incident in Article 23(3) as one that has caused, or is capable of causing, severe operational disruption or financial loss, or one that affects other people or entities through considerable material or non-material damage. The follow-on Commission Implementing Regulation (EU) 2024/2690 sharpens that language for specific sectors like DNS providers, cloud services, and data centers, with concrete financial anchors: an incident that could cause losses exceeding 500,000 euros or 5% of total annual turnover clears the bar. Those aren’t abstract legal concepts to be argued over in a committee meeting three weeks later. They’re numbers someone has to estimate, under pressure, while the incident is still unfolding.

Italy’s ACN has translated this into an operational five-phase model, described in detail in this analysis of the ACN incident handling framework: pre-notification within 24 hours, a detailed notification within 72 hours of the moment the entity becomes aware (“evidenza”), categorization into severity tiers IS-1 through IS-4, and a five-step handling process running through reporting, investigation, containment, and eradication. What all of this quietly assumes is that somebody in the organization can, within hours, translate “we found something bad on the file server” into “this is or is not a significant incident under the law.” That translation is not a technical exercise. It’s a business judgment made with incomplete information, on the clock, with regulatory consequences attached to getting it wrong in either direction: under-report and face sanctions, over-report and burn credibility with the same CSIRT you’ll need to call again next year.

Decisions with incomplete data are still decisions

This is where my digital forensics background makes me allergic to how most incident response plans are written. They read like the investigation will be finished before anyone has to act, complete with root cause, full IOC list, and a tidy timeline. Real incidents, the kind I’ve documented when writing about ransomware operators like GhostLock, rarely cooperate with that fantasy. You isolate systems based on partial telemetry. You decide whether to pull a NAS offline before you know for certain whether the attacker is still inside it. You brief the board with confidence intervals, not certainties, because waiting for certainty means missing the 24-hour window entirely.

Part of the problem is that forensic investigation and incident triage pull in opposite directions, and most organizations train for one while the regulation demands the other. A full forensic examination is built to reach a conclusion you can defend in court or in front of a regulator months later. Triage within a NIS2 window is built to reach a threshold you can act on now: enough to estimate the blast radius, enough to judge whether containment will cause more damage than the attacker, enough to tell the CSIRT that yes, this counts as significant. These are different muscles. Organizations that treat them as the same process end up doing neither well, and the forensic team gets blamed for being slow while the business team gets blamed for being reckless. A forty-page incident report delivered three weeks late is compliance fiction. What the directive actually demands is a defensible assessment delivered in hours, refined as the picture improves. The forensic team that understands this distinction and the business team that learns to read partial evidence are the same team, or they need to become one.

Attribution and evidence quality matter just as much for the business decision as for the eventual regulatory report. I’ve argued before, in the context of what I called the FACT attribution framework, that in environments subject to DORA, NIS2, or sector-specific compliance requirements, the question of who did what to which system has stopped being optional, precisely because the notification you file becomes a legal document, not an internal memo. An organization that hasn’t invested in the forensic readiness to answer “what happened, how bad is it, and how confident are we” quickly will find itself making the downtime decision, and the notification decision, on vibes. That works until the day it doesn’t, and NIS2 has made sure that day comes with a fine attached.

Governance means someone outside IT owns the call

The uncomfortable truth is that “should we shut down the line” is not a question IT should be answering alone, and pretending otherwise is exactly the kind of governance gap that periodic reviews are meant to catch. I’ve written before about how making NIS2 reviews work in real life means building a system that adapts when reality changes rather than a static annual checkbox, and incident decision authority is a perfect example of something that looks fine on paper and collapses the moment it’s actually needed. If the person authorized to halt a production line, accept a data exfiltration risk, or approve a ransom conversation (however briefly, before saying no) has never been clearly named, trained, and rehearsed, the decision will default to whoever happens to be on the call at 2 a.m., regardless of whether they have the authority or the business context to make it.

This is exactly why tabletop exercises earn their keep: not to test whether the SOC can detect an intrusion, but to force the CFO, the COO, and the legal team into the same room as security, rehearsing the moment when someone has to decide with 60% of the picture instead of 100%. An organization that has never run that scenario will discover, live, during an actual incident, that nobody agreed in advance on what “acceptable risk” means in euros, hours, or reputational exposure. By then, the 24-hour clock is already running, and improvisation is not a governance model.

FAQ

What makes an incident “significant” under NIS2? Under Directive (EU) 2022/2555 an incident is significant if it has caused, or is capable of causing, severe operational disruption or financial loss, or if it affects other people or entities by causing considerable material or non-material damage.

How much time does NIS2 give organizations to notify a significant incident? The notification runs on a three-phase clock: an early warning within 24 hours, a detailed notification within 72 hours, and a final report within one month, all measured from the moment the entity becomes aware of the incident.

Why is calculating downtime cost important for NIS2 compliance? Because severity thresholds under the NIS2 implementing rules are partly financial, an organization that hasn’t quantified its own downtime cost cannot reliably tell whether an incident crosses the reporting threshold, let alone brief the board on whether to shut a process down.