Legislation · 18 Sep 2024 · Rob Nidschelm

DORA Is No Longer a Deadline. It Is an Operating Model

The Digital Operational Resilience Act has applied across the European Union since 17 January 2025. The deadline has passed, but the more important work has only become clearer: financial services must be designed to keep operating when technology fails.

It is easy to approach a new regulation as a project. A team interprets the requirements, identifies gaps, updates policies and assembles evidence for an audit. Once the deadline passes, attention moves elsewhere.

That model is particularly dangerous with DORA.

DORA is not primarily asking whether an organisation can produce the right documents. It is asking whether the organisation can continue delivering important financial services when an ICT provider fails, a cyberattack spreads, a critical platform becomes unavailable or a recovery plan does not work as expected.

That is an operational question. It cannot be answered once and filed away.

Why DORA exists

Modern financial services are built on a long chain of technology dependencies. A customer may see a single application, but the service behind it can depend on identity platforms, payment processors, cloud infrastructure, data feeds, managed service providers, software suppliers and telecommunications networks.

This creates efficiency, but it also concentrates risk. A disruption at one supplier can affect many financial entities at the same time. A failure in a shared platform can cross national borders before an individual organisation has understood what happened.

DORA creates a harmonised European framework for managing that risk. It covers a broad range of financial entities and brings ICT risk into the same governance conversation as other material business risks. It also reaches into the supply chain by setting expectations for the management of ICT third-party providers.

The objective is not perfect availability. No organisation can prevent every outage or attack. The objective is the ability to withstand disruption, respond in a controlled way and recover without losing control of critical services, data or decisions.

The five capabilities behind the regulation

DORA is often summarised as five pillars. That summary is useful, provided they are not treated as five isolated workstreams.

1. ICT risk management

An organisation needs a coherent framework for identifying, protecting, detecting, responding to and recovering from ICT risk. That includes asset knowledge, ownership, change control, vulnerability management, identity, monitoring, continuity and recovery.

The difficult part is usually not the absence of tools. It is the absence of a reliable connection between them. A vulnerability scanner may identify a critical issue, but the organisation still needs to know which business service depends on the affected asset, who owns it, which supplier supports it and what would happen if it were taken offline.

Risk management becomes useful when technical information can be translated into operational consequences.

2. Incident management and reporting

DORA requires significant ICT-related incidents to be classified, managed and reported through defined processes. The reporting obligation matters, but it should not become the centre of the incident response plan.

During a serious incident, several clocks start at once. Technical teams are containing the problem. Business teams are assessing customer impact. Legal, privacy, communications and executive stakeholders need accurate information. Regulators may require notification. Suppliers may hold important evidence.

An effective process decides in advance who collects facts, who classifies the incident, who can approve a notification and how conflicting information is resolved. A template without rehearsed decision-making will not survive a real crisis.

3. Digital operational resilience testing

Controls should be tested before an attacker or outage tests them for you.

This includes vulnerability assessments, scenario exercises, recovery tests and, for certain organisations, threat-led penetration testing. The purpose is not to demonstrate that a control exists. It is to discover where assumptions fail.

A backup is not evidence of recoverability until restoration has been tested. A continuity plan is not evidence of continuity until teams can execute it under pressure. A supplier escalation path is not reliable until someone has confirmed that it works outside normal office hours.

Testing should create corrective work with owners and deadlines. Otherwise, it becomes theatre.

4. ICT third-party risk management

Outsourcing a service does not outsource accountability.

Financial entities need to understand which providers support critical or important functions, what those providers depend on and how concentration risk could affect the organisation. Contracts must support oversight, access, incident cooperation, continuity and exit arrangements.

The contract is only one layer. Operational teams also need current contacts, dependency maps, tested escalation routes, recovery expectations and a credible alternative if a supplier can no longer provide the service.

The hardest question is often not whether a supplier is secure. It is whether the organisation can continue if that supplier is unavailable.

5. Information sharing

DORA supports the voluntary sharing of cyber-threat information and intelligence. This reflects a basic reality: attackers reuse infrastructure, techniques and access paths across organisations.

Information sharing is most useful when it is operational. Indicators need context. Intelligence must reach the teams that can change monitoring, block infrastructure, search for related behaviour or adjust a control. A report that arrives after the threat has changed is interesting, but not protective.

Governance changes the quality of the programme

DORA places responsibility at management level. This does not mean that executives need to become security engineers. It means they must be able to understand the organisation’s exposure, approve the risk framework, allocate resources and challenge whether resilience claims are supported by evidence.

Boards should be cautious with dashboards that compress resilience into a single colour or score. A green status may hide an untested recovery process, an unsupported legacy application or a supplier dependency with no practical exit route.

Useful governance asks questions such as:

Which critical services have not completed an end-to-end recovery test?
Which suppliers create the greatest concentration risk?
Which incidents exposed weaknesses that remain unresolved?
Which privileged access paths could bypass normal controls?
Where does the organisation depend on knowledge held by one person or provider?
What evidence shows that remediation actually reduced risk?

These questions connect regulation to operating reality.

A practical DORA evidence chain

Many organisations have individual controls but struggle to prove how they work together. A practical evidence chain can be built around a critical business service.

Start with the service. Identify the processes, information, applications, infrastructure, identities and suppliers required to deliver it. Record the failure scenarios that matter. Define how disruption will be detected and escalated. Test the recovery path. Capture the result. Assign corrective actions. Retest after material changes.

This creates a traceable line from business impact to technical control and from policy to demonstrated behaviour.

The same approach improves incident response. When an alert affects a known asset, teams can understand which service is at risk, which recovery objective applies, which supplier must be involved and which stakeholders need information.

Common ways DORA programmes lose momentum

The first is treating policies as the outcome. Policies are necessary, but resilience is demonstrated through operation and testing.

The second is separating compliance from engineering. If control requirements remain in spreadsheets while infrastructure changes in cloud platforms, identity systems and deployment pipelines, the compliance view will quickly become inaccurate.

The third is assessing suppliers only during procurement. A provider’s risk can change through acquisitions, subcontracting, service redesign, financial pressure or new vulnerabilities.

The fourth is measuring activity instead of capability. The number of tests completed says little if the same weaknesses remain open or the scenarios avoid critical dependencies.

The fifth is assuming that a successful recovery exercise proves future recoverability. Systems, people and suppliers change. Evidence has a shelf life.

What good looks like after the deadline

A mature DORA programme becomes difficult to separate from good operational management.

Critical services have owners. Dependencies are known. Significant changes trigger risk review. Access is controlled and reviewed. Incidents produce learning, not only closure. Recovery is tested against realistic scenarios. Supplier risk is monitored throughout the relationship. Management receives enough context to make decisions rather than simply acknowledge reports.

Most importantly, resilience is treated as a cycle:

understand, protect, detect, respond, recover, learn and test again.

That cycle is the real operating model behind DORA. The regulation provides the common European baseline. The organisation still has to turn it into something that works at three in the morning, when the primary system is unavailable, the supplier is still investigating and customers are waiting.

Sources and further reading

This article provides general technical and operational context, not legal advice.

Continue the series: European National Cyber & Digital Law Series index

DORA Is No Longer a Deadline. It Is an Operating Model

Why DORA exists