The Clock Is Ticking, the Evidence Isn’t: What Incident-Reporting Laws Like NIS2 Actually Require

Introduction

A significant cyber incident hits at 11pm on a Friday. Under NIS2, the clock on the first regulatory deadline starts the moment the organisation becomes aware of it, not the moment someone gets around to writing the notification. Twenty-four hours later, a national authority expects an early warning. Seventy-two hours after that, a fuller report with an initial assessment of severity and impact. A final report follows within a month.

The deadlines are demanding by design. What most organisations discover, usually during the incident itself rather than beforehand, is that the clock is the easy part to plan for. The harder problem is evidence: knowing, with enough precision to write a credible 72-hour report, what was actually accessed, by whom, from where, and what happened to it next. This article looks at what incident-reporting regimes like NIS2 actually demand operationally, and why the evidence gap is usually the real point of failure, not the timeline.

• Takeaway 1: NIS2 incident reporting runs on a fixed three-stage clock. A 24-hour early warning, a 72-hour detailed notification, and a final report within one month, each triggered from the moment the organisation becomes aware of a significant incident.
• Takeaway 2: The 72-hour report demands specifics, not a narrative. Severity, impact and an initial assessment of what happened have to be substantiated, which requires records the organisation can query quickly, not reconstruct.
• Takeaway 3: Most organisations can meet the deadline but not the evidence bar. Having an incident response plan is not the same as being able to produce, within hours, a precise account of what data was touched.
• Takeaway 4: Fragmented logging across channels is the most common reason evidence takes too long to assemble. When email, file sharing, APIs and other channels each log separately, someone has to correlate them under time pressure before a single report can be written.
• Takeaway 5: A single, continuously running audit trail turns reporting from a scramble into a query. Evidence that already exists in one place gets pulled and verified, rather than requested from multiple systems and reconciled by hand.

Executive Summary

Incident-reporting regimes such as NIS2 are frequently treated as a deadline-management problem: build an internal process fast enough to notify the right authority within 24 and 72 hours. That framing misses where organisations actually struggle. The deadlines are fixed and well known in advance. The evidence needed to fill them in is not, because it depends on whether the organisation’s systems captured, in enough detail and in a queryable form, what happened during the incident. For security and compliance leaders, the practical question is not whether the incident response plan names the right contacts. It is whether the underlying data can answer, in the time available, exactly what was accessed and by whom.

Why Incident-Reporting Timelines Are Getting Shorter, Not Longer

Modern incident-reporting frameworks have moved away from the single, delayed notification model that characterised earlier data protection rules. A staged reporting structure, with an early warning inside the first day and a substantive report within three, reflects a regulatory judgement that early visibility matters more than a fully polished account.

The Three-Stage Structure Behind Modern Incident Reporting

An early warning, typically due within 24 hours of an organisation becoming aware of a significant incident, exists to get a signal to the relevant authority before the full picture is known. A detailed notification follows within 72 hours, expected to include an initial assessment of severity and impact, sometimes with indicators of compromise. A final report, due within a month, closes the loop with root cause and remediation. Each stage assumes the organisation already has, or can quickly produce, the underlying facts. The regulation sets the clock. It does not supply the evidence.

Why “Significant Incident” Still Requires a Fast, Confident Answer

Before any report gets written, someone has to determine whether an incident meets the threshold that triggers reporting at all, typically involving severe operational disruption, financial loss, or considerable harm to others. Making that call quickly and defensibly requires visibility into scope and impact from the outset. An organisation that cannot say, within the first hours, roughly what happened and to what data, is not just at risk of a late report. It is at risk of misjudging whether a report is required in the first place.

The Real Bottleneck Is Evidence, Not the Deadline

Ask most security teams whether they have an incident response plan, and the answer is yes. Ask whether that plan has ever been tested against a real 72-hour reporting deadline, and the confidence usually drops. The gap between having a plan and being able to execute it under time pressure is almost always an evidence problem.

What a Credible 72-Hour Report Actually Requires

A 72-hour report is not a description of what the organisation believes happened. It is expected to include a genuine initial assessment: severity, likely impact, and often technical indicators. Producing that requires being able to answer, quickly and with confidence, which systems and data were involved, who accessed what, and when. Teams that have to manually pull logs from several disconnected systems, format them consistently, and cross-reference timestamps are working against the clock rather than with the evidence.

Why Fragmented Logging Turns a Reporting Deadline Into a Fire Drill

Most organisations run sensitive data through several channels: email, file sharing, APIs, managed file transfer, increasingly AI agents. When each channel logs independently, in its own format, at its own level of detail, assembling a single coherent account of an incident means someone has to reconcile several partial pictures under deadline pressure. Reporting timelines get missed here, or worse, met with a report that understates what actually happened because the full picture never got assembled in time.

What Reporting-Ready Evidence Actually Looks Like

An organisation that consistently meets incident-reporting deadlines with confidence, rather than relief, generally has the same underlying property: a single source of record for who touched what, when, and from where, spanning every channel sensitive data moves through, that exists before the incident happens rather than being assembled after.

Continuous Logging Beats Reconstruction After the Fact

Evidence that has to be reconstructed after an incident is inherently slower and less reliable than evidence that was already being captured continuously. A log that records every access, send, share and download in real time, without gaps introduced by throttling or delayed writes, means the 72-hour report is a matter of querying existing audit trail records rather than piecing together what probably happened from fragments.

Cross-Channel Correlation Has to Exist Before the Incident, Not During It

Because significant incidents rarely confine themselves to one channel, evidence has to be correlatable across channels from the outset. An organisation that can show exactly which files an external party accessed by email, downloaded through file sharing, and pulled through an API, on one timeline, answers the “what happened” question in the time the regulation allows. An organisation piecing that together from separate systems during the incident usually cannot.

Building Incident-Reporting Readiness Before the Clock Starts

The organisations that handle incident-reporting obligations well treat the evidence question as infrastructure, not as an incident-response exercise. That means auditing, ahead of any incident, whether logging is continuous and complete across every channel sensitive data moves through, whether that logging can be queried fast enough to inform a decision within hours rather than days, and whether the resulting record would actually satisfy an authority asking for specifics rather than assurances. Answering these questions after an incident starts is the definition of being unprepared, however good the response plan looks on paper.

How a Data Control Plane Makes Reporting Deadlines Achievable

Meeting a 24-hour and 72-hour reporting clock consistently is fundamentally a data visibility problem, not a process-documentation problem. It requires a governance layer that captures every access, send, share and download across every channel sensitive data moves through, including email, file sharing, APIs and AI agents, continuously and in a single, queryable form, so that when an incident happens, the evidence already exists rather than needing to be assembled.

The Kiteworks Data Control Plane applies data-aware, zero-trust controls to every action across every channel and captures each one in a tamper-proof, unthrottled audit log that feeds directly into SIEM tooling. Because logging is continuous and never sampled or delayed, security and compliance teams can query exactly what happened, by whom, and when, within the hours a 24-hour early warning or 72-hour notification actually allows, rather than reconstructing events from separate systems under deadline pressure. The same record that supports day-to-day NIS2 compliance reporting becomes the evidence base for incident notifications, without a separate reconstruction effort each time.

Organisations that want to test whether their current logging would actually support a 24-hour and 72-hour reporting timeline can schedule a custom demo to see how continuous, cross-channel evidence capture applies to their own incident-response process.