Why AI Incidents Now Trigger Multiple Legal Regimes
If you're a CISO at a mid-market bank and your AI credit scoring engine goes down, you don't have one regulator to call. You might have four. The EU AI Act requires serious incident reporting to the market surveillance authority. DORA requires major ICT incident reporting to your financial supervisory authority within hours. NIS2 requires early warning to your national CSIRT within 24 hours. And if personal data was compromised, GDPR adds the data protection authority within 72 hours. Same event. Four different clocks. Four different authorities. Are you set up for that?
I've watched mid-market compliance teams discover this overlap for the first time during a tabletop exercise. The usual reaction is a long silence followed by "we're not ready for this." That's the honest answer for most organisations right now.
Are You Simultaneously in Scope of AI Act, DORA and NIS2?
Not every organisation faces all three. But more do than you'd expect. Here's a quick scoping check.
| Organisation Type | EU AI Act | DORA | NIS2 | GDPR |
|---|---|---|---|---|
| Bank / insurer using AI for credit or underwriting | YES Annex III | YES | LIKELY if essential entity | YES |
| Critical infrastructure operator using AI | YES if high-risk AI | NO (non-financial) | YES | YES |
| SaaS / cloud provider serving financial sector | IF AI | YES if CTPP | YES digital infrastructure | YES |
| Hospital / health system with AI diagnostics | YES Annex I/III | NO | YES healthcare entity | YES |
Key insight: Financial institutions using AI for credit, underwriting, or fraud detection are the most likely to face all three simultaneously. For a detailed financial services mapping, see the Financial Services AI Stack Guide.
What Counts as an "Incident" Under Each Law?
This is where it gets messy. The three frameworks use different definitions of what constitutes a reportable incident, with different severity thresholds and different examples.
| Framework | Incident Definition | Severity Threshold | Example |
|---|---|---|---|
| EU AI Act (Art. 62) | Serious incident involving high-risk AI or GPAI with systemic risk | Causes or likely to cause serious harm to health, safety, or fundamental rights | AI credit scoring model systematically denying loans to a protected group |
| DORA (Art. 19) | Major ICT-related incident affecting service, data, or operations | Significant impact on service availability, integrity, or confidentiality | AI scoring engine outage causing 48-hour disruption to lending services |
| NIS2 (Art. 23) | Significant incident affecting network and information system security | Significant impact on provision of services, financial loss, or affected persons | Ransomware attack compromising the AI model infrastructure |
| GDPR (Art. 33) | Personal data breach | Breach of personal data likely to result in risk to rights and freedoms | AI training data leak exposing customer financial records |
How the 4-Hour, 24-Hour, 72-Hour and "As Soon as Possible" Clocks Interact
The biggest operational risk isn't missing one deadline. It's sending inconsistent facts to different authorities because your teams aren't coordinated. Here's the timeline stack.
! DORA: 4 hours — Initial report for major ICT incidents at financial entities
Report to your national financial supervisory authority. Clock starts when the incident is classified as major.
! NIS2: 24 hours — Early warning for significant incidents
Early warning to your national CSIRT. Must indicate whether the incident is suspected to be caused by unlawful or malicious acts.
! DORA: 24 hours — Intermediate report with updated details
Update to financial supervisory authority with initial assessment and impact.
! EU AI Act: "Without undue delay" — Serious incident report
Report to national market surveillance authority. No fixed hour deadline, but "without undue delay" means as soon as you've identified the incident as serious.
! NIS2: 72 hours — Full incident notification
Full notification to CSIRT with assessment of severity, impact, and indicators of compromise.
! GDPR: 72 hours — Personal data breach notification
Notify DPA if personal data was breached and risk to individuals exists.
→ DORA: 72 hours — Final report. NIS2: 1 month — Final report.
Close out with root cause analysis and remediation measures.
Timeline stack: how DORA, NIS2, EU AI Act and GDPR incident reporting deadlines interact for a single AI system failure.
One Process for AI Incidents Across All Three Frameworks
Running three separate processes isn't realistic for a mid-market compliance team. Here's a 7-step unified SOP that produces compliant outputs for all frameworks from a single internal incident record.
Step 1: Detect and Classify
Is this an AI-related incident? Use the AI Incident Log tool to record it immediately. Don't wait for full analysis before creating the record.
Step 2: Triage Frameworks
Which of AI Act, DORA, NIS2, and GDPR apply? Run the scoping matrix above against your organisation type and the incident characteristics. This takes 5 minutes, not 5 hours.
Step 3: Start Unified Incident File
Create a single internal incident record that serves as the source of truth for all frameworks. One record, multiple outputs. Don't create separate files for each regulator.
Step 4: Hit the Strictest Timer First
If you're a financial entity under DORA, the 4-hour initial report comes first. Then NIS2 24-hour early warning. Then AI Act "without undue delay." Cascade, don't serialise.
Step 5: Coordinate Ongoing Updates
Schedule updates harmonised across regimes. DORA 24-hour intermediate, NIS2 72-hour notification, GDPR 72-hour breach report. Use the same facts across all submissions to avoid inconsistency.
Step 6: Root Cause with AI-Specific Analysis
Ensure your root cause analysis captures AI-specific elements: bias in training data, model drift, oversight failure, data quality issues. These are mandatory for AI Act Article 62 reporting but also strengthen your DORA and NIS2 reports.
Step 7: Final Reports and Learning
One internal post-mortem mapped to all frameworks. Feed findings back into your risk register and governance framework. Update your AI risk management system per Article 9.
Which EU AI Compass Tools Plug Into Your Incident Playbook
| Playbook Step | Tool | Purpose |
|---|---|---|
| Detect & classify | High-Risk AI Classifier | Confirm AI system risk class |
| Record incident | AI Incident Log | Single source of truth for all frameworks |
| Assess deployer obligations | Deployer Self-Assessment | Check which deployer duties apply |
| Assess rights impact | FRIA + DPIA Wizard | Combined fundamental rights and data protection assessment |
| Update risk posture | AI Risk Register | Track and update risk status post-incident |
| Align frameworks | ISO/NIST Gap Analyzer | Map controls across governance frameworks |
Top 5 Ways Cross-Regulation Incident Management Fails
Reporting AI incidents only through GDPR
Teams default to the framework they know. DPOs report to the DPA but forget the market surveillance authority (AI Act) and the CSIRT (NIS2). The incident is formally unreported under two frameworks.
Under-reporting to NIS2 because it's "just AI"
An AI model failure isn't seen as a cybersecurity incident, so nobody triggers NIS2 early warning. But if the AI runs on compromised infrastructure or the failure affects service availability, NIS2 applies.
Uncoordinated facts across frameworks
The DORA 4-hour report says one thing. The NIS2 72-hour report says something slightly different because a different team wrote it. Regulators compare notes. That inconsistency becomes a finding.
No clear owner for cross-framework coordination
The CISO owns NIS2. The DPO owns GDPR. Nobody owns AI Act. DORA falls to IT risk. Without a single incident coordinator, the four processes diverge immediately.
Treating vendor incidents as "not our problem"
Your AI vendor's infrastructure fails. Under all three frameworks, the deploying entity must still report. You can't defer by pointing to your vendor's incident management.
Related guides: For full deployer obligations, see the High-Risk AI Deployer Guide. For the financial services regulation stack, see Financial Services AI Stack. For governance framework mapping, see ISO 42001 / NIST AI RMF Mapping.
FAQ: AI Act, DORA and NIS2 Incident Reporting
If an AI credit scoring system fails, which frameworks do we report under?
Does every AI system outage trigger the EU AI Act?
How do we handle vendor incidents where AI is embedded in a third-party tool?
Can we use one incident report for all three frameworks?
Which reporting deadline takes priority?
When did DORA and NIS2 become enforceable?
Need a Cross-Regulation Incident Playbook for Your Team?
E2 Workshop ($999): custom cross-regulation incident playbook session for financial and critical infrastructure clients. Advisory from $4,999.
View Workshops & Advisory →Disclaimer & Limitations
This guide is for educational and informational purposes only. It does not constitute legal or regulatory advice. EU AI Compass tools are educational aids, not certified compliance instruments. Consult qualified legal counsel before making compliance decisions. Move78 International Limited is not a law firm. All regulatory references are accurate as of the publication date based on eu-ai-rules-engine v2.4. NIS2 transposition status varies by member state. The Digital Omnibus is a proposal, not enacted law.