DORA — Digital Operational Resilience
Meridian Payments — Monday, 9:47 AM — Month-End
An interactive scenario about a critical vendor outage, the 4-hour reporting clock, and what happens when the CEO is on a plane and the regulator is on the line.
4-hour window. CEO unreachable. The regulator is waiting.
All languages available in the full course
Head of Compliance at Meridian Payments — a mid-size EU payments firm processing €2.3 billion annually. DORA-regulated. 850 employees.
It's 9:47 AM on the last business day of the month. Your critical cloud provider's status page just turned amber.
This is a choose-your-own-adventure scenario. You’ll face three real decisions that a DORA compliance officer encounters during a major ICT incident — and your choices shape how the story unfolds.
The 4 Stakeholder Bars (top right)
Each bar starts at 50%. Your decisions shift them. There’s no perfect answer — only trade-offs.
Score Toasts
After each choice, a flash shows the impact — e.g. +3 Regulator | -1 Vendor. Watch for these to understand trade-offs in real time.
Legal References
Article references appear throughout — click them to read the relevant DORA article.
It's month-end. 14,000 merchant settlements are queued. Your largest client — NatAlliance Bank, processing €180M today — has an SLA that triggers penalty clauses at 99.5% uptime. You're already below that. And now their head of merchant operations is waiting for your answer.
It's 9:47. The call is still on hold. Your coffee is cold.
"Jordan, it's worse than I thought. CloudVault's EU-West region is having a major issue. Their status page says 'investigating' but I've been on hold with their support for 20 minutes."
"Payment processing is down to 40% capacity. The settlement queue is backing up. If this isn't resolved in the next hour, we'll miss the month-end window for 8,000 merchants."
You "What about failover?"
Emma "I can failover to EU-Central. Forty-five minutes down, maybe more. But Jordan — that's twelve million in mid-flight payments. If even one of those belongs to a retail bank running direct debits right now — and NatAlliance just called you — that's real people bouncing rent payments. Fatima Khoury's payroll is probably in that queue."
Your phone buzzes. A text from David Chen, your CEO, sent before his flight: "Month-end is clean, right? Singapore board presentation depends on it. Don't let anything blow up while I'm in the air." He's now unreachable for 10 hours.
Answer three questions to classify the CloudVault outage. Each question corresponds to an Art. 17 materiality criterion.
Q1. Has a critical IT service been disrupted for more than 2 consecutive hours during business hours?
Your monitoring shows 14,000 merchants affected. Payment processing at 40% capacity. €180M in month-end settlements at risk. The question on your desk: how serious is this?
Emma thinks it's CloudVault's problem. The status page says "investigating." You have incomplete information — but the queue is growing by the minute.
Do you classify this as a major ICT-related incident?
"This is a major incident. 14,000 merchants, €180M in settlements, critical payment function below threshold. I'm classifying it now and starting the notification process."
Emma "Jordan, it might resolve in 20 minutes. CloudVault has had blips before. If you file a major incident report and it turns out to be nothing, we look like we overreacted."
You "If it resolves in 20 minutes, I update the report. If it doesn't and I haven't classified it, we're explaining to the regulator why we waited. Which conversation would you rather have?"
You open the incident management platform and log the classification. The 4-hour notification window starts now: 10:15 AM. Deadline: 2:15 PM.
Under Article 17, financial entities must classify ICT-related incidents as "major" based on criteria including: the number of clients affected, the criticality of services impacted, and the duration. The RTS (EU) 2024/1772 sets specific thresholds — e.g. >10% of clients or >€100M in affected transactions. Early classification costs nothing. Late classification creates a gap between "when you knew" and "when you acted" that regulators will scrutinise.
Emma's assessment: "It's definitely CloudVault. Their EU-West storage layer failed. They're restoring from backups. ETA: unknown."
You classify it as major at 11:17 AM. The 4-hour window starts now. Deadline: 3:17 PM.
But the incident started at 9:47. When Dr. Rossi asks "when did you become aware?", the answer is 9:47. When she asks "when did you classify?", the answer is 11:17. The gap is 90 minutes.
"Why did it take you 90 minutes to determine that 14,000 affected merchants and €180M in at-risk settlements constituted a major incident?"
DORA requires classification "as soon as the incident is detected." The 4-hour notification clock under Article 19 starts from classification — but the regulator's timeline starts from awareness. A 90-minute gap between detection and classification becomes the first question in any supervisory review: "What were you doing during that gap?" Waiting for certainty is understandable but not what the regulation requires.
The incident hasn't resolved. It's gotten worse. Payment processing is now at 15% capacity. Three merchant clients have escalated. Your largest client's SLA breach penalty is now active: €50,000 per hour.
You reclassify to major at 11:47. The 4-hour window starts at 11:47. Deadline: 3:47 PM.
At 11:22, Fatima Khoury in Rotterdam calls her bank. She runs a 12-person logistics company. Her payroll settlement didn't process. Twelve people expecting their salary today won't get it. She's been on hold for 40 minutes. Nobody can tell her why.
The regulator will see the timeline. 9:47 to 11:47 — two hours of a critical payment function being degraded before classification. Under Article 17, classification should happen "as soon as the incident is detected." Two hours isn't "as soon as."
Article 17 requires classification "as soon as the incident is detected." Two hours of a critical payment function at 15% capacity — while 14,000 merchants cannot process — is well beyond any reasonable interpretation of "as soon as." Under Article 19, the 4-hour notification window starts from classification, but the regulator will reconstruct the full timeline from detection (9:47) to classification (11:47). That 2-hour delay is now a documented compliance failure.
Under DORA Article 17, financial entities must classify ICT incidents as major or not major. The RTS (EU) 2024/1772 sets specific thresholds: number of clients affected, criticality of service, geographic spread, duration, and data impact.
Before you face a live incident, practise classification on six scenarios. Each has different characteristics — your job is to determine whether it crosses the threshold for mandatory reporting.
MAJOR = mandatory report to competent authority (initial notification within 4h of classification) · NOT MAJOR = log internally
ATM network — 340 machines offline across DE, NL, AT (3h and counting)
Critical service; 3 EU Member States; 14% of retail clients unable to withdraw cash
Internal HR portal — degraded performance (8s load, normal 2s)
Internal only; no customer, financial counterpart, or transaction impact
⚠ Fraud detection system — offline 85 minutes; estimated undetected fraud losses €120,000
Critical function; duration below 2h threshold; economic impact already above €100k
Core banking — settlement engine at 40% processing capacity (2.5h)
Critical function; end-of-day regulatory reporting at risk; systemic financial exposure
⚠ Mobile banking — intermittent login failures affecting 7% of active users (90 min)
Customer-facing; 7% client impact; 90-minute duration; economic impact estimated <€100k
Staff VPN — 3 remote employees unable to connect
Internal only; no client, counterpart, transaction, or critical-function impact
Your CEO, David Chen, is on a flight to Singapore. He took off two hours ago. He's unreachable for the next 8 hours.
Meanwhile, CloudVault's account manager finally calls back:
Marcus Hahn — CloudVault "Jordan, look — I know this is bad timing. We're seeing issues in EU-West. Our team is on it."
You "Marcus, when we signed the contract, you personally assured me EU-West had full redundancy. You said — I have the email — 'no single point of failure in our EU infrastructure.' What happened?"
Marcus A pause. "The redundancy is at the application layer. This is a storage controller issue. We... I'll be honest, Jordan, I'm not sure our maintenance schedule covered the firmware on those controllers. I need to check."
You "So the 'no single point of failure' had a single point of failure."
Marcus "I'll update you in an hour."
The notification deadline is approaching. Your CEO is unreachable. The vendor is vague. You need to decide what to file.
The 4-hour window under Article 19 is closing. You must file an initial notification with your national competent authority. The CEO is on a plane. The vendor says "2-4 hours." You don't have a root cause.
What do you file?
You file at 2:12 PM — 3 minutes before deadline.
Dr. Elena Rossi — National Competent Authority "Mr. Adams, I've received your initial notification. Thank you for filing within the window. I note the root cause is unknown — when do you expect the intermediate report?"
You "Within 72 hours. We're working with CloudVault to determine root cause."
Elena "The report notes your CEO was unreachable. Who authorised the filing?"
You "I did. Under the delegated authority in our ICT incident management policy, section 4.3."
Elena "Good. That's exactly the kind of documentation we expect to see."
Your phone buzzes. Singapore area code. David Chen landed 20 minutes ago.
David Chen — CEO "Jordan. My counsel called during the board presentation. You filed a major incident notification with the BaFin using delegated authority. While I was in the air. I had to explain to the Singapore board why our compliance officer can unilaterally notify regulators without my sign-off."
You "The Article 19 deadline was 2:15 PM. You were unreachable. Section 4.3 of the ICT policy authorises—"
David "I know what Section 4.3 says. I wrote it. We'll talk Thursday."
Article 19 requires three reports: (1) an initial notification within 4 hours of classification, (2) an intermediate report within 72 hours, and (3) a final report within one month. The initial report doesn't require root cause — only what you know: nature, classification, first impact assessment, and a point of contact. Filing early with partial information is exactly what DORA intends. The intermediate report is where root cause analysis belongs. Filing under delegated authority was correct — but "correct" and "comfortable" are different things.
Marcus's update arrives at 3:08 PM: "Root cause identified — storage controller firmware bug in EU-West. Patch deploying now. Full resolution by 5 PM."
You file at 3:15 PM. Better data. But 60 minutes past the deadline.
Dr. Rossi "Mr. Adams, your initial notification was due at 2:15. It arrived at 3:15. Under Article 19, the initial report must be submitted within 4 hours of classification. Can you explain the delay?"
You "We were waiting for the vendor to confirm root cause—"
Dr. Rossi "The initial report doesn't require root cause. It requires what you know. You could have filed at 2:15 and updated when the root cause was confirmed. That's what the intermediate report is for."
The initial notification does not require root cause. It requires what you know: nature, classification, first impact assessment, and a contact person. Waiting for "better data" past the 4-hour deadline is the single most common DORA reporting failure. The regulation is designed for fast, incomplete early filings — that's why the intermediate report (72 hours) and final report (1 month) exist. Filing late with a root cause doesn't compensate for missing the deadline.
"Mr. Adams, I've received your initial notification. It says 'ICT incident under investigation.' That's it."
"Under Article 19, the initial notification must include: the nature and classification of the incident, a first assessment of impact, and a point of contact. Your filing contains none of these."
You "We're still determining the scope—"
Elena "You classified this as major. That means you already determined it meets the criteria. The initial report should reflect that assessment. I'll need a revised submission within 2 hours."
You scramble to revise and resubmit. The delay is logged. Elena Rossi's office confirms receipt but notes the initial submission failed to meet Article 19's four minimum elements — a fact that will appear in the post-incident review.
Article 19 specifies four minimum elements for the initial notification: (1) nature and classification of the incident, (2) a first assessment of impact, (3) the financial entity's identification details, and (4) a point of contact. "ICT incident under investigation" meets none of these. The regulator treats an incomplete filing as a failed filing — you've met the deadline but not the obligation. A revised submission within 2 hours avoids a formal supervisory finding, but the deficiency is already on record.
CloudVault's incident is resolved. Payments are processing normally. The settlement queue clears by 7 PM. No data was lost — but 6 hours of degraded service on month-end.
Marcus Hahn "It was a firmware bug in our storage controller. Affected EU-West only. We've deployed the patch. It won't happen again."
You "Marcus, this outage lasted 6 hours and affected our critical payment function. Under DORA Article 28, we need to assess whether your resilience arrangements meet the standards in our outsourcing agreement."
Marcus "That's... let me check with our compliance team and get back to you."
He doesn't get back to you. The board meeting is Thursday. The CEO is back tomorrow. You need to decide how to frame this.
CloudVault has submitted their incident report. Before the board meeting, you need to check it against your DORA Article 28 outsourcing obligations. Identify every gap in the report.
A firmware bug in the EU-West storage controller caused degraded payment processing from 09:47 to 16:02 CET on 14 December 2027 (6 hours 15 minutes). EU-Central and US-East regions were unaffected.
The bug was introduced by an automated firmware update deployed at 09:30 CET. CloudVault's internal monitoring detected the degradation at 09:47 and the engineering team began investigation immediately.
Firmware version 4.1.2 introduced a memory allocation conflict affecting write operations under sustained load. The issue was isolated to the EU-West cluster. The patch (v4.1.3) was deployed at 16:02 CET.
The firmware update was supplied by Nexon Storage Systems GmbH, a sub-contractor responsible for CloudVault's storage infrastructure in Europe.
Patch v4.1.3 deployed at 16:02 CET. All payment processing queues restored by 19:00 CET. No data loss confirmed. CloudVault will review firmware update procedures.
CloudVault will implement a mandatory 48-hour staging environment test before production firmware deployments. Internal review scheduled for January 2028.
CloudVault acknowledges the incident caused service degradation. We are reviewing the applicable SLA terms in coordination with our legal team and will respond to Meridian's formal SLA query within 30 business days.
Select all that apply — then submit.
Thursday morning. David Chen is back. The board wants to understand what happened. Your SLA penalties total €300,000. Three merchant clients have requested "assurance meetings."
The question isn't just "what went wrong." It's "whose fault was it?" CloudVault's firmware bug caused the outage. But DORA Article 28 says you are responsible for managing third-party ICT risk. The vendor failed. But did your oversight fail too?
"The outage was caused by CloudVault's firmware bug. But our third-party risk management didn't identify that their EU-West maintenance schedule had a gap. That's on us."
"Here's the remediation plan: quarterly vendor resilience reviews, automated monitoring of our critical ICT providers' maintenance schedules, and updated exit strategy documentation for CloudVault."
The CEO nods. The board appreciates the honesty. When Dr. Rossi reviews your intermediate report and sees the same accountability, she notes: "Meridian's incident response demonstrates a mature approach to third-party ICT risk management."
Board Chair — Patrick Lund "Jordan, your accountability is noted — and respected. But we have to discuss CloudVault's renewal. It's a €4M annual contract. Given what happened, the board needs to consider whether we should exit." The exit strategy you'd recommend carries an estimated €2M transition cost and a 6-month delay to the next product launch. The right answer still has a price tag.
Article 28 makes the financial entity responsible for managing ICT third-party risk — not just for having a contract. The regulator doesn't want to hear "it was the vendor's fault." They want to see that you had oversight, that you learned, and that your remediation plan prevents recurrence. Full accountability is the right answer — but it opens a real conversation about a €4M contract and what comes next.
"CloudVault experienced a firmware failure in their EU-West region. Here's how we responded: classified the incident, notified the regulator within the 4-hour window, initiated failover procedures, and recovered full processing by 7 PM."
"Recommendation: enhanced vendor oversight including quarterly resilience reviews."
David Chen — CEO "When was our last vendor risk assessment for CloudVault?"
A pause. The board chair looks up from his notes.
You "Fourteen months ago."
David "DORA requires ongoing monitoring. Fourteen months isn't ongoing. The board approved a vendor oversight budget in January. I want to understand why that assessment hasn't been updated."
The board is still broadly satisfied with the incident response. But the 14-month gap is now on record. Dr. Rossi's intermediate report confirms it: "The entity's third-party risk assessment for CloudVault was last updated 14 months ago. DORA Article 28 requires ongoing monitoring, not periodic review."
A competent response timeline doesn't compensate for a stale risk assessment. Article 28(2) requires financial entities to manage ICT third-party risk on an ongoing basis — which means continuous monitoring of your critical providers' resilience, not an annual checkbox. A 14-month gap between vendor risk assessments tells the regulator your third-party oversight framework exists on paper but not in practice. The intermediate report will flag this as a structural gap.
"CloudVault's infrastructure failed. Their firmware management was inadequate. We're reviewing the contract and considering penalties."
The CEO asks: "Did we know about this risk?" The honest answer is no — because your last vendor risk assessment was 14 months ago. You don't say that.
Dr. Rossi's report is less charitable: "The entity's presentation to the management body attributed the incident entirely to the ICT third-party service provider. However, under Article 28(2), the financial entity retains full responsibility for compliance with DORA, including oversight of ICT third-party service providers. The absence of an updated risk assessment suggests insufficient ongoing monitoring."
Article 28(2) is explicit: the financial entity retains full responsibility for compliance with DORA, including oversight of ICT third-party service providers. Blaming the vendor is not a compliance strategy — it's evidence that your third-party risk management framework failed. The regulator expects to see three things: that you had oversight before the incident, that you took accountability during, and that your remediation prevents recurrence. Presenting this as "their fault" demonstrates none of these.
System Status
Art. 19 Filing Deadline
01:42:18
remaining
Incident Feed
Initial Incident Notification — Article 19
Complete all fields. The competent authority is waiting.
Click the four reporting milestones in the correct order — from the first obligation to the last. Select them one at a time.
Article 17 — ICT incident classification criteria
Article 19 — Reporting obligations (4h initial, 72h intermediate, 1 month final)
Article 28 — Third-party ICT risk management
Article 30 — Key contractual provisions for ICT services
You scored . The 4-hour clock doesn't wait. Try a different path?