DORA Compliance on OCI for Financial Services

Most financial services teams discovered the hard edge of DORA in the same way: a compliance officer arrived with a spreadsheet called the register of information and asked the cloud team to fill in fields nobody had ever tracked. Which legal entity contracts with Oracle. Which OCI regions hold which critical functions. What the substitutability assessment says. What the exit strategy is, tested and documented, not aspirational. The regulation applies in full, the supervisors are asking for the register, and the gap between what DORA demands and what most cloud estates can evidence is wide.

This article is part of our complete guide to OCI compliance and sovereignty. It is written for financial entities running, or planning to run, regulated workloads on Oracle Cloud Infrastructure, and for the architects and risk teams who have to make the paperwork true. Nothing here is legal advice. It is the practitioner view of where DORA touches an OCI estate and what to build in response.

What DORA is and who it applies to

DORA is Regulation (EU) 2022/2554, the Digital Operational Resilience Act. It entered application on 17 January 2025 and it is a regulation, not a directive, so it applies directly across the EU without national transposition. Its scope is broad: banks, insurers, investment firms, payment and e money institutions, fund managers, trading venues, crypto asset service providers, and around twenty other categories of financial entity. Crucially, it also reaches the technology supply chain. ICT third party providers that the European Supervisory Authorities designate as critical fall under a direct oversight framework, with a lead overseer, inspection powers, and penalties. The major hyperscalers, Oracle among them, sit squarely in that designation conversation.

The intent is simple to state. Financial regulators concluded that capital buffers protect against financial shocks but not against operational ones, and that a sector which runs on a handful of cloud providers needs rules about resilience, not just solvency. DORA harmonises what was previously a patchwork of outsourcing guidelines from the EBA, EIOPA, and ESMA into one binding regime with teeth.

The five pillars of DORA

DORA organises its requirements into five pillars, and it helps to see them as one system rather than five checklists, because evidence produced under one pillar feeds the others.

• ICT risk management. A documented framework, owned by the management body, covering identification, protection, detection, response, and recovery for all ICT assets, including those in the cloud.
• ICT incident reporting. Classification of incidents against harmonised criteria, with initial, intermediate, and final reports to the competent authority on fixed clocks for major incidents.
• Digital operational resilience testing. A proportionate testing programme for all entities, and threat led penetration testing at least every three years for those designated as significant.
• ICT third party risk. The register of information, contractual provisions under Article 30, concentration risk assessment, and exit strategies for every critical ICT service.
• Information sharing. Voluntary arrangements to exchange cyber threat intelligence within trusted financial sector communities.

For a cloud estate the third party pillar generates the most paperwork, the testing pillar generates the most engineering work, and the risk management pillar determines whether either of them holds together under supervisory questioning.

When OCI is a critical ICT third party provider

If a critical or important function of your business runs on OCI, then Oracle is a critical ICT third party provider in your register, and a specific set of obligations follows. Four of them dominate the work.

The register of information

Every financial entity must maintain a register of all contractual arrangements with ICT providers, flagged by whether they support critical or important functions, and submit it to the competent authority on request and through annual reporting cycles. For OCI this means mapping each contractual arrangement, each subscribed region, and each service category to the business functions it supports. Tenancy and compartment structure makes this dramatically easier or harder. An estate built on a clean landing zone with compartments aligned to business function can generate register entries almost mechanically. An estate where everything lives in the root compartment cannot, and that is one reason a regulated workload landing zone pays for itself before the first audit.

Article 30 contractual provisions

Article 30 prescribes minimum contract content for ICT services supporting critical or important functions: full service level descriptions, data processing locations, access and audit rights for the entity and its regulator, incident assistance obligations, participation in resilience testing, notice periods, and termination rights. Oracle addresses these through its financial services contract addenda. The work on your side is a clause by clause mapping of your actual signed agreement against the Article 30 list, because supervisors ask for that mapping, not for the marketing page that says one exists.

Exit strategies

DORA requires a documented exit strategy for every critical ICT service, and it must be more than a sentence promising to migrate if needed. Supervisors expect identified alternatives, a realistic transition timeline, data portability mechanics, and evidence that the strategy has been reviewed and, where proportionate, exercised. On OCI the honest version of an exit plan deals with the hard parts: Exadata workloads that have no like for like equivalent elsewhere, data egress at scale, and the Oracle licensing position that determines whether moving is commercially survivable.

