DORA readiness is a map of how your service really fails
A year after DORA became applicable, financial product teams can turn registers and testing into better knowledge of dependencies, recovery and customer impact.
The EU Digital Operational Resilience Act became applicable on 17 January 2025. It introduced harmonised expectations across ICT risk management, incident handling, resilience testing and third-party risk for financial entities in scope. The required registers of contractual arrangements with ICT third-party providers give supervisors and organisations a structured view of dependencies.
A register can meet a reporting need while still failing an operations team. The real value appears when a product team can trace a customer journey through services, infrastructure, data and suppliers—and make a credible decision when one of them fails.
Map business service, not organisational chart
Start with a service customers recognise: make a payment, retrieve a policy, view a position or complete onboarding. Trace the people, software, data stores, queues, identity providers, cloud resources and third parties required to complete it.
Record where the service crosses ownership boundaries. Those seams are where assumptions accumulate: one team expects a retry, another expects a manual queue, and a supplier's recovery target starts after an incident is declared rather than when customers lose access.
Reconcile contracts with architecture
Third-party registers should be testable against what engineers operate. Procurement may know the contracted legal entity while engineering knows a product name or API. Finance may know the spend while security knows the data flow. Connect those views with stable identifiers and named owners.
For each material dependency, understand:
- which customer services rely on it;
- what data and privileges it receives;
- the practical exit or substitution path;
- incident notification and evidence commitments;
- recovery objectives and historical performance;
- concentration risk shared with other services or suppliers.
A contract cannot create a technical exit that has never been designed.
Exercise uncomfortable failure modes
Tabletop exercises should make decisions difficult enough to be useful. Remove a primary supplier during a busy period. Make contact details stale. Let a fallback depend on the same identity service as the primary route. Introduce incomplete information and a customer communication deadline.
Then run technical recovery. Restore data, rotate credentials, fail over traffic and reconcile queued work. Time the result from customer impact to verified recovery. Record which runbook steps were assumptions.
Design graceful degradation
Not every service needs an all-or-nothing response. A product may preserve read-only access, queue a request safely, provide a manual route or clearly show when information was last updated. These modes must be designed, secured and tested before the primary path fails.
Communication is part of resilience. Give customer-facing teams accurate service state, affected scope and next-update timing. Avoid confident restoration estimates based only on infrastructure health; verify the business transaction end to end.
Make the register a living operational asset
Update dependency information through change management, architecture review and procurement events. Assign data quality ownership. Use incidents and exercises to correct the map.
DORA creates a regulatory reason to do this work. The product reason is stronger: when teams understand how a service really fails, they can reduce both the likelihood and the customer cost of failure.
This article is operational guidance, not legal advice. Confirm DORA scope and obligations with appropriate specialists.