Reporting cyber security incidents starts with understanding what happened

After reading this article, you will understand:

• Why a single incident can fall within the scope of the GDPR, NIS2, DORA, the CRA and the AI Act at the same time, each with its own deadline and regulator;
• How technical facts determine the legal characterisation of an incident, rather than the internal label given to it;
• Why poor logging is not just a technical issue but a legal one too: in 86% of Hunt & Hackett’s incident response investigations in 2025, telemetry was incomplete;
• Why a nine-day attack timeline can become legally significant, and only becomes visible if the necessary forensic material exists;
• Why certainty is not a precondition for reporting, and what regulators expect instead.

Good incident response starts with the facts

Organisations with mature incident response capabilities do not begin with the law or the deadline. They begin with the event itself. What has been observed? Which systems have been affected? Which data, including personal data, may be involved? Only once the facts are clear, or can at least be assessed on a defensible preliminary basis, can a reliable legal assessment be made. Incident response therefore becomes an integrated technical and legal process. It is no longer “technology first, legal later”, or vice versa, but two tracks running side by side.

Starting with the event also means starting with the phase the event is in. A ransomware attack in which encryption has not yet taken place demands different priorities from one in which systems have already been encrypted and data may have been exfiltrated. In the first case, the focus is on preventing encryption: isolating infected systems, improving visibility and cutting off the attacker’s access. In the second, the focus shifts to identifying the root cause, assessing the damage, restoring operations and determining what data may have left the organisation. Those differences in approach help determine which technical questions need to be answered first, and therefore which legal assessments can properly be made at a given stage.

One event, multiple legal identities

What is technically one event may have several legal identities. A ransomware attack affecting a managed service provider (“MSP”) processing customer data may be relevant under:

• GDPR — if personal data has been leaked, destroyed or accessed unlawfully;
• NIS2 — if the MSP qualifies as an essential or important entity;
• DORA — if an affected customer is a financial entity;
• CRA — from 11 September 2026, where there is an actively exploited vulnerability in a product with digital elements;
• AI Act — where there is a serious incident involving a high-risk AI system within the meaning of Article 3(49).

Which regime applies depends on the facts, not the label the organisation gives the incident internally. An incident viewed internally as “an outage” may have a very different status under the GDPR, NIS2, DORA or the CRA. That is why the first legal step is not to assign a deadline, but to map the potentially relevant regimes.

The same is true from a technical perspective. The response differs according to the type of incident:

• Ransomware requires immediate isolation of infected systems, broad and as-complete-as-possible visibility through monitoring, and root cause analysis to understand the extent of the compromise and limit further damage.
• Espionage is usually covert and prolonged, and calls for a measured response that does not alert the attacker.
• Business email compromise may have a narrow technical footprint but an immediate and potentially significant financial impact.
• A data breach may be either visible or hidden.
• A supply chain attack has a systemic quality, and responsibility for the problem may be difficult to untangle.

These technical differences cannot be separated from the legal assessment: the nature of the incident helps determine which facts must be established technically and which reporting thresholds may be met.

This is not an abstract issue. Hunt & Hackett’s Trend Report 2026 is based on more than 54,000 security events investigated in 2025 by its Security Operations Centre (SOC) and Incident Response team. Within incident response investigations specifically, 71% of incidents were financially motivated, with ransomware (43%) and business email compromise (29%) the dominant categories. Hunt & Hackett also sees identity-based intrusion emerging as a leading attack pattern. According to IBM data from 2025, this accounts for around 30% of global breaches. Underlying this is a shift that matters for legal characterisation: from perimeter to identity, from encryption to data theft, and from paper compliance to demonstrable resilience. That same shift is reflected in the reporting landscape: from a single reporting obligation to several regulators appearing in parallel, each with its own deadline.

The often-overlooked first step: a regime scan

In a well-designed incident response playbook, every reporting decision is preceded by a short legal horizon scan. Not to determine immediately which regime applies — that is often impossible in the first few hours — but to avoid overlooking a relevant reporting track until it is too late. The question is always: which laws may come into play, based on what we know so far?

A practical regime scan starts with three questions:

In practice, the regime scan often runs into a recurring problem at the very first step: organisations frequently do not know exactly which systems and data they hold, which business processes depend on them, or which regime applies to them. That lack of visibility is not usually due to unwillingness, but because the information has never been built up systematically. The result is that the regime scan takes longer than it should in the early stages of an incident, and relevant reporting routes come into view too late.

Each regime also has its own regulator. Regulators do exchange information in some respects, but that does not relieve the correct legal entity within the group of its own reporting duty. One notification to one authority is not automatically enough. If you notify the wrong authority, or fail to notify because another regime appeared to apply, you have not complied with your obligations under the other regime.

