DORA Common Misunderstandings

Common misunderstandings about DORA tend to share a pattern: they shrink a service-wide regime into a single team, a single document, or a single date. DORA applies from 17 January 2025, and it covers ICT risk management, incident reporting, testing, third-party risk, and information sharing, supervised as a whole. Misunderstandings arise when DORA is read as an information technology project, when proportionality is read as an exemption, when outsourcing is read as transferring responsibility, or when application is read as completion. Each misunderstanding leaves a gap, and the gap usually appears only during a disruption, a test, or a supervisory conversation, when it is hardest to close.

This guide works through the most persistent misunderstandings in turn, using different service illustrations, so that a reader can check each one against their own picture rather than accepting a general warning.

The idea that DORA belongs only to technology teams is persistent, and it is misleading. Technology teams are central to ICT risk, testing, and provider oversight, but DORA is concerned with services that customers rely on, and those services involve business ownership, risk governance, incident decision making, and customer communication. A retail brokerage illustration makes the point, and it is only an illustration: when trading is disrupted, the technology failure matters, but so does the decision about what to tell customers, the decision about whether to pause a service, and the record of who decided what and when. If business owners are absent from incident rehearsals and test design, the technology recovery may succeed while the service recovery fails, because nobody owned the customer and market consequences.

A related misunderstanding is that DORA is a large firm regime, with smaller firms able to treat it lightly. Proportionality, explained in its own guide, calibrates depth to risk, size, and complexity, but it does not remove duties, and a critical service run by a small firm still deserves strong treatment. A small lender illustration helps, and it is only an illustration: a single lending platform, run on a small number of systems, may still be the firm's only route to customers, and its disruption may affect every customer at once. Size is a factor in how work is organised, not a measure of whether a service matters, and supervisors judge a small firm's picture by whether it fits its risk, not by whether it resembles a large firm's file.

Treating DORA as a checklist, or as a set of separate chapter projects, is the misunderstanding named in the theme of this cluster, and it deserves emphasis. A checklist can confirm that a policy exists, a template is used, and a test was run, without showing whether incident, testing, and provider records refer to the same service or whether lessons travel between them. Separate chapter teams compound the problem, because each team can complete its own task while the service as a whole remains unexamined. A custody service illustration shows the alternative, and it is only an illustration: risk, incident, testing, and provider records for that custody service should all name the same systems, the same providers, and the same recovery sequence, so that a reader can follow one service through every chapter without switching vocabularies.

Outsourcing does not transfer responsibility for a service, even where a provider operates the system, holds the data, or runs the recovery. DORA is explicit in its logic, if not in a single slogan: the financial entity remains responsible for its service, and it must therefore retain rights and information that let it oversee, audit, and if necessary exit a provider relationship. A misunderstanding here often appears as a contract that promises a service level without giving the firm access to the information, testing, or audit rights it needs to judge whether that promise is being kept. The contract is not the resilience, and a provider's assurance is not a substitute for the firm's own service map, register, and test evidence.

The final misunderstanding is temporal: that DORA is finished when it starts to apply, or when an implementation project closes. Application from 17 January 2025 begins live duties, technical standards continue to apply on their own dates, and incidents, tests, provider changes, and supervisory findings keep revising the picture. A project that closes with a celebration and a frozen set of documents will drift from reality as services and providers change, and the drift will only become visible when a document is needed under pressure. A rolling programme, with owners, review dates, and a habit of revising after each lesson, is less tidy than a closed project, but it matches how DORA actually works, as a continuing regime for services that keep changing.