Regulators in the EU and UK now oversee the biggest cloud providers directly, but banks and fintechs still own the risk. Two industry voices explain what changed in their vendor work, from document routes to exit tests.

For most financial firms, cloud and IT vendors used to be a procurement question. Sign the contract, check the certificates and review it once a year. Operational resilience rules have changed that. DORA third-party risk rules now reach into contracts, subcontractor chains and exit plans, while UK regulators have started overseeing the largest cloud providers directly.

So we asked industry leaders one question: what has operational resilience regulation, such as DORA or the UK’s critical third parties regime, forced your company to change in how it manages cloud and tech vendors? We wanted specific process changes over general opinion. Two respondents answered, both from the vendor side. Below, we set their replies against the rules.

Where DORA third-party risk rules stand

The EU’s Digital Operational Resilience Act has applied since 17 January 2025. It makes banks, payment firms and other financial entities manage ICT third-party risk across the whole relationship. That includes a register of every ICT contract, set contract terms and documented exit plans. For services supporting critical or important functions, contracts must give the financial firm full rights of access, inspection and audit.

The first registers showed how hard DORA third-party risk work is. In a 2024 dry run, just 6.5% of submitted registers passed every data quality check, the ESAs reported. Then, in November 2025, the ESAs designated 19 critical ICT providers for direct EU oversight. They include AWS, Google Cloud, Microsoft, Oracle, SAP, IBM, Accenture and Bloomberg.

The UK took its own approach to DORA third-party risk questions in July 2026. HM Treasury designated AWS, Google Cloud, Microsoft and Oracle as the first critical third parties, with oversight by the Bank of England, PRA and FCA from 13 July. “A single failure can reverberate across the financial system,” said FCA chief executive Nikhil Rathi. Still, the regime adds to firms’ own duties rather than replacing them.

The paperwork has to find the right person

Our first respondent runs an IT services firm in Hamburg that supports a financial services client.

“I see DORA from the vendor side. My firm, hagel IT in Hamburg, supports a financial services client that was preparing its BaFin application. Their list of requirements never reached us at first, and only turned up through our support desk.

So we changed how we start. Before any such work begins, we agree a named contact and a fixed route for regulatory documents. We also say plainly that we have no ISAE 3402 report.”

Jens Hagel, Founder, kjello

His example is small but common. DORA third-party risk work often fails at the handover between a firm’s compliance team and a supplier’s support desk. His honesty on assurance matters too. DORA does not require an ISAE 3402 report, an independent audit of a service provider’s controls. However, a financial firm must still be able to audit and inspect any supplier supporting a critical function. So a supplier without such a report should expect direct audit requests instead.

Mapping the chain, testing the exit

Our second respondent works on enterprise architecture at a software development firm.

“DORA has turned vendor management from a procurement exercise into a permanent design constraint. We now map dependencies beyond our main providers, and documented visibility into critical sub-providers, such as identity verification or payment orchestration layers, is a condition for any architecture approval. That way, a failure two levels down doesn’t cause an outage for the end client.

The biggest shift is moving exit plans from documents into the architecture. We ask delivery teams to avoid proprietary lock-in, so we can test data and workload migration through simulations. That shows concentration risk is handled by workloads that can move, not just a promise in a contract.

We’ve also replaced annual audits with continuous, API-driven risk monitoring in our security operations centre. If a vendor’s public-facing systems show a critical vulnerability, our risk score triggers an automatic review of that vendor’s access.”

Sudhanshu Dubey, Delivery Manager and Enterprise Solutions Architect, Errna

His first point matches the DORA third-party risk rules. DORA’s subcontracting standards require ICT providers to track their full chain of subcontractors and report material changes. His exit point is sound too, since DORA third-party risk rules expect exit strategies for critical services to be documented and tested. However, continuous monitoring is good practice rather than a specific DORA requirement. Note also that Errna is mainly a blockchain and software developer, so these are its own engineering choices rather than a bank’s controls.

Fintechbits analysis

Why concentration risk is no longer theoretical

Recent outages show why DORA third-party risk rules exist. On 20 October 2025, an AWS outage disrupted Lloyds, Halifax and Bank of Scotland customers in the UK, Retail Banker International reported. One lawyer quoted pointed to “growing systemic risk from heavy national and sectoral reliance on a small number of hyperscale cloud providers.”

That is why DORA third-party risk rules ask firms to assess concentration risk and plan exits. A bank cannot move off a hyperscaler overnight. But it can know which services depend on one provider, and how long a switch would take. Exit planning matters in banking partnerships too, as our roundup on embedded finance compliance found.

Common misconceptions

Several claims come up often in DORA third-party risk debates. First, DORA does not apply directly to most IT vendors. It applies to financial entities, which push the duties down through contracts. Second, designation of a critical provider does not move responsibility away from the bank. Third, an assurance report such as ISAE 3402 or SOC 2 helps, but it does not replace contractual audit rights.

The same logic applies further down the stack. Fintechs that rely on a partner bank or a BaaS provider face a similar chain of dependency, as our explainer on banking-as-a-service describes. Expanding into new markets adds more links, as our piece on cross-border expansion showed.

What to watch next

Several milestones will shape DORA third-party risk work in 2027. The ESAs will update their list of critical providers each year and run their first full examinations. In the UK, the new incident and third-party reporting rules apply from March 2027, and more critical third parties may be designated. Meanwhile, national supervisors such as BaFin are reviewing registers for missing subcontractors.

Above all, both respondents point to the same DORA third-party risk lesson. Resilience depends on clear routes for information and tested plans to leave, not on a certificate filed once a year.

FintechBits covers payments, banking and fintech developments for readers in the US and UK. This article is for information only and is not financial or legal advice. Views expressed are those of the FintechBits editorial team.