DORA Case Study: A Bank Facing a Major Incident

A payment platform outage at 9:15 a.m., customer transactions on hold, a cloud service provider called in, and business teams estimating it will take an hour to return to normal operations: a banking DORA incident cannot be treated as a simple IT incident. It immediately puts governance, business continuity plans, the quality of communication, the management of dependencies, and the ability to produce evidence for the regulator to the test.

The DORA Regulation, effective as of January 17, 2025, has strengthened European expectations regarding the digital operational resilience of financial institutions. For a bank, the challenge is therefore not merely to prevent cyberattacks or outages. It is to demonstrate that the institution can absorb a disruption, maintain or restore its critical functions, and communicate systematically within a regulated environment.

What a DORA incident Reveals at a Bank

Let’s consider a realistic scenario. A retail bank notices a sudden degradation in its online banking application. Customers can no longer confirm certain transfers, while transactions at branch locations remain partially possible. The initial investigation reveals an anomaly at an ICT service provider supporting an authentication component.

The operational question is not just, “When will service be restored?” It quickly becomes broader. Which business functions are affected? Which customers and channels are at risk? Is there an acceptable workaround? Has the threshold for classifying an incident as major been reached, or is it likely to be reached? Who decides to activate the crisis response team? What message should be communicated to customers, customer service teams, senior management, and the relevant authorities?

DORA calls for organizing these responses within a coherent framework. The incident must be detected, recorded, analyzed, classified, and—when the applicable criteria are met—reported in accordance with established procedures. This process cannot rely on an IT manager’s improvisation or on a crisis procedure that is consulted for the first time during the incident.

Do not confuse a technical incident with an operational impact

A minor outage can become a major one if it affects a critical function, a significant number of customers, sensitive transactions, or a period of high activity. Conversely, a highly visible technical issue may not warrant the same level of escalation if essential functions remain available thanks to proven fallback solutions.

The assessment therefore requires cross-referencing technical and business data: the duration and scope of the outage, the criticality of the service, the impact on operations, the number of affected customers, potential losses or costs, reputational damage, geographic exposure, and dependence on a third party. The challenge lies not so much in having these criteria as in making them actionable under pressure, with information that is initially incomplete.

DORA Banking Case: Managing the First Few Hours

The first few hours set the tone for what follows. A well-prepared bank does not try to produce a perfect analysis right away. Instead, it establishes a decision-making rhythm, verifies the available facts, and keeps its options open for continuity.

Establish a shared understanding

The incident manager must obtain an accurate picture of the situation: affected services, estimated start time, known causes and hypotheses, containment measures, customer impact, relevant dependencies, and actions taken by service providers. This status report must be updated at defined intervals, taking care not to confuse a technical hypothesis with a confirmed fact.

A properly maintained crisis log becomes a compliance asset in this context. It makes it possible to reconstruct decisions, their rationale, the approvals obtained, and the communications that took place. It also facilitates lessons learned and the preparation of internal or regulatory reports. Without this traceability, the organization risks having competent teams but being unable to demonstrate effective control over its response.

Implementing Impact-Oriented Governance

The crisis response team should not be overstaffed as a matter of course. Its size depends on the actual and foreseeable impact. However, responsibilities must be clearly defined: incident management, business continuity decisions, liaison with the service provider, regulatory assessment, external communications, reporting to senior management, and legal coordination.

In a bank, business continuity provides essential discipline: it refocuses the response on critical activities, acceptable recovery times, and the fallback modes that are actually available. Cybersecurity, IT, business units, compliance, and communications must therefore work toward a shared understanding of priorities. Conflicting messages or poorly defined approval timelines can exacerbate the incident, even as technical remediation progresses.

Managing Notifications Without Waiting for Absolute Certainty

Notification processes must be integrated into the incident management system. They rely on the ability to classify incidents, validation responsibilities, and predefined communication channels. Waiting until a technical issue is fully resolved before assessing notification requirements poses a risk of noncompliance.

This does not mean disseminating speculative information. A distinction must be made between what has been established, what is estimated, and what is still under investigation. The bank must also plan for the entire regulatory disclosure process, from the initial notification through updates to the final report, in accordance with applicable requirements and communications with the competent authority.

Turning DORA Requirements into Operational Evidence

A credible system is not measured by the quality of a single policy. It is measured by the alignment between governance documents, incident procedures, business impact analyses, business continuity plans, supplier contracts, drills, and retained evidence.

For the online banking scenario, for example,the impact analysis must identify the critical services supported by authentication, the expected recovery times, technical and human dependencies, and the consequences of prolonged unavailability. The business continuity plan must then specify who authorizes the switch to degraded mode, how operations are prioritized, what information is provided to branches and customer service centers, and under what conditions a return to normal operations is approved.

This integration is particularly important for legacy systems, which are often built in silos. An IT disaster recovery plan may cover the restoration of infrastructure without addressing the business decision to resume operations. A crisis plan may define the members of a crisis response team without incorporating the DORA classification criteria. A compliance review may verify the existence of procedures without testing their actual use. DORA encourages linking these mechanisms rather than treating them as separate entities.

The Crucial Role of ICT Service Providers

In many banking incidents, the financial institution alone does not control the speed of recovery. It depends on a cloud provider, a software vendor, a telecommunications carrier, a payment service provider, or an integrator. This dependence does not shift responsibility away from the bank.

Contracts and management procedures must ensure that the necessary information can be obtained quickly: a description of the incident, the scope of the impact, corrective actions, estimated timelines, escalation contacts, and information needed for notification. It is also necessary to be familiar with fallback or business continuity solutions in the event of prolonged unavailability. Their appropriateness depends on the service in question, the level of outsourcing, and security or confidentiality constraints.

Tests are the most reliable way to verify this preparedness. A useful exercise goes beyond simply simulating a failure. It introduces realistic stressors: conflicting information from the supplier, the unavailability of a decision-maker, a rapid increase in customer calls, a communication channel failure, or the need to assess a notification within a tight deadline. The goal is to observe decision-making and coordination, not just the technical capacity for recovery.

Professionalizing Response Skills

Operational resilience requires professionals who can apply guidelines to the specific circumstances of an incident. BCP/DRP managers must understand digital governance requirements. Information Security (SSI) and IT teams must take into account business impacts and continuity obligations. Risk and compliance functions must be able to scrutinize the quality of classifications, evidence, and action plans.

This cross-functional competency is developed through shared methods, practical case studies, and regular exercises. Structured training, in particular, helps standardize terminology, clarify responsibilities, and translate regulatory requirements into testable scenarios. In complex organizations, it prevents each line of defense from using its own criteria and documents without a consolidated approach.

Mistakes That Weaken the System

Four mistakes frequently occur during evaluations or crisis exercises:

• to view DORA as a topic exclusively related to cybersecurity or information technology;
• documenting plans without verifying the decisions they enable;
• underestimating dependence on a critical ICT service provider;
• Initiate notification procedures only when the incident has already occurred.

Correcting these discrepancies involves less adding new procedures than ensuring that existing systems are consistent, well-coordinated, and manageable. The quality of a response often hinges on specific details: a reliable on-call roster, an escalation threshold understood by all departments, a validated decision matrix, a tested fallback procedure, or a supplier contact who can be reached immediately.

When faced with a major incident, a bank that retains its ability to make decisions, communicate, and justify its choices protects more than just its digital availability—it protects the trust placed in its services. It is this capability—built before the crisis and regularly tested—that gives DORA its operational impact.

This post is also available in: