The Digital Operational Resilience Act changed the centre of gravity in vendor management for financial entities. Where older supervisory expectations treated outsourcing as a contracting problem, DORA treats your technology suppliers as an extension of your own operational risk surface. The shift is subtle on paper and significant in practice.
From outsourcing register to ICT dependency map
DORA expects regulated entities to maintain a register of information covering their contractual arrangements for ICT services. Read literally, that sounds like a list. Read in the spirit of the regulation, it is a dependency map: which providers underpin which critical or important functions, where those providers sit, who they in turn rely on, and what happens to your service if any one of them degrades.
The distinction matters because supervisors are increasingly interested in concentration risk — the scenario where a handful of providers sit beneath a large share of the financial system. A register that captures only your direct contracts misses the fourth-party and chain dependencies where concentration actually accumulates.
Three questions a good register should answer
When we help teams pressure-test their register against DORA, we keep coming back to three questions that a flat supplier list rarely answers well:
-
Which functions break if this provider fails? Map every ICT arrangement to the business function it supports, and flag whether that function is critical or important. Without this link, you cannot prioritise testing or exit planning.
-
What is the realistic exit? DORA pushes entities to think about substitution and orderly exit for arrangements supporting critical functions. “We would migrate” is not an exit plan; a tested, costed, time-bound path is.
-
Where does the chain go? Subcontracting matters. If your provider’s resilience depends on a hyperscaler in a single region, that exposure is yours too, even though you never signed a contract with the hyperscaler.
Why mapping across frameworks helps
Most financial entities are not implementing DORA in isolation. They already carry obligations under NIS2, internal information-security frameworks aligned to ISO 27001, and in many cases NIST-derived control catalogues. The third-party and incident-handling expectations across these regimes overlap heavily — but they use different vocabulary and different article structures.
The practical payoff of a cross-framework view is that a single control (“maintain and test an exit plan for critical providers”) can be evidenced once and mapped to the relevant obligation in each regime, instead of being re-discovered and re-documented per audit. That is the difference between compliance as a recurring fire drill and compliance as a maintained asset.
A note on evidence
Whatever tooling you use, the test is the same: when a supervisor asks where the obligation says that, can you point to the specific article and paragraph, and to the specific control and evidence that satisfies it? Resilience is ultimately demonstrated, not asserted — and the entities that fare best are the ones whose register is a living model of their dependencies rather than a snapshot taken once a year.
This article is general information, not legal advice. Always validate against the current text of the regulation and your supervisor’s guidance.