DORA third-party risk rules changed what a storage contract has to contain when the customer is a financial entity in the European Union. The Digital Operational Resilience Act, Regulation (EU) 2022/2554, has applied since 17 January 2025. It covers banks, insurers, investment firms, payment institutions and many others, and it treats their dependence on ICT providers as a risk to be managed through governance, contracts and exit planning. Storage sits squarely inside that scope whenever it supports a critical or important function.
This post explains what the regulation asks of financial entities in relation to ICT providers, how that translates into storage agreements and which architecture choices make the obligations easier to meet. It is a general overview and not legal advice.
The third-party chapter of the regulation starts with governance. A financial entity must maintain a register of information covering all its contractual arrangements for ICT services. Before entering a new arrangement it must assess whether the service supports a critical or important function and what risks follow. For arrangements that do support such functions, it must have a documented exit strategy. These duties rest on the financial entity, not the provider, and supervisors can ask for the register.
The general discipline is described under third-party risk management. What DORA adds is specificity about the contract itself.
Article 30 of the regulation sets out terms that contracts for ICT services must include. A baseline applies to every arrangement, and additional terms apply when the service supports a critical or important function.
| Contract term | Applies to | What it means for storage |
|---|---|---|
| Locations of service and data | All ICT contracts | Named countries or regions where data is stored and processed, with notice of changes |
| Access, recovery and return of data | All ICT contracts | Data returned in a usable format on insolvency, resolution or end of service |
| Termination rights and notice | All ICT contracts | Defined grounds and minimum notice periods |
| Incident assistance | All ICT contracts | Provider support when an ICT incident affects the service |
| Service level targets | Critical or important functions | Quantified availability, durability and performance commitments |
| Access, inspection and audit rights | Critical or important functions | Rights for the entity, its auditors and the authorities |
| Exit with a transition period | Critical or important functions | Continued service while data moves to another provider or in-house |
| Testing participation | Critical or important functions | Provider involvement in continuity and resilience tests |
Stating where data is stored sounds simple and often is not. A storage service may replicate to a second region, keep metadata somewhere other than the objects, send telemetry to the provider and allow support staff in other countries to connect. Each of these is a location in the sense the contract has to capture. The posts on metadata residency and storage telemetry and data boundaries explain where those less obvious flows arise, and remote support access covers the support path.
The simpler the architecture, the simpler the clause. Storage that the entity operates in its own data centers has locations the entity chose and can list. Storage consumed as a service has locations the provider chose, and the contract needs to bind them.
An exit strategy on paper is easy to write. Supervisors expect one that could actually be carried out without disrupting the function. For storage, three things decide whether that is true. The first is volume: moving hundreds of terabytes or more takes time and network capacity that has to be planned. The second is format: data held behind a standard interface such as the S3 API can be read by another system without conversion, while proprietary formats cannot. The third is cost: retrieval and egress charges can make an exit unaffordable at the moment it is needed.
The post on cloud exit planning works through these in detail. Under DORA the plan also has to be tested or at least reviewed periodically, and the transition period in the contract has to be long enough to cover the transfer time the plan assumes.
DORA created an oversight regime for ICT providers that are critical to the financial sector as a whole. The European supervisory authorities published the first list of designated critical providers on 18 November 2025. Designation puts the provider under direct oversight. It does not reduce the financial entity's own obligations, and it highlights a related concern in the regulation: concentration. When many functions depend on one provider, a single failure or a single dispute affects all of them. Entities are expected to assess that risk before contracting and to consider whether alternatives exist.
Reviews tend to follow the paper trail and then test it. They check that the storage arrangement appears in the register with the right criticality, that the contract contains the required terms, that service levels are measured and reported, and that the exit plan names a destination and a duration. They ask how deleted data is evidenced at the end of a contract, a topic covered in the post on data deletion verification. Agreed service levels should match what the architecture can deliver, which the post on storage service levels addresses.
Scality RING is software-defined object and file storage deployed on standard x86 servers that the organization owns and operates. For a financial entity, that changes the shape of the third-party relationship: the data, the hardware, the network boundary and the administrative accounts stay inside the entity, and the supplier relationship covers software and support. Locations are the entity's own sites. RING can span multiple sites, with erasure coding and replication selectable per policy.
RING exposes an S3 interface, so applications and backup software address it with a widely implemented API, which keeps data readable by other S3-compatible systems if the entity ever changes platform. It runs across hardware generations without a forklift migration, and metrics and logs are kept locally. It supports versioning and S3 Object Lock for records and backup copies that must be retained.
DORA does not prohibit any way of consuming storage. It makes the financial entity prove that it understands its dependencies and could leave them. The less a storage arrangement hides about where data is and how it comes back, the less work that proof takes.