Reporting Cyber Security Incidents starts with knowing what happened

Incident response under new EU data and cyber legislation doesn't require five separate checklists, but one evidence-based process.

A joint publication by Lawrence Advocaten and Hunt & Hackett

When a cyber incident occurs, an organization has more important things to worry about than reporting deadlines. The first priority is to understand what is happening, limit the damage, and then restore business operations. Nevertheless, pressure quickly arises from lawyers, regulators, customers, or external advisors: should we report, to whom, and within what timeframe?

This question is understandable, but under the new EU data and cyber legislation, it is too narrow. In recent years, the European regulatory framework for incident response has expanded significantly. In addition to the General Data Protection Regulation ("GDPR"), we now have the Network and Information Security 2 Directive (Directive (EU) 2022/2555; "NIS2"), the Digital Operational Resilience Act (Regulation (EU) 2022/2554; "DORA"), the Artificial Intelligence Act (Regulation (EU) 2024/1689; "AI Act"), and the Cyber Resilience Act (Regulation (EU) 2024/2847; "CRA"). Each regime uses its own definition of a reportable incident, its own reporting deadline, its own supervisory authority, and its own circle of addressees. The simple "72-hour question" assumes that it is clear which regime applies. In the first hours of an incident, this is rarely the case.

After reading, you will know:

• why a single incident can simultaneously fall under the GDPR, NIS2, DORA, CRA, and the AI Act, each with its own deadline and supervisory authority.

• how technical facts determine the legal qualification, and not the internal label you give to the incident.

• why poor logging is not only a technical but also a legal problem: in 86% of Hunt & Hackett's IR investigations in 2025, telemetry was incomplete.

• why a nine-day attack timeline becomes legally relevant, and is only visible if the forensic material is available.

• why certainty is not a prerequisite for reporting, and what regulators expect instead.
  

Good incident response starts with the facts

Organizations that have properly set up incident response do not start with the law and the deadline. They start with the event. What has been observed, which systems have been affected, which data (including possibly personal data) are involved? Only when these facts (or a defensible provisional assessment thereof) are on the table can a legally reliable qualification be made. This makes incident response an integrated technical-legal process. It is no longer "first technical, then legal," or vice versa, but two parallel tracks.

Starting with the event itself also means: at the phase of the event. A ransomware attack where encryption has not yet occurred requires different priorities than an attack where systems have already been encrypted and data may have been exfiltrated. In the first case, the focus is on preventing encryption: isolating infected systems, increasing visibility, and excluding the attacker. In the second case, the focus shifts to identifying the root cause, assessing the damage, recovery, and the question of which data may have been taken outside the organization. These differences in approach partly determine which technical questions must be answered with priority and thus which legal qualifications are defensible at which moment.

One event, multiple legal identities

What is technically one event can legally have multiple identities. A ransomware attack at a managed service provider ("MSP") that processes customer data can be relevant under:

• GDPR — if personal data has been leaked, destroyed, or unlawfully accessed;

• NIS2 — if the MSP qualifies as an essential or important entity;

• DORA — if an affected customer is a financial entity;

• CRA — from September 11, 2026, in the case of an actively exploited vulnerability in a product with digital elements;

• AI Act — in the event of a serious incident involving a high-risk AI system within the meaning of Article 3, point 49.

Which regime applies depends on the facts. Not on the label the organization internally gives to the incident. An incident that is internally seen as "a malfunction" can have a completely different status under the GDPR, NIS2, DORA, or the CRA. This is why the first legal step is not to assign a deadline, but to identify possible regimes.

From a technical perspective, the same applies. The response differs per incident type:

• Ransomware requires immediate isolation of infected systems, broad and as complete as possible visibility through monitoring, and a root cause analysis to understand the extent and limit further damage.

• Espionage is typically creeping and long-term, and requires a cautious response that does not alert the attacker.

• Business email compromise has a narrow but potentially large direct financial impact.

• A data breach can be both visible and hidden.

• A supply chain attack has a systematic character, where the question of who owns the problem is complex.

These technical differences are inseparable from the legal qualification: the nature of the incident partly determines which facts must be technically established, and which reporting thresholds are met.

That this is not an abstract problem is evident from Hunt & Hackett's data. The 2026 Trend Report is based on more than 54,000 security incidents investigated in 2025 by Hunt & Hackett's Security Operations Center (SOC) and Incident Response team. Within the incident response investigations specifically, 71% of incidents were financially motivated, with ransomware (43%) and business email compromise (29%) as dominant types. What Hunt & Hackett observes is that identity-based intrusions have evolved into a leading attack pattern. According to IBM data from 2025, this accounts for approximately 30% of global breaches. Beneath this lies a shift that is significant for legal qualification: from perimeter to identities, from encryption to data theft, and from paper compliance to demonstrable resilience. This same shift is reflected in the reporting landscape: from one reporting obligation to multiple supervisory authorities that appear in parallel and with their own deadlines.

