By Yair Knijn · April 22, 2025
NIS2 quietly gave your MSP a 24-hour incident-reporting clock. Most owners never started it.
You own a managed service provider. A client's mail flow goes down at 2pm, your team confirms it's an intrusion by 4pm, and everyone's heads-down on containment. You think the job is to fix the outage and write a clean post-incident summary. It isn't. The moment your engineer typed "confirmed compromise" into the ticket, a regulatory clock started, and nobody knows it's running.
That assumption is the trap. Under NIS2, detection is not the start of a technical cleanup. It's the start of a notification deadline you owe to a national authority, and the directive doesn't pause it while you're busy being useful.
The 24h / 72h / 1-month framework and what counts as significant
NIS2 transposed into national law across the EU from October 2024, and it splits reporting into three filings against one trigger: an early warning within 24 hours of becoming aware of a significant incident, a fuller incident notification within 72 hours with an initial assessment, and a final report within one month. "Becoming aware" is detection, not root-cause confirmation. The early warning has to flag whether the incident looks malicious or could cross borders, so you're filing before you actually know.
"Significant" decides whether the clock applies. The threshold is an incident capable of causing severe operational disruption or financial loss, or considerable damage to other parties. That is a low bar on a bad day, and the safe reading is that a confirmed compromise at a client clears it.
Why MSPs are in scope even when their clients think they aren't
The common excuse is "our clients are too small to be regulated, so this isn't our problem." Managed service providers are named directly in NIS2 as ICT service providers, important entities in their own right. The size-cap rule pulls in providers with 50+ staff or €10m+ turnover, and sector-criticality rules can pull you in below that. You don't inherit obligations from your clients. You carry your own.
And the downside isn't theoretical paperwork. Fines under NIS2 run to €10 million or 2% of global annual turnover, whichever is higher, and national authorities can hold management personally accountable. The owner who skipped the reporting workflow is the named person.
Detection-to-notification: the workflow gap that eats your 24 hours
Here is where MSPs actually lose. The 24 hours doesn't start when someone gets around to thinking about compliance. It starts at detection, buried in a ticket:
- The analyst who detects the incident has no field that says "this may be reportable."
- Nobody owns the decision on whether the threshold was crossed, so it drifts.
- The 24-hour countdown lives in a person's memory, not on the record, and that person goes home.
- By the time someone asks "did we have to report this?", you're at hour 30.
Every one of those is an organisational failure, not a technical one. You can run a flawless restore and still be in breach because the early warning never left the building.
Wiring the regulatory clock into your incident record so it starts itself
The fix is to stop treating reporting as a separate compliance task and bolt it onto the incident record itself. When a ticket is classified as a security incident, the system asks the significance question, and on a yes it stamps the detection time, sets a T+24h early-warning target and a T+72h notification target, assigns an owner, and escalates as those deadlines approach. The clock starts when the incident is created, not when someone remembers it exists.
This is the same discipline as an SLA breach, pointed at a regulator instead of a customer. OpsDesk runs response and escalation clocks per incident inside each client workspace, with an audit trail that shows when detection happened and when each notification went out, so the 24-hour deadline isn't a thing you hope someone remembered. To see how the regulatory clock attaches to an incident record, the incident lifecycle is where it lives.