In the Digital Operational Resilience Act, published in the EU’s Official Journal on 27 December 2022, the European Parliament and Council made an explicit claim about outsourcing. Under Article 28, financial entities using outside technology services “shall, at all times, remain fully responsible” for their obligations under DORA and applicable financial services law. A bank can sign a service contract. It cannot sign away those duties.
The record supports that claim. But responsibility here means regulatory accountability, not a promise of uninterrupted service or an automatic compensation award after every outage. DORA specifies who must prepare, supervise, recover and report.
Who remains responsible inside the bank?
DORA has applied since 17 January 2025. Article 5 puts responsibility for the bank’s technology risk framework on its management body. That body must define, approve and oversee the framework. It bears ultimate responsibility for managing the bank’s technology risk.
Buying cloud services does not change that allocation. Article 28 requires third-party technology risk to sit inside the bank’s overall risk framework. Banks must maintain a strategy for that risk, including a policy covering services that support critical or important functions.
Delegated Regulation 2024/1773 makes the policy more concrete. It requires responsibilities, planning, due diligence, monitoring and exit arrangements across the contractual relationship. The bank must have the skills and resources to oversee the arrangement effectively.
That is more demanding than assigning someone to manage the supplier account. The governing body remains responsible for a framework that can identify failures, contain their effects and restore operations.
What must the contract actually buy?
Article 30 requires the parties’ rights and obligations to be allocated clearly in writing. The full contract must include service-level agreements and be available in a durable, accessible format.
For technology services generally, the contract must describe the functions supplied, service and data locations, data protection requirements, and access to data after termination or supplier failure. It must also address assistance during technology incidents, at no additional cost or at a cost determined beforehand.
Services supporting critical or important functions carry additional requirements. Their contracts need precise quantitative and qualitative performance targets, relevant reporting obligations, contingency arrangements, and access, inspection and audit rights. A general promise to provide a reliable service is not the prescribed standard.
Amazon Web Services’ own shared-responsibility explanation illustrates why the boundary matters. AWS distinguishes its responsibility for security of the cloud from customers’ responsibility for security in the cloud. The customer’s tasks vary with the service selected.
That allocation describes operational work. Article 28 separately determines whether outsourcing releases the bank from its regulatory duties. It does not.
Can the bank see its dependencies?
Article 28 requires a register of information covering contractual arrangements for outside technology services. Implementing Regulation 2024/2956 supplies the standard templates. The register connects providers, contracts, services and the functions those services support.
This is not merely a procurement inventory. It gives supervisors a structured record of dependence, while requiring the bank to distinguish services supporting critical or important functions.
Article 29 then requires a concentration-risk assessment before relevant contracts are signed. The bank must consider whether a provider is difficult to replace and whether multiple arrangements depend on the same provider or closely connected providers.
Subcontracting adds another layer. Delegated Regulation 2025/532 specifies assessments and contractual conditions where subcontracted services support critical or important functions. These include the provider’s ability to select and monitor subcontractors and the bank’s ability to assess risks arising from the chain.
The consequence is concrete. A bank cannot treat its direct supplier’s name as a complete account of where its critical service depends on outside companies.
What happens when the service fails?
DORA’s recovery obligations apply to the bank, not only to the failed supplier. Article 11 requires technology business-continuity policies and response and recovery plans. Article 12 addresses backup policies, restoration procedures and recovery methods.
Delegated Regulation 2024/1774 adds requirements for the underlying risk-management framework, including continuity testing and response and recovery arrangements. A supplier’s recovery plan is therefore an input to the bank’s arrangements, not a replacement for them.
The reporting rules follow the same allocation. Article 19 requires financial entities to report major technology-related incidents to the relevant competent authority. It permits outsourcing the reporting task, but expressly leaves the financial entity fully responsible for meeting the reporting requirements.
Not every interruption qualifies as a major incident. Delegated Regulation 2024/1772 establishes classification criteria and materiality thresholds, covering factors including affected clients, duration, geographical spread, data losses and economic impact.
Delegated Regulation 2025/301 sets reporting content and time limits. Implementing Regulation 2025/302 provides the forms and procedures. The supplier may provide the technical explanation. The bank still owes the regulator the required report.
Is an exit clause enough?
No. Article 28 requires exit strategies for technology services supporting critical or important functions. Those strategies must account for provider failure, deteriorating service, disruption and risks to the function’s continued deployment.
The bank must be able to exit without disrupting its business, limiting regulatory compliance or damaging the continuity and quality of client services. DORA requires comprehensive, documented exit plans that are sufficiently tested and reviewed periodically.
It also requires identification of alternative solutions and transition plans that enable the bank to remove the contracted services and relevant data securely and transfer them elsewhere or bring them in-house.
Article 30 supports that operational requirement with a contractual one. Relevant contracts must include an adequate mandatory transition period during which the provider continues supplying services, allowing migration to another provider or an internal solution.
A termination right establishes permission to leave. An exit plan must establish how the bank can leave while continuing to operate.
Does supervising the cloud provider change this?
DORA does not leave the provider entirely outside financial supervision. Article 31 establishes designation of critical technology providers and the appointment of a lead overseer from the European supervisory authorities.
Delegated Regulation 2024/1502 details the designation criteria. They address systemic impact, the importance of the financial entities relying on the provider, support for critical or important functions, and substitutability.
Under Articles 35 and 37 to 39, the lead overseer has powers to request information, investigate and inspect. It can make recommendations addressing weaknesses. Article 42 provides for financial supervisors to require temporary suspension, or ultimately termination, of relevant services where the statutory conditions are met.
These are additional controls over the supplier, not a substitution of the supplier for the bank. Article 28’s retention of responsibility remains intact alongside the oversight regime. Neither a critical-provider designation nor direct oversight supplies the bank with its own tested recovery and exit arrangements.
What is the verdict?
Yes. A bank can outsource its technology without outsourcing responsibility for its regulatory obligations during an outage. DORA deliberately requires that result. The bank must govern the dependency, secure enforceable contractual rights, maintain recovery arrangements, report qualifying incidents and prepare a workable exit. Cloud-provider supervision adds another accountable actor. It does not remove the bank.