The forgotten first step: regime scan

In a well-designed incident response playbook, every reporting decision is preceded by a brief legal horizon scan. Not to immediately determine which regime applies (which is often not possible in the first hours), but to prevent a relevant reporting track from coming into view too late. The question is always: given what we are currently observing, which laws could potentially come into play?

A practical regime scan starts with three axes:

In practice, the regime scan at the first step already encounters a recurring problem: organizations often do not know exactly which systems and data they manage, which business processes depend on them, and under which regime they fall. This lack of insight is not due to unwillingness, but because it has never been systematically built up. The consequence is that the regime scan in the initial phase of an incident takes more time than necessary and relevant reporting tracks come into view too late.

Each regime also has its own supervisory authority. Authorities exchange information on some points, but this does not relieve the correct legal entity within the group of its own reporting obligation. A single report to a single counter is not automatically sufficient. Anyone who reports to the wrong counter, or fails to report because another regime seemed applicable, does not fulfill their obligation under the other regime.

Forensic facts determine the legal qualification

A legal qualification can only be made with some certainty if sufficient technical facts are available. Forensic investigation provides several key insights for this:

• a timeline of detection, access, and any further spread through the network (lateral movement);

• a scope of affected systems, accounts, and data categories;

• an informed estimate of what has been viewed, copied, encrypted, or exfiltrated;

• a knowledge status that explicitly states what has been established, what is plausible, and what is still open.

How this looks in practice can be illustrated by what Hunt & Hackett typically sees in ransomware incidents. Isolation of involved systems and accounts ideally takes place as quickly as possible and in any case within one to three hours after detection. The first scope assessment and initial root cause analysis run for at least the first twenty-four hours. A full root cause analysis usually takes two to eight days for the first eighty percent of findings; the remaining twenty percent can take up to twenty-five days.

These technical timelines thus cut across the legal reporting deadlines: a NIS2 early warning must be given within twenty-four hours, an incident report within seventy-two hours, while the forensic investigation is still ongoing. This is not a friction that can be avoided. It is precisely why working with evidence-based provisional qualifications is not a makeshift solution, but the standard operating procedure.

These facts then determine the legal qualification. Is there a personal data breach, a significant incident involving an essential or important entity, a serious ICT incident, a serious incident involving a high-risk AI system, or an actively exploited vulnerability in a product with digital elements? Multiple qualifications simultaneously are more the rule than the exception.

In all cases, the supervisory authority wants not only a conclusion but a factually substantiated basis for a report. A report without a technical foundation is vulnerable: it raises questions, makes follow-up more difficult, and can be challenged retrospectively. A failure to report without a documented, substantiated reason not to report is equally vulnerable.

Forensic work provides input for legal qualification from the outset. At the same time, legal triggers provide input for the forensic scope from the outset: which questions must be answered with priority, which log sources must be secured, what timeline precision is needed to account for deadlines? The questions posed by legal teams (was there unauthorized access, was there exfiltration, was there lateral movement, when did the incident begin, when was there sufficient knowledge, what is the scope) are the same questions posed by forensic teams, but with a different end goal. Good incident response aligns these two levels of discussion.

How heavily this coordination problem weighs in practice is again shown by the figures from Hunt & Hackett. In 86% of their incident response investigations in 2025, detection and investigation were hampered by incomplete telemetry (missing audit logs, too limited log retention, or systems outside the monitoring scope).

A concrete example of this is an incident where Hunt & Hackett was called in after a ransomware attack at a company. The attacker claimed to have stolen data. Forensic investigation found no direct traces of exfiltration, but the absence of network data made a definitive conclusion impossible. The advice was: assume possible data loss, monitor for publication of the data, and carry out the required legal and supervisory reports. Not because exfiltration had been proven, but because the forensic evidence was missing to rule it out. This is precisely the situation where a report cannot wait for certainty and where the quality of logging determines how defensible the reporting decision is in retrospect.

This directly affects the organization's legal position. Anyone who cannot reconstruct what happened also cannot substantiate why a report was or was not made, or why an earlier qualification was adjusted retrospectively. The evidentiary file on which the report rests is contained in the same log sources that must also support the forensic analysis.

Where forensic investigation and legal work meet

The cooperation between forensic investigation and legal assistance takes its sharpest form at the moment of reporting itself. The forensic team reconstructs what happened, safeguards the technical reliability of the facts, and translates new findings into possible consequences for scope, impact, and earlier assumptions. The legal team translates this factual picture into concrete reporting obligations, handles contact with the supervisory authority, chooses the correct legal basis and authority, and monitors the cadence of early warning, incident reporting, interim report, and final report, without the communication becoming too assertive or too vague. Neither role can replace the other at the moment of reporting, and neither can build a defensible position against the supervisory authority under time pressure without the other.

