DORA ICT Risk Management Framework

Under DORA, ICT risk management is a single framework for managing technology risk across a financial entity, from identifying risk through protection and detection to response and recovery, with regular review as technology and threats change. It is not a collection of separate controls that happen to sit in the same policy. The framework exists to keep important services running through disruption and to support their return when disruption interrupts them.

The test of the framework is practical rather than documentary. A service can be named, its supporting systems and suppliers can be traced, and the way each part of the framework helps that service can be explained in plain terms. Where that explanation breaks down, the framework has a gap, even when individual controls look complete on paper. DORA treats that joined-up view as the point of the exercise.

A framework holds together when information flows between its parts. A risk identified during planning changes what is protected, what is watched, and what is rehearsed for recovery. An incident that is detected early changes the assessment of the risk that produced it. A recovery that proves slow or partial changes the protection and detection work that precedes the next incident. Without those loops, each part can be maintained in isolation while the service as a whole remains fragile.

Governance gives those loops a home. Senior management responsibility, clear ownership for each service and system, and a route for risk information to reach decision makers are part of the structure. The framework is therefore as much about decision making as it is about technology. It asks who decides, on what information, and with what authority to change a service, a supplier arrangement, or a recovery sequence.

Consider a payment service that depends on a customer channel, a processing platform, a data store, and a settlement link. Identification maps that chain and the risks that could interrupt any link in it. Protection hardens the links that matter most and limits the effect when one link is compromised. Detection watches for signs that a link is failing or under attack, so response can begin before customers notice a widespread failure.

Response contains the effect, protects data and customers, and keeps communication clear while the service is degraded. Recovery restores the service in a planned order, checking that restored systems are sound before they carry live traffic again. Review then asks what the disruption revealed about the original map, the protection, the detection, and the recovery order. Each phase hands the next phase a better starting point than it had before.

A control list can pass while a service fails. A firewall rule can be correct, a backup can complete, and a monitoring alert can fire, yet the service can still stay down because nobody owns the order in which systems return, because a restored system depends on a supplier that is itself still disrupted, or because the team that responds cannot reach the team that holds the recovery credentials. Those are joining-up failures, not failures of a single control in isolation.

The service view exposes those seams. It follows one service from the customer to the underlying data and back again, and it asks at each seam who acts, what information they need, and what happens when that information is missing. DORA places that discipline at the centre of ICT risk management, because resilience is a property of the service in disruption, not a property of a policy document in calm conditions.

Technology and threat change continuously, so a framework fixed at one point in time drifts away from the service it is meant to protect. New systems are introduced, suppliers change, customer channels evolve, and attackers adapt. Review is the mechanism that brings the framework back into line with the service as it actually runs, rather than the service as it was described when the framework was first written.

Good evidence shows decisions and their consequences. It shows the service map, the risks attached to it, the protections and detection in place, the response and recovery arrangements, and the reviews that changed them. It also shows who owned each part and when each part was last tested or reconsidered. Evidence of that kind allows a reviewer to trace a service through disruption without relying on memory or on a single individual.