When the Digital Operational Resilience Act entered into force, most financial firms already knew it was coming. What caught many off guard was the forensic detail it demanded: not just that data stays in the EU, but that every ICT third-party arrangement can demonstrate contractual enforceability, audit rights, and sub-outsourcing transparency under European law. For one mid-sized French asset management firm with around 800 employees, the gap between what their US hyperscaler could promise and what DORA actually required was too wide to paper over.
The compliance team’s review was triggered by a straightforward question: could the existing cloud agreement satisfy Articles 28 and 30 of DORA, which set out the mandatory content for ICT third-party contracts covering critical or important functions? The answer, after examining the provider’s standard terms, was no. The contractual arrangements did not provide the audit access, exit strategy documentation, or data residency guarantees that the regulation demands in enforceable form. The firm’s portfolio risk calculation engine and client reporting pipelines, both classified as critical functions under its internal DORA mapping, were running on infrastructure where the governing law was not European and the data location was a commercial commitment rather than a legal one.
The stakes were concrete. The firm’s primary regulator, the AMF, had aligned its supervisory expectations with the European Supervisory Authorities’ joint guidelines on DORA implementation. A finding of inadequate ICT third-party risk management for a critical function would not be a paperwork issue; it would be a material supervisory risk. The firm needed to move, and it needed the replacement infrastructure to be unambiguously inside the European legal perimeter.
Mapping the workload before touching the architecture
DIVERSITY’s engagement started with a technical and compliance scoping exercise rather than an infrastructure pitch. The client’s internal teams had already completed a DORA ICT asset register, so the first task was to cross-reference that register against the actual workload topology running on the hyperscaler. The risk calculation engine ran nightly batch jobs against position data, pulling in market feeds and producing VaR and stress-test outputs that fed directly into regulatory reporting. The client reporting stack generated MiFID II-compliant documents for approximately 4,000 end clients. Both workloads had hard latency budgets and strict data-handling requirements; neither was a good candidate for a lift-and-shift to shared cloud compute.
The decision to use bare metal rather than virtualised cloud instances was driven by two factors. First, the calculation workloads were CPU-intensive and memory-bound, and the firm had already observed significant performance variance on shared hyperscaler instances during peak batch windows. Second, bare metal gave the compliance team something they could point to in a regulatory conversation: dedicated, single-tenant hardware with no hypervisor layer shared with other tenants, hosted in DIVERSITY’s MUC1 Munich facility under ISO 27001 certification and contractual terms governed by EU law.
The migration architecture
DIVERSITY provisioned a dedicated bare metal cluster at MUC1, with a secondary replication target at AMS1 Amsterdam for disaster recovery, satisfying the dual-site EU-only replication requirement the firm’s business continuity policy demanded. The network path between MUC1 and AMS1 runs entirely within DIVERSITY’s own backbone, with no transit through non-European infrastructure. Both sites are carrier-neutral and maintain direct peering with the firm’s existing connectivity providers, which meant the cutover did not require changes to the firm’s upstream network arrangements.
The migration was sequenced over eight weeks. The client reporting stack moved first, as it had a cleaner data boundary and could be validated against known output sets from the previous environment. The risk calculation engine followed, with a four-week parallel-run period during which both environments produced outputs that the firm’s quant team compared nightly. Discrepancies were investigated and resolved before the hyperscaler environment was decommissioned. DIVERSITY’s team provided the infrastructure layer and migration tooling; the firm’s internal developers retained ownership of the application code throughout.
Bare metal under EU contract law is not a performance choice, it is a compliance posture. The regulator does not care about your SLA uptime figure if the governing law sits outside its jurisdiction.
What DORA compliance actually required from the contract
The contractual side of the engagement was as important as the technical one. DORA Article 30 requires ICT third-party contracts for critical functions to include, among other things: a full description of all functions and services to be provided, the locations where data will be processed and stored, provisions on audit rights and access, and exit strategy obligations. DIVERSITY’s standard enterprise agreement for bare metal services was reviewed against the Article 30 checklist and supplemented with a DORA-specific annex covering sub-processor disclosure, data residency attestation for both MUC1 and AMS1, and a structured exit assistance commitment specifying timelines and data portability formats.
The firm’s legal team confirmed that the resulting contract was fully enforceable under EU law, with jurisdiction clauses pointing to European courts. That single change, from a US-governed agreement to a European one, resolved the core finding from the compliance review. The AMF supervisory file was updated to reflect the new ICT third-party arrangement, and the firm’s DORA ICT risk register was closed out for these workloads.
Outcomes: compliance closed, costs reduced
The migration achieved its primary objective: both critical workloads now run on EU bare metal infrastructure under contracts that satisfy DORA’s ICT third-party risk management requirements in full. The firm’s compliance team can demonstrate data residency, audit rights, and exit provisions to the AMF without qualification. The dual-site DR setup at MUC1 and AMS1 also satisfies the resilience requirements under DORA’s ICT continuity provisions, removing a secondary gap that had been flagged during the initial review.
The performance outcome was a secondary benefit that became significant. The dedicated bare metal cluster eliminated the batch-window variance the quant team had been managing around on shared cloud. Nightly risk runs that had occasionally stretched past their completion window now finish within a consistent, tighter schedule. That reliability has operational value independent of the compliance case.
The financial outcome was a 28 percent reduction in monthly infrastructure spend compared with the previous hyperscaler bill. On dedicated bare metal, the firm pays for capacity it controls rather than for a metered service with unpredictable peak costs. The saving was not the reason for the migration, but it made the business case straightforward to approve and removed any internal argument that compliance was coming at a premium.