Experience is paramount here. Teams that have frequently managed incidents under supervisory pressure know which questions typically arise early on: what is certain, what is plausible, what is still unknown, what measures have been taken, and when will additional information follow? This experience prevents an initial report from being too definitive, too vague, or technically insufficiently substantiated. The same applies on the forensic side. The quality of incident response often becomes apparent when not all facts are known yet. At that point, decisions must be made about containment, evidence preservation, investigation priorities, and communication, all while the investigation is ongoing. Experience helps to make these choices proportionally while also allowing room for new insights as the factual picture evolves.

The Jungle of Deadlines

The law demands speed. But the most difficult question is often not which deadline applies, but when that deadline begins. The GDPR looks at the moment of becoming aware of the breach. NIS2 works with the awareness of a significant incident. DORA links the initial notification to classification as major and to the moment the entity became aware of the incident. The AI Regulation looks at establishing a causal link, or its reasonable probability, between the AI system and the serious harm.

Precisely for this reason, an accurate incident timeline is not a technical detail, but crucial legal information.

How this precision with timelines works in practice can be illustrated by two incidents that Hunt & Hackett assisted with. In the first case, a Dutch organization was informed about a breach where the attacker had already achieved the highest privilege level and was actively spreading further through the network. The moment of detection was thus not the moment of initial access, and that difference is legally relevant: when did the incident begin, when was there "sufficient" awareness, and from what moment did the reporting deadline start? In the second case, forensic investigation reconstructed an attack timeline of nine days between initial access and ransomware rollout: nine days during which the attacker was active, and whose existence only became visible thanks to available forensic material.

Anyone who cannot document when awareness, detection, classification, or the establishment of a causal link occurred, also cannot substantiate why a report was made on time or not on time.

At the same time, the factual picture is, in most cases, far from complete. Logs have not all been collected, EDR data is still being correlated, IAM events are still being reconstructed, exfiltration hypotheses are still being tested. This is the core tension of modern incident response. Anyone who cannot forensically determine what happened, cannot reliably determine what needs to be reported from a legal perspective. But waiting too long for complete certainty can mean being too late.

The solution is not to wait for certainty. A provisional notification can be explicitly required under various regimes before the forensic investigation is completed. The solution, therefore, is to work with evidence-based provisional qualifications. An organization must, even with an initial report, be able to explain: this is what we knew at that moment, this is what we did not yet know, these were our assumptions, these were the open research questions, and therefore, we reported or did not report in this manner. Subsequent notifications and interim reports are precisely intended to supplement a provisional factual picture and, where necessary, adjust earlier qualifications.

The ex-post assessment will not be whether the organization 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 became known. This is a lower bar than perfection, and at the same time a higher bar than simply meeting a deadline.

From Five Checklists to One Integrated Process

The resulting model is simple in design but demanding in execution:

In the first step, the security team determines what has been observed. In the second step, legal or compliance maps out which legislation might be relevant given that observation. In the third step, forensic experts provide an initial factual picture, explicitly marking what has been established, what is plausible, and what is still open. In the fourth step, legal performs the legal qualification and determines which reporting obligations are triggered. In the fifth step, the report is made to the correct authority, in the correct form, within the correct deadline. In the sixth step, the evidence file is built up to reconstruct decision-making retrospectively and, where necessary, defend it.

This is not a linear process. Steps three to six constantly intertwine. New forensic facts lead to updated legal qualifications, which in turn can trigger new reporting obligations or update existing reports. This is why a common incident language between security and legal teams is so important: forensic findings must be articulated in a way that is legally interpretable, and legal triggers must be translated into concrete research questions. Those who keep the two levels separate will fall behind under time pressure.

From an incident response perspective, forensic investigation and reporting to supervisors always run parallel in this process flow. Initial root cause analysis, forensic investigation, and initial reporting occur simultaneously, not sequentially. And even after the acute phase, the evidence file remains active: supervisory reporting and legal review are not the conclusion of the incident, but an ongoing track that is based on the same forensic findings that also guide recovery.

In Conclusion: Reporting Starts with Knowing What Happened

Under the new EU data and cyber legislation, incident response is not an administrative act where technology first works and then legal writes a report, or vice versa. It is an integrated process in which forensic investigation and legal qualification run in parallel from the start, with the same event as a common starting point and the same evidence file as a common outcome.

Reporting, therefore, does not begin with a deadline. It begins with a defensible analysis of the facts available at that moment. Every report must be traceable to such an analysis. Every non-reported incident must also be traceable.