Forensic facts determine the legal assessment

A legal assessment can only be made with some confidence once sufficient technical facts are available. A forensic investigation provides several core insights for this purpose:

• A timeline of detection, access and any further spread through the network (lateral movement);
• The scope of affected systems, accounts and categories of data;
• A reasoned assessment of what has been viewed, copied, encrypted or exfiltrated; and
• A clear knowledge status identifying what has been established, what is likely and what remains unresolved.

Hunt & Hackett’s experience in ransomware incidents offers a useful illustration. Affected systems and accounts should ideally be isolated as quickly as possible, and in any event within one to three hours of detection. Initial scoping and root cause analysis will continue for at least the first 24 hours. A full root cause analysis typically takes two to eight days to establish the first 80% of findings; the remaining 20% may take up to 25 days. These technical timelines run directly alongside the legal reporting deadlines. Under NIS2, an early warning must be issued within 24 hours and an incident notification within 72 hours, even though the forensic investigation will still be ongoing. That tension cannot be eliminated. It is exactly why evidence-based preliminary assessments are not a fallback, but the standard approach. Those facts then determine the legal outcome. Is there a personal data breach, a significant incident affecting an essential or important entity, a major ICT-related incident, a serious incident involving a high-risk AI system, or an actively exploited vulnerability in a product with digital elements? Multiple characterisations at the same time are more the rule than the exception. In every case, regulators want more than a conclusion in a notification: they want a factual basis for it. A report without a technical foundation is vulnerable. It raises questions, makes follow-up more difficult and may later come under pressure. Equally vulnerable is a failure to report without a documented and reasoned basis for that decision. From the outset, forensic work informs the legal analysis. At the same time, legal triggers shape the forensic scope from the outset: which questions need to be answered as a priority, which log sources must be preserved, and what level of timeline precision is needed to justify compliance with deadlines? The questions legal teams ask — was there unauthorised access, was there exfiltration, was there lateral movement, when did the incident begin, when was there sufficient awareness, what is the scope — are the same questions forensic teams ask, but for a different purpose. Good incident response aligns those two conversations.

The scale of that challenge is again clear from Hunt & Hackett’s figures. In 86% of its incident response investigations in 2025, detection and investigation were hindered by incomplete telemetry, such as missing audit logs, insufficient log retention or systems falling outside the monitoring scope. One example involved a ransomware attack in which the attacker claimed to have stolen data. Forensic investigation found no direct evidence of exfiltration, but the absence of network data meant a definitive conclusion could not be reached. The advice was therefore to proceed on the basis of possible data loss, monitor for publication of the data, and make the necessary legal and regulatory notifications. Not because exfiltration had been proven, but because the forensic evidence needed to rule it out was missing. That is exactly the kind of situation in which reporting cannot wait for certainty, and in which the quality of logging determines how defensible the reporting decision will look in hindsight. That goes directly to the organisation’s legal position. If you cannot reconstruct what happened, you cannot explain why a notification was or was not made, or why an earlier assessment was later revised. The evidential record on which the notification rests is contained in the same log sources that must also support the forensic analysis.

Where forensic investigation and legal work meet

The point at which forensic investigation and legal support most clearly converge is the reporting stage itself. The forensic team reconstructs what happened, ensures the technical reliability of the factual picture and translates new findings into possible implications for scope, impact and earlier assumptions. The legal team translates that factual picture into concrete reporting obligations, manages contact with the regulator, selects the appropriate legal basis and authority, and oversees the rhythm of early warning, incident notification, interim update and final report, without communication becoming either too definite or too vague. Neither role can replace the other at this stage, and neither can build a sustainable position with the regulator under time pressure without the other.

Experience matters greatly here. Teams that have managed incidents under regulatory pressure before know which questions typically arise early: what is certain, what is likely, what remains unknown, what measures have been taken, and when will further information follow? That experience helps prevent an initial report from being too categorical, too vague or technically under-supported. The same applies on the forensic side. The quality of incident response is often most visible when not all the facts are yet known. At that point, decisions still need to be made on containment, evidence preservation, investigative priorities and communications while the investigation is ongoing. Experience helps ensure those decisions are proportionate, while still leaving room for new findings as the factual picture develops.

The maze of deadlines

The law requires speed. But often the most difficult question is not which deadline applies, but when it starts to run. GDPR looks to the moment the breach becomes known. NIS2 turns on awareness of the significant incident. DORA links the initial notification to classification as major and to the moment the entity became aware of the incident. The AI Act looks to the establishment of a causal link, or the reasonable likelihood of one, between the AI system and the serious outcome.

That is exactly why a precise incident timeline is not a technical detail, but a matter of legal significance.

