SkarpChapter 3 of 6
Report or Hold? Classifying Incidents Across Overlapping EU Regimes
Students will be able to apply a multi-regime classification matrix and produce a reasoned notification decision that records facts, uncertainty, thresholds, awareness times, and reassessment triggers.
1. Start with the incident, not the statute
One event, multiple tests
A technical incident is the factual object. Each regime applies its own legal threshold. The correct output is often several coordinated decisions, not one universal answer.
Separate the questions
For each regime, record the protected interest, threshold, awareness time, deadline, recipient, and reassessment trigger. Do not let a low impact under one regime control another.
Current timing checkpoint
DORA has applied since January 17, 2025. CRA vulnerability and severe-incident reporting applies from September 11, 2026; broader CRA application is generally December 11, 2027.
2. Build the classification matrix
The matrix fields
Use the same factual chronology, but record a distinct trigger, threshold, awareness time, deadline, recipient, evidence basis, and reassessment trigger for each regime.
Do not cross-import thresholds
A conclusion under GDPR does not decide NIS2. A lack of confirmed exfiltration may affect GDPR risk, while service disruption may independently satisfy NIS2 or DORA.
NIS2 significance
NIS2 focuses on severe operational disruption, financial loss, or considerable damage. Implementing Regulation 2024/2690 adds specified criteria for covered entity types and recurring incidents.
3. Apply NIS2 significance as a capability test
Three impact categories
Separate confirmed impact, credible potential impact, and unsupported possibility. NIS2 can be triggered by capability, but capability must be connected to the affected systems and facts.
Access can be enough
For specified NIS2 entities, malicious unauthorised access capable of causing severe operational disruption may satisfy significance even before an outage occurs.
Recurring incidents
Under Regulation 2024/2690, linked incidents may be aggregated when they occur at least twice within six months, share an apparent root cause, and collectively meet the stated financial-loss criterion.
4. Worked example: one outage, two different risk questions
The factual core
A credential attack causes a cross-border routing outage from 10:00 to 13:00, with delayed dispatch until 18:30. The same event also involves systems containing delivery and contact data.
NIS2 decision
Cross-border unavailability and operational dependency support reporting based on severe disruption. NIS2 reporting is staged: 24-hour early warning, 72-hour incident notification, and a later final report.
GDPR decision
Assess confidentiality, integrity, and availability of personal data, then the likelihood of risk to individuals. Authority notification and communication to individuals use different thresholds.
5. Conduct the GDPR risk assessment without waiting for certainty
Two GDPR thresholds
Authority notification turns on whether risk is unlikely. Communication to individuals generally requires likely high risk. These are separate decisions and should not be collapsed.
Assess before certainty
Use the nature of data, affected population, identifiability, consequences, likelihood, and mitigation. A pending forensic answer is not a reason to suspend the initial assessment.
Record uncertainty
State what is known, what is inferred, and what remains unknown. Use a reasoned risk range and identify the fact that would move the assessment to a different conclusion.
6. Classify DORA incidents by criticality and materiality
DORA's centre of gravity
DORA asks whether the incident has a high adverse impact on systems supporting critical or important functions. Classification uses clients, transactions, duration, geography, data loss, service criticality, and economic impact.
Classification before reporting
First identify the affected function and apply the classification procedure. A major-incident conclusion starts the special reporting clock; do not confuse technical detection with DORA classification.
DORA timing
The initial report is due as early as possible, within four hours of major classification, and no later than 24 hours after awareness. Intermediate and final reports follow under Regulation 2025/301.
7. Worked example: a payment authentication failure
Facts
Authentication failures affect 18% of customers in three Member States for seven hours. Payments fail and reconciliation is delayed, but no exfiltration is currently identified.
DORA outcome
Assess the critical payment function, affected customers, transaction volume and value, duration, geography, data integrity, and economic impact. A major incident may exist without confidentiality loss.
GDPR outcome
Do not assume a GDPR report follows from DORA. Establish whether personal data was breached and whether the breach is likely to risk individuals. Reassess if logs or credentials were exposed.
8. Recognise CRA triggers at the product level
CRA's trigger
The CRA focuses on the manufacturer's product: an actively exploited vulnerability or a severe incident affecting the product's security. The manufacturer's service availability is not the only relevant fact.
Current CRA dates
As of September 29, 2026, CRA reporting for actively exploited vulnerabilities and severe incidents applies. Most other CRA requirements generally apply from December 11, 2027.
Staged CRA reporting
Vulnerability reporting uses 24-hour, 72-hour, and corrective-measure-plus-14-day stages. Severe-incident reporting uses 24-hour, 72-hour, and one-month stages.
9. Make the report-or-hold decision
Use this decision exercise for every regime:
Report now when: the current evidence satisfies the legal threshold, or the regime expressly captures credible capability or active exploitation, and delay would risk missing the deadline.
Hold with documented monitoring when: the threshold is not met on current evidence, the uncertainty is material, and a defined fact-gathering action can resolve it quickly without allowing the deadline to expire.
Never use "hold" to mean "do nothing." A no-report decision should contain:
- The precise threshold considered.
- The facts supporting and opposing notification.
- The awareness time used and why.
- The evidence unavailable at decision time.
- The person who approved the decision.
- The next review time.
- The event that reopens the decision.
Example reassessment triggers include confirmation of exfiltration, discovery that a critical function was affected, a second linked incident, identification of additional Member States, a product exploit confirmed in the wild, or losses crossing a specified threshold.
A useful legal formulation is: "No report at 14:00 on the present record; reassess at 18:00 or earlier upon confirmation of unauthorised access, material service degradation, or affected-person risk." That is a controlled decision, not regulatory indecision.
10. Check your classification logic
Choose the best answer. The question tests whether you can keep overlapping thresholds separate while preserving a defensible reassessment record.
A financial entity suffers a seven-hour payment outage across three Member States. No exfiltration is currently identified. What is the best immediate legal approach?
- Classify under DORA based on critical-function impact and operational materiality, while conducting a separate GDPR assessment and recording reassessment triggers.
- Do not report under any regime because there is no evidence of data exfiltration.
- Report only under GDPR because payment records are personal data.
Show Answer
Answer: A) Classify under DORA based on critical-function impact and operational materiality, while conducting a separate GDPR assessment and recording reassessment triggers.
DORA classification is based on operational and financial impact, service criticality, affected clients and transactions, duration, geography, data losses, and economic impact. Lack of known exfiltration does not eliminate a DORA reporting duty. GDPR must be assessed separately against the personal-data-breach and individual-risk thresholds.
Key Terms
- awareness time
- The documented point at which the relevant entity has sufficient information to reasonably conclude that a legally relevant incident or breach has occurred.
- personal data breach
- A breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data.
- reassessment trigger
- A defined fact or event that requires an earlier or renewed classification decision, such as confirmed exfiltration, expanded outage, additional jurisdictions, or a crossed materiality threshold.
- significant incident
- Under NIS2, an incident that has caused or is capable of causing severe operational disruption, financial loss, or considerable material or non-material damage.
- major ICT-related incident
- Under DORA, an ICT-related incident with a high adverse impact on systems supporting a financial entity's critical or important functions.
- documented no-report decision
- A contemporaneous record explaining why a reporting threshold was not met, what uncertainty remained, who approved the decision, and when or upon what facts it must be revisited.
- actively exploited vulnerability
- A vulnerability in a product with digital elements that is being exploited by a malicious actor and therefore triggers the CRA reporting framework when the manufacturer becomes aware.