The question for organizations wishing to test their incident response is therefore not whether their playbook contains the correct deadlines. The question is whether the playbook also includes regime-mapping, evidence requirements, defined decision-making moments, escalation lines, and file building, and whether the preconditions for this are in place: logging and retention in order, roles defined, and direct access to forensic and legal expertise available when an incident occurs. That is what makes the difference between an organization that can choose a defensible course under time pressure, and an organization that is already behind in the first hours.

This also applies to how organizations assess their SOC or MDR capabilities. These capabilities should not only be measured by detection and response time, but also by the extent to which they can support a legally usable factual picture, an explicit knowledge status, and a defensible evidence file under time pressure.

We call this broader approach evidence-based resilience: resilience that does not only exist on paper, but can be traced back to facts, decision points, and sources at every stage of an incident. The goal is not only to comply with reporting obligations, and not only to restore systems. The goal is to always be able to base decisions under time pressure on a defensible factual picture. Only in the combination of forensic depth and legal precision does a reporting process emerge that does what it needs to do under pressure. The real test follows when the factual picture is still incomplete, reporting deadlines are approaching, and important decisions cannot wait. With the self-assessment below, you can check in six steps whether your incident response process is set up for this.

Step 1 → Event: what was observed?

Can your security team provide a reliable initial picture within the first few hours?

• We can quickly determine which systems were affected and in what order

• Our logging and telemetry are sufficient to reconstruct an initial attack timeline

• We know which systems fall outside our monitoring scope

• We can distinguish the type of incident at an early stage — ransomware, data theft, BEC, espionage — because the response differs by type

• From the outset, we document what has been established, what is plausible, and what is still open

• We can determine within 24 hours which internal and external stakeholders need to be involved in decision-making

Step 2 → Possible Regimes: which legislation comes into play?

Does your legal or compliance team conduct a regime scan before a reporting decision is made?

• We know which EU regimes our organization falls under: GDPR, NIS2, DORA, CRA, and/or AI Act

• For every incident, we perform a brief horizon scan across three axes: data, services, and technology

• We know which supervisory authority belongs to which regime

• We understand that one incident can have multiple legal identities and act accordingly

• We have mapped which systems, business processes, and data categories fall under which regime

Step 3 → Forensic Facts: what actually happened?

Does your forensic investigation provide a factual picture that is legally interpretable?

• We have direct access to forensic expertise when an incident occurs

• During an ongoing incident, we can determine investigation priorities without losing sight of the continuity of containment and recovery.

• We can perform an initial root cause analysis while containment is still ongoing

• For each finding, we explicitly determine what is certain, what is plausible, and what is still open

• We can reconstruct when initial access occurred, separate from the moment of detection

Step 4 → Legal Qualification: which reporting obligations are triggered?

Can your legal team make a defensible legal qualification based on the forensic factual picture?

• Our legal and forensic teams use a common incident language

• We work with evidence-based provisional qualifications and do not wait for complete certainty

• We understand the difference between reporting deadlines per regime and know when they begin

• Legal triggers are translated into concrete forensic research questions and vice versa

• We have defined decision-making moments for the first 4, 24, and 72 hours

Step 5 → Notification(s): to the correct authority, in the correct form, within the correct deadline

Is your reporting process set up for multiple parallel reporting tracks?

• We have determined in advance who is authorized to make reporting decisions

• We know how to distinguish between an early warning, an incident notification, and a final report

• We can make a technically substantiated report while the forensic investigation is still ongoing

• We have defined escalation lines that activate forensic and legal expertise from the very first hour

• We have previously practiced drafting a report under time pressure

• We actively monitor the cadence of follow-up notifications and interim reports

Step 6 → Evidence File: can decision-making be reconstructed retrospectively?

Do you build the file during the incident that allows you to account for your actions retrospectively?

• We actively build an evidence file during an incident, not afterwards

• Our file contains an explicit knowledge status for each decision-making moment: what we knew then, what we didn't know, and why

• We can account for why a report was or was not made at a certain time

• Forensic findings and legal qualifications are kept in the same file

• Supervisory reporting and legal review are treated as an ongoing track, not as a conclusion of the incident

 

What do the results say?
The checklist is not a final judgment. It shows where the incident response process is solid and where it is likely to come under pressure due to time constraints.

Are checkboxes missing mainly in step 1, 3 or 6?
The technical foundation deserves attention. Think of logging, retention, forensic capacity, and the quality of the initial factual overview. These are the building blocks that determine how defensible your position is when a supervisor asks questions.

Are checkboxes missing mainly in step 2, 4 or 5?
The legal calibration deserves attention. Think of regime mapping, reporting thresholds, and whether the escalation lines activate the right expertise quickly enough.

Are checkboxes missing across multiple steps?
Then technology and legal aspects are not in sync, and that is precisely the situation in which organizations get out of step under pressure.

Do you want to know if your assessment is correct?
Hunt & Hackett and Lawrence Advocaten are happy to assist you.