Concentration risk

Article 29 requires entities to weigh ICT concentration risk before contracting: what happens if this provider fails, and is the sector wide dependence on this provider itself a risk. For Oracle centric estates the assessment cuts both ways. Concentration on OCI is real if your core banking database, your DR, and your analytics all sit with one provider. But OCI also offers genuine isolation options that change the analysis, including OCI Dedicated Region, which places the entire cloud inside your own data centre, and the EU Sovereign Cloud, which is operationally separated from Oracle's commercial regions. A concentration assessment that names these options, and explains why you did or did not use them, reads far better than one that does not.

Mapping DORA requirements to OCI capabilities

None of the five pillars is satisfied by a platform feature alone, but the platform determines how expensive the evidence is to produce. The table below maps the recurring DORA demands to the OCI capabilities that carry them.

The pattern across every row is the same. Oracle provides the control surface, certifications, and the contractual baseline, and you can verify the platform attestations through the OCI compliance certifications programme. But DORA obligations sit with the financial entity, and supervisors have been explicit that responsibility cannot be outsourced even where the work is. The platform makes evidence cheap or expensive. It never makes the obligation disappear.

Resilience testing and TLPT

Pillar three is where DORA stops being a documentation exercise. Every in scope entity needs a digital operational resilience testing programme proportionate to its size and risk profile, covering vulnerability assessments, scenario testing, and recovery exercising. Entities designated as significant must additionally run threat led penetration testing, TLPT, at least every three years, performed against live production systems by qualified testers under the TIBER EU aligned framework, with results shared with the regulator.

On OCI this has two practical consequences. First, your critical functions on OCI are in TLPT scope, which means red team activity against production cloud workloads, and that requires planning with Oracle's penetration testing policies, clean separation of compartments so testing cannot cascade, and detection engineering good enough that the exercise produces findings rather than embarrassment. Second, recovery testing must be real. A disaster recovery design that has never failed over is, in DORA terms, an untested assumption. Cross region DR on OCI is well supported and comparatively economical, and exercising it twice a year turns a paper plan into evidence. Our disaster recovery practice builds and exercises exactly these designs for regulated estates, including the evidence pack the supervisor will eventually ask for.

The subcontracting chain question

One of the least understood parts of DORA is that the obligations follow the service down the subcontracting chain. If Oracle subcontracts any material part of the ICT service supporting your critical function, your contract and your register must reflect it, and the regulatory technical standards on subcontracting require you to assess the chain before signing, not after an incident. In practice this means asking precise questions: which subprocessors touch the service, in which jurisdictions, what happens to your Article 30 rights at each link, and whether a failure two levels down can take out your critical function. For OCI the chain is shorter than for providers that resell third party infrastructure, since Oracle operates its own regions, but the question still applies to support arrangements, connectivity, and any managed service provider you place between yourself and the platform. Note the irony there: an MSP running your OCI estate is itself an ICT third party in your register, with its own Article 30 mapping and its own exit plan. Choose partners who already understand that they are part of your compliance perimeter.

A DORA implementation framework for OCI estates

Sequencing matters. Entities that start with the contract review usually stall, because the contract questions cannot be answered until the inventory exists. This is the order that works.

Where an independent specialist fits

Oracle will tell you, accurately, that OCI carries the certifications and contract frameworks a financial entity needs. What Oracle cannot do is sit on your side of the table. The register, the gap analysis, the concentration assessment, and above all the exit strategy are documents about your dependence on Oracle, and there is an obvious tension in asking the provider to author them. An independent specialist who knows OCI deeply but holds no Oracle revenue interest can map the estate honestly, say plainly where Dedicated Region or Sovereign Cloud is worth the premium and where it is not, and build the DR and logging architecture that turns obligations into evidence. That is the work we do, across 500+ OCI engagements and with 24/7/365 operational coverage behind the estates we run, and it is precisely the kind of work where independence is not a slogan but a structural requirement of the regulation itself.

DORA rewards estates that were built deliberately and punishes estates that grew by accident. If your OCI footprint is the second kind, the framework above is the route back, and the earlier you start, the cheaper every step becomes.