Two cases handled by Hunt & Hackett illustrate how important timeline precision can be in practice. In the first, a Dutch organisation was informed of a breach in which the attacker had already obtained the highest level of privilege and was actively moving further through the network. The moment of detection was therefore not the same as the moment of initial access, and that distinction is legally important: when did the incident begin, when was there sufficient awareness, and from what point did the reporting period start to run? In the second, forensic investigation reconstructed an attack timeline of nine days between initial access and ransomware deployment — nine days in which the attacker was active, and which only became visible because the necessary forensic material was available. If you cannot document when awareness, detection, classification or the establishment of a causal link took place, you cannot explain why a report was or was not made on time.

At the same time, the factual picture is incomplete in most cases. Not all logs have yet been collected, EDR data is still being correlated, IAM events are still being reconstructed, and exfiltration hypotheses are still being tested. That is the central tension in modern incident response. If you cannot establish forensically what happened, you cannot reliably determine from a legal perspective what must be reported. But if you wait too long for complete certainty, you may be too late. The answer is not to wait for certainty. Under several regimes, a preliminary notification may be explicitly required before the forensic investigation is complete. The solution, therefore, is to work with evidence-based preliminary assessments. Even in an initial report, an organisation must be able to say: this is what we knew at the time, this is what we did not yet know, these were our assumptions, these were the open lines of inquiry, and this is why we did or did not report in this way. Follow-up notifications and interim reports are there precisely to supplement a preliminary factual picture and, where necessary, revise earlier assessments.

The test in hindsight will not be whether the organisation knew everything in the first hour, but whether, based on the information available at the time, it chose a defensible course and updated that course carefully as new facts emerged. That is a lower bar than perfection, but a higher one than simply meeting a deadline.

From five checklists to one integrated process

The model that follows is simple in concept, but demanding in practice.

First, the security team establishes what has been observed. Second, legal or compliance maps which legislation may be relevant in light of that observation. Third, forensic experts provide an initial factual picture, clearly identifying what has been established, what is likely and what remains unresolved. Fourth, legal makes the legal assessment and determines which reporting obligations are triggered. Fifth, the notification is made to the correct authority, in the correct form and within the correct timeframe. Sixth, the evidential record is built so that the decision-making process can later be reconstructed and, where necessary, defended. This is not a linear process. Steps three to six continuously overlap. New forensic facts lead to updated legal assessments, which may in turn trigger new reporting obligations or updates to existing notifications. That is why a shared incident language between security and legal teams matters so much: forensic findings must be expressed in a way that can be interpreted legally, and legal triggers must be translated into specific investigative questions. If the two are kept apart, they will drift out of alignment under time pressure.

From an incident response perspective, forensic investigation and regulatory reporting always run in parallel in this process flow. Initial root cause analysis, forensic investigation and first reporting happen at the same time, not one after the other. And even after the acute phase, the evidential record remains live: regulatory reporting and legal review are not the end of the incident, but an ongoing workstream based on the same forensic findings that also guide recovery.

In conclusion: reporting starts with understanding what happened

Under the new EU data and cyber laws, incident response is not an administrative exercise in which the technical team works first and legal drafts a report afterwards, or vice versa. It is an integrated process in which forensic investigation and legal assessment run side by side from the outset, with the same event as their common starting point and the same evidential record as their shared outcome. Reporting therefore does not begin with a deadline. It begins with a defensible analysis of the facts available at that point in time. Every report must be traceable back to such an analysis. Every decision not to report must be as well.

For organisations looking to test their incident response capability, the real question is not whether the playbook contains the right deadlines. The question is whether it also covers regime mapping, evidential requirements, defined decision points, escalation lines and file-building, and whether the necessary foundations are in place: sound logging and retention, clearly defined roles, and direct access to forensic and legal expertise the moment an incident occurs. That is what makes the difference between an organisation that can choose a defensible course under pressure and one that is already on the back foot in the first few hours. The same applies to the way organisations assess their SOC or MDR capability. That capability should not be judged solely by detection and response times, but also by the extent to which it can support, under pressure, a legally usable factual picture, a clear knowledge status and a defensible evidential record.

We call this broader approach evidence-based resilience: resilience that exists not only on paper, but can be traced at every stage of an incident back to facts, decision points and sources. The aim is not just to comply with reporting obligations, nor just to restore systems. The aim is to ensure that, under time pressure, decisions can always be based on a defensible factual picture. It is only in the combination of forensic depth and legal precision that a reporting process emerges which does what it should under pressure. The real test comes when the facts are still incomplete, reporting deadlines are running, and important decisions cannot wait.

With the self-assessment below, you can test in six steps whether your incident response process is set up to do exactly that.