EU AI Act + DORA Incident Reporting: Unified Playbook for AI System Failures in Dual-Regulated SaaS

Post #1579 in the sota.io EU Cyber Compliance Series

At 14:23 on a Tuesday afternoon, your AI-powered credit scoring service starts returning anomalous outputs. Within minutes, a downstream bank that uses your API as an ICT third-party provider classifies the event as a potential major ICT incident under DORA. At the same time, your AI system has caused a "serious incident" as defined under EU AI Act Art.73. You now have two reporting clocks running simultaneously — to different authorities, with different definitions, on different timelines.

This is the dual-regulation collision that no one prepared FinTech and InsurTech SaaS developers for. DORA and the EU AI Act were designed by different legislative bodies, finalized years apart, and assign oversight to different national authorities. But the incidents they regulate overlap significantly — any AI system failure in a financial context can simultaneously trigger both frameworks.

This guide builds the unified incident response playbook for SaaS teams serving DORA-regulated entities.

Part 1: Understanding the Two Incident Definitions

DORA: Major ICT-Related Incident

Under DORA Art.17, financial entities must classify ICT-related incidents and identify those that qualify as "major." The classification criteria are specified by technical standards from the European Supervisory Authorities (ESAs), examining factors including:

• Clients affected: number of clients impacted and whether services to them were disrupted
• Duration: how long the disruption lasted or is expected to last
• Geographic spread: whether the incident crosses borders or affects multiple member states
• Data loss: whether personal or financial data was compromised
• Criticality of affected services: whether the service is essential for continuity of financial operations
• Reputational impact: potential for damage to the institution's standing or market confidence

For an ICT third-party provider like a SaaS company, the relevant question is whether your service disruption causes a DORA-qualifying major incident at your customer's institution. Under DORA Art.28-30 on ICT third-party risk (covered in the previous post in this series), your customer's contractual arrangements must include notification obligations that let them trigger their own DORA reporting workflow when your service fails.

EU AI Act Art.73: Serious Incident

The EU AI Act uses a narrower but partly overlapping definition. Under Art.73, a "serious incident" means any incident or malfunction of a high-risk AI system that, directly or indirectly, leads to:

• Death of a person or serious harm to a person's health
• Serious and irreversible disruption of the management and operation of critical infrastructure
• Breach of obligations under EU law designed to protect fundamental rights
• Serious damage to property or the environment

For financial AI systems — credit scoring, underwriting, fraud detection, trading algorithms — the "serious harm to a person's health" and "breach of obligations designed to protect fundamental rights" categories are the most likely triggers. A flawed credit decision that leaves someone unable to access housing finance, or a discriminatory AI output that violates GDPR anti-discrimination principles, can qualify.

The Definitional Gap

Neither framework perfectly anticipates the other. A DORA major ICT incident can occur even if no individual person is seriously harmed — a widespread service outage affecting thousands of transactions qualifies under DORA's volume and duration criteria without meeting Art.73's serious incident threshold. Conversely, an AI system that produces a single catastrophic output (a wrong medical risk assessment leading to denial of insurance, causing health harm) may trigger Art.73 without meeting DORA's "major" classification criteria by volume or duration.

The dangerous middle ground is where both apply: a widespread AI system failure affecting many clients across multiple financial institutions. These events are simultaneously major under DORA and serious under the AI Act, but the two frameworks handle them differently.

Part 2: Reporting Timelines — The Collision Map

The practical complexity becomes clear when you lay the two reporting timelines side by side.

DORA Major ICT Incident Timelines (Art.19 + ESA RTS)

DORA Art.19 establishes the initial notification obligation. The ESA technical standards (RTS) specify the detailed timelines:

Initial notification: Within 4 hours of classifying the incident as major (or within 4 hours of becoming aware of a major incident, whichever is earlier)

Intermediate report: Within 72 hours of the initial notification — updated information including root cause analysis progress, client impact figures, and estimated resolution timeline

Final report: Within 1 month of the incident being resolved — full root cause analysis, timeline reconstruction, remediation steps taken, and preventive measures implemented

The initial notification is deliberately minimal — DORA recognizes that institutions cannot have full information within 4 hours. The purpose is to alert the supervisory authority early so they can monitor systemic risk.

EU AI Act Art.73 Serious Incident Timelines

For high-risk AI systems, providers must notify the relevant national market surveillance authority:

Initial notification: Within 2 days of becoming aware of the serious incident

Intermediate report: Within 10 days of the initial notification — including assessment of the incident's cause, impact scope, and immediate mitigation steps taken

Final report: Within 15 days of resolution — complete technical analysis, corrective action plan, and confirmation of system status

At first glance, the AI Act timelines appear more generous — 2 days versus 4 hours for the initial notification. But the 2-day clock starts when the provider "becomes aware" of a serious incident, not when they classify it. In practice, awareness can precede formal classification by hours, compressing the effective window.

Parallel Timeline Scenario

Consider an AI credit scoring system failure on Monday at 09:00:

Your SaaS team must simultaneously support your customer's DORA reporting workflow (by providing technical information about your system failure within hours) while managing your own Art.73 reporting to a different authority on a different calendar.

Part 3: Reporting Authorities — Two Different Supervisory Channels

This is where the dual-regulation complexity becomes organizational rather than just technical.

DORA Reports Go to Financial Supervisory Authorities

Under DORA Art.19, major ICT incident reports are submitted to the relevant financial supervisory authority — which depends on the institution type and member state:

• Banks: national banking supervisor (ECB for significant institutions under SSM, national competent authority for less significant institutions)
• Investment firms: ESMA or national competent authority
• Insurance: national insurance supervisory authority (EIOPA coordinates)
• Crypto-asset service providers (CASPs): national competent authority under MiCA

For cross-border incidents, DORA Art.19 also establishes notification to ENISA and other relevant authorities. The specific routing depends on which member states' institutions are affected.

AI Act Reports Go to Market Surveillance Authorities

Under EU AI Act Art.73, reports go to the market surveillance authority of the member state where the provider is established, or where the incident occurred. Separately, providers must also notify the national competent authority designated under the AI Act — which in most member states is a different body from the financial supervisor.

In Germany: BaFin for DORA, while the AI Act national competent authority is expected to be designated under Art.70 (exact designation varies by member state).

In France: ACPR/AMF for DORA, with ANSSI and other bodies likely designated for AI Act oversight.

The Coordination Gap

No coordination mechanism currently exists between DORA financial supervisors and AI Act market surveillance authorities at the EU level. When an AI system failure triggers both frameworks, two separate investigations can proceed in parallel with no structured information-sharing requirement between the two supervisory channels.

For your SaaS company, this means you could receive information requests from two different regulatory bodies, with potentially overlapping but differently-scoped inquiries, on different timelines.

Part 4: Building the Unified Incident Response Playbook

Given this complexity, dual-regulated SaaS teams need a single incident response procedure that handles both frameworks simultaneously. Here is the architectural approach.

Incident Classification Layer (0–30 minutes)

When an anomaly is detected, your incident response procedure must immediately assess two questions in parallel:

DORA relevance check:

• Is any of our clients a DORA-regulated financial entity?
• Does this incident affect services they use?
• Could the impact qualify as "major" under DORA criteria (client volume, duration, geographic spread)?

AI Act Art.73 relevance check:

• Is the affected system a high-risk AI system under Annex III?
• Is there any indication of personal harm, fundamental rights impact, or critical infrastructure disruption?
• Has anyone been denied a service, received a harmful output, or suffered a consequence?

Both checks run simultaneously. A "yes" to either triggers the corresponding reporting track.

Dual Notification Track (30 minutes – 4 hours)

DORA track (for client notification):

• Notify affected financial entity clients immediately (they need to start their own 4-hour DORA clock)
• Provide technical incident summary: service status, affected endpoints, estimated resolution time
• Assign a dedicated incident liaison for each DORA-regulated client
• Begin technical log preservation for intermediate and final reports

AI Act Art.73 track (for authority notification):

• Identify the market surveillance authority for your jurisdiction
• Prepare initial notification: AI system identification, incident description, preliminary impact assessment
• No final analysis required at 2-day stage — describe what you know and what you don't
• Document the timestamp of "awareness" precisely — this anchors all subsequent deadlines

Evidence Preservation Layer (hours 1–24)

Both frameworks require detailed technical reporting. Preserve simultaneously:

• System logs covering the incident window (including pre-incident baseline)
• API request and response logs for affected endpoints
• Model inference logs if your AI system produces explainable outputs
• Configuration state at time of incident (model version, hyperparameters, input pipeline version)
• Customer impact data (anonymized if containing personal data)
• Communication logs with affected clients

Store evidence in a tamper-evident, timestamped archive. Both DORA and AI Act investigations may require production of this evidence months after the incident.

Intermediate Report Synchronization (72 hours / 10 days)

DORA's intermediate report at 72 hours and the AI Act intermediate report at 10 days are on different timescales. Use the 72-hour DORA deadline as your internal forcing function: the technical analysis needed for DORA's intermediate report is a superset of what you need for the AI Act's intermediate report. Complete the technical root cause analysis once, then adapt the output for each authority's format.

The key difference: DORA focuses on operational impact (client numbers, transaction volumes, service restoration). The AI Act focuses on AI-specific factors (was the model output incorrect? did training data contribute? was human oversight bypassed?). Both narratives come from the same incident data.

Authority Liaison Structure

Designate separate authority liaisons for each regulatory channel:

• DORA liaison: coordinates with client DORA reporting teams and the financial supervisory authority (if you are directly regulated) or manages the information flow to clients who are directly regulated
• AI Act liaison: manages the Art.73 reporting process with the market surveillance authority

Both liaisons share a common technical briefing document but produce regulatory outputs tailored to their respective authority's format requirements.

Part 5: Contractual Prerequisites

The unified playbook only works if your contracts with financial entity clients are properly structured. As covered in our DORA ICT third-party risk post (#1578), DORA Art.30 requires that ICT contracts include specific provisions.

For incident management, ensure your contracts specify:

Notification timelines: Your SaaS commits to notifying clients of major service disruptions within a defined timeframe (typically 1–2 hours of classification, giving them time to meet their 4-hour DORA clock)

Technical information provision: You commit to providing the technical data clients need for their DORA intermediate and final reports

Audit cooperation: You agree to cooperate with supervisory authority investigations arising from your clients' DORA reports

AI-specific provisions: If your service includes high-risk AI systems, contracts should specify that you are the provider for AI Act purposes and responsible for Art.73 reporting — preventing disputes about reporting responsibility when an incident occurs

Part 6: The Information Asymmetry Problem

A structural challenge in the dual-reporting scenario is information asymmetry. Your DORA-regulated clients know their impact (client numbers affected, transaction volumes disrupted) better than you do. You know your system's technical state (model version, error rates, root cause) better than they do.

DORA and the AI Act both assume the reporting entity has comprehensive information, but in a third-party service model, the information needed for complete reporting is split across organizational boundaries.

Resolution: Pre-incident information sharing agreements

Before an incident occurs, establish what information each party will share in real time during an incident:

• Your SaaS → clients: technical status updates every 30 minutes during active incidents, root cause preliminary findings within 4 hours, model behavior logs within 24 hours
• Clients → your SaaS: client impact numbers within 2 hours (needed for DORA severity assessment), geographic distribution of affected clients within 4 hours

This pre-agreed information flow makes both parties' reporting obligations more achievable and reduces the risk of inconsistent accounts being submitted to different authorities.

Part 7: DORA Art.23 — Payment Incidents

For SaaS serving payment service providers, DORA Art.23 adds a separate incident category: operational or security payment-related incidents. These have their own reporting chain through national competent authorities to EBA, rather than following the standard DORA Art.19 major ICT incident pathway.

If your AI system is embedded in payment processing (fraud detection, transaction routing, payment authorization), classify incidents against both Art.17/18 (general ICT) and Art.23 (payment-specific) criteria. Payment incidents may have additional reporting obligations to national payment supervisors even when the AI Act serious incident definition is not met.

Part 8: Avoiding the Dual Reporting Trap

The most dangerous outcome is submitting inconsistent reports to different authorities. If your DORA client's financial supervisor receives a report describing "widespread service disruption affecting 15,000 transactions" while your AI Act Art.73 report describes "a minor output anomaly affecting a small number of requests," the inconsistency becomes a compliance problem in itself.

Prevention requires a single source of truth for incident facts:

• One incident timeline document, updated in real time by a single owner
• All external reports derived from this document, with authority-specific framing but factually consistent
• Legal review of both reports for consistency before submission

The factual record — what happened, when, how many users affected, what the AI system did — must be identical across both regulatory submissions. Only the framing and emphasis differ (operational impact for DORA, AI-specific causation for Art.73).

Summary: The Dual-Regulation Incident Response Checklist

Pre-incident (do now):

• Classify all AI systems by Annex III high-risk category (Art.73 scope)
• Identify all DORA-regulated financial entity clients
• Draft contractual incident notification provisions (DORA Art.30 requirements)
• Establish pre-agreed information sharing timelines with each client
• Designate DORA liaison and AI Act Art.73 liaison (can be same person with written procedures)
• Set up tamper-evident log archiving covering the required evidence categories

During incident (immediate response):

• Run DORA and AI Act relevance checks simultaneously (first 30 minutes)
• Notify affected financial entity clients immediately if DORA-relevant
• Timestamp "awareness" of any potential serious incident precisely
• Start the 4-hour DORA clock from classification, not detection
• Preserve all technical logs from the incident window

Reporting (hours to days):

• Client notification within contractually agreed window (enabling their DORA reporting)
• AI Act Art.73 initial notification within 2 days of awareness
• DORA intermediate report support to clients at 72 hours
• AI Act intermediate report at 10 days
• Single source of truth document reviewed for cross-report consistency before submission
• Final reports (AI Act: 15 days post-resolution; DORA: 1 month post-resolution)

Post-incident:

• Root cause analysis addressing both AI-specific factors and operational factors
• Corrective action plan covering both AI system remediation and ICT controls
• Contract review — did incident reveal gaps in notification or cooperation provisions?
• Update incident response playbook based on lessons learned

Next in this series: Post #1580 will cover the triple compliance challenge for crypto platforms using AI — MiCA CASP obligations, DORA ICT risk requirements, and EU AI Act high-risk classification for AI-powered trading and KYC systems.

Previous posts in this series:

• EU AI Act + DORA FinTech/InsurTech Cross-Compliance Developer Guide — dual compliance mapping
• EU AI Act + DORA ICT Third-Party Risk: AI Model Governance for Dual-Regulated Firms — third-party risk and Art.28-30

sota.io is an EU-native managed PaaS — deploy any language on Hetzner Germany with no US parent, no CLOUD Act exposure, from €9/mo.