Most financial entities discover DORA's third-party rules the hard way. They have a list of vendors in a spreadsheet, a folder of signed contracts, and a vague sense that they could switch providers if they had to. Then a supervisor asks for the register of information, the contract clauses that prove oversight, and the exit plan for a critical provider, and the gaps show up fast.

DORA treats ICT third-party risk as an operating discipline, not a procurement afterthought. The Digital Operational Resilience Act took effect across the EU in January 2025, and it asks financial entities to know exactly who runs their critical functions, prove that their contracts give them control, and show they can leave a provider without breaking the business. This guide covers what DORA expects and how to run it as a living program with OptiTech.

What DORA expects of you

DORA applies to banks, insurers, investment firms, payment institutions, crypto-asset providers, and many other financial entities operating in the EU. Its third-party chapter has a simple goal behind the detail: a financial entity stays responsible for its operational resilience even when it outsources the technology that delivers it.

That responsibility turns into a handful of concrete obligations:

  • Maintain a register of information. You keep a structured record of every contractual arrangement for ICT services, kept current and ready to hand to your supervisor.
  • Classify what's critical. You identify which ICT services support critical or important functions, because those carry the heaviest requirements.
  • Put the right terms in every contract. DORA names specific clauses your agreements must contain, especially for critical services.
  • Manage concentration risk. You watch for over-reliance on a single provider whose failure would take down more than one critical function.
  • Document and test exit plans. For every critical provider, you can show a way out that keeps the business running.

The penalties matter, but the daily risk is sharper: a supervisor can ask for any of this at short notice, and an incomplete answer signals a governance problem that invites more scrutiny.

The register of information

The register of information is the backbone of DORA third-party risk, and it's the first thing a supervisor asks to see. It's not a vendor list. It records each contractual arrangement for ICT services with the detail regulators specified: the provider and its identifiers, the service and the function it supports, the criticality assessment, the contract dates, the data and locations involved, and how substitutable the provider is.

Kept in a spreadsheet, this register drifts out of date the moment a contract renews or a service changes. In OptiTech it lives as a structured register where each arrangement links to the provider, the function it supports, the contract terms, and the evidence behind the criticality call. When the register has to go to a supervisor, you export the current state instead of reconciling versions the night before.

Identifying critical ICT providers

Not every vendor carries the same weight. DORA asks you to work out which ICT services support functions that, if disrupted, would materially impair your ability to operate or meet your regulatory obligations. Those are your critical or important functions, and the providers behind them get the strictest treatment.

The assessment isn't a one-time label. A provider that looked routine can become critical as you route more of a core process through it. OptiTech keeps the criticality assessment attached to each arrangement with the reasoning and the reviewer, so the classification is defensible and you can see when it last changed.

The contract terms DORA mandates

DORA doesn't leave your contracts to chance. For ICT services, and especially those supporting critical functions, your agreements have to contain specific provisions. Among them:

  • Clear descriptions of the services and the service levels.
  • Data location and processing terms, with your right to know where data lives.
  • Access, inspection, and audit rights for you and your supervisor.
  • Cooperation with authorities and incident reporting obligations.
  • Explicit termination rights and, for critical services, exit support.

The hard part isn't knowing the list. It's proving, across dozens of contracts, that each one actually contains the clauses it needs. OptiTech tracks the required provisions against each contractual arrangement, so a missing audit-rights clause or an absent exit-support term shows up as a gap you can assign and close, not a surprise you find mid-audit.

Concentration risk

Concentration risk is what keeps regulators up at night. When many financial entities depend on the same handful of cloud and technology providers, one provider's outage can ripple across the whole sector. DORA asks you to see your own exposure: where you rely heavily on a single provider, where several critical functions sit with the same vendor, and where switching would be hard.

OptiTech surfaces this by connecting providers to the functions they support. When one provider underpins several critical functions, that shows up in the register instead of hiding across separate contracts. Seeing the concentration is the first step to deciding whether you accept it, mitigate it, or plan around it.

Exit strategies and exit plans

Here's the requirement regulators press on hardest, and the one most firms are weakest on. For every critical ICT provider, DORA expects a documented exit strategy: a realistic, tested way to leave that provider without disrupting a critical function.

The reason is straightforward. If a critical provider fails, gets acquired, changes terms, or is ordered out of a market, "we'd figure it out" is not an answer a supervisor accepts. An exit plan turns that scenario into a rehearsed process.

A credible exit plan covers the same ground every time:

  • Triggers. The events that would start an exit, from a breach of service levels to a provider's insolvency.
  • The alternative. A named substitute provider or an in-house fallback, with a realistic view of how hard the switch is.
  • Data and continuity. How you retrieve your data in a usable form and keep the critical function running through the transition.
  • Timeline and owners. Who does what, in what order, and how long each step takes.
  • Testing. Evidence that you've actually walked through the plan, not just written it.

That last point is where plans fall apart. A plan written once and never revisited is a liability, because it describes a provider relationship and an alternative that have both moved on.

Treat the exit plan as evidence, not a document

An exit plan is only worth what you can prove about it. Record who owns it, when it was last tested, and what the test showed. A plan with a recent test date and a named substitute is worth far more to a supervisor than a polished document nobody has exercised.

From register to living evidence

The through line of DORA third-party risk is that everything has to be current and provable on demand. A register that's accurate today, contracts whose clauses you can point to, a concentration view you actually watch, and exit plans with real test dates.

OptiTech keeps these connected. The register links to the contracts, the contracts link to the required provisions, the providers link to the functions they support, and each exit plan links to its triggers, its substitute, and its last test as living evidence. When your supervisor asks, or when an enterprise client runs a resilience review, you show the current state from the OptiTech Console instead of assembling it under pressure. The same records can feed your trust center, so clients see your operational resilience posture without a back and forth.

Getting started

You don't have to solve all of DORA at once. A realistic first pass looks like this:

  1. Build your register of information. Start with the ICT services behind your critical functions.
  2. Classify criticality for each arrangement, and record the reasoning.
  3. Check your contracts against DORA's required provisions, and log the gaps.
  4. Write and test an exit plan for each critical provider, with owners and a test date.

DORA rewards firms that treat third-party risk as an operating habit rather than an annual document exercise. Build the register once, keep it current, prove your contracts and your exits, and both your supervisor and your clients get the same clear answer.

Ready to turn DORA third-party risk into a living program? Book a demo and see how OptiTech connects your register, contracts, and exit plans.