The Digital Operational Resilience Act made uptime, incident reporting and vendor risk a regulatory matter for EU insurers. The ideas travel better than the paperwork — here is what any insurance platform should take from it.
Since 17 January 2025, EU financial entities — insurers included — have been subject to the Digital Operational Resilience Act, a regulation that treats a technology outage the way prudential rules treat a capital shortfall: as a supervisory event, not a private embarrassment. If you run insurance infrastructure anywhere in the world, DORA is worth reading even though it will never apply to you directly, because it is the clearest statement yet of what regulators think good operational engineering looks like.
The short version: DORA covers around twenty categories of financial entity plus the ICT providers that serve them, and it organises its demands into a handful of areas — an ICT risk management framework, mandatory reporting of major incidents, resilience testing, management of third-party technology risk, sharing of cyber threat intelligence, and direct oversight of ICT providers deemed critical to the sector. None of these ideas is exotic. What is new is that they are law, with supervisors empowered to inspect and sanction.
Why a European regulation matters to a Gulf platform
Regulatory ideas migrate. Solvency-style capital rules, conduct-of-business standards and product governance requirements all started in one or two jurisdictions and spread as supervisors compared notes. Operational resilience is following the same path: the failure modes DORA targets — a cloud region going down, a vendor breach cascading through dependent firms, an unreported incident quietly eroding customer trust — are identical in Riyadh, London and Singapore.
There is also a practical channel. Insurers and reinsurers operate across borders even when regulation does not, and a carrier with European group entities will push DORA-shaped contract clauses and audit demands down to every technology partner it works with, wherever that partner sits. If your platform serves insurers, DORA-style questionnaires are already in your future.
The three ideas worth stealing
DORA runs to a dense body of technical standards, but its engineering substance compresses into three demands that any serious platform can adopt voluntarily.
- Know your dependency graph. DORA's third-party provisions exist because financial firms discovered they could not list the vendors their critical services depended on, let alone the vendors behind those vendors. Maintaining a live register of dependencies — and knowing which ones are concentration risks — is cheap compared to discovering the graph during an outage.
- Treat incidents as reportable facts, not reputational secrets. The regulation forces firms to classify incidents and report major ones to authorities on fixed timelines. The discipline this imposes — severity definitions agreed in advance, a paper trail from detection to resolution — is exactly what makes post-incident learning honest, whether or not a regulator ever reads the report.
- Test resilience before reality does. DORA mandates a testing programme, scaling up to advanced threat-led testing for significant entities. The underlying principle is that recovery procedures which have never been rehearsed are hypotheses, not capabilities.
An untested failover is a hypothesis. Regulation or no regulation, the market eventually runs the test for you.
What it means for embedded insurance specifically
Embedded distribution multiplies the dependency problem DORA worries about. A policy sold inside a checkout depends on the platform's uptime, the infrastructure layer's uptime, and the insurer's core systems — three organisations, one customer promise. When any link fails, the customer does not parse the supply chain; they experience an insurance brand that did not work at the moment of purchase.
That is why the operationally serious version of embedded insurance looks DORA-shaped even where DORA does not apply: contractual uptime commitments between platform and infrastructure, incident escalation paths agreed before launch, degradation behaviour designed in advance — what does the checkout show when quoting is down — and joint post-incident reviews rather than blame exchanges. At Yasmina we treat the sandbox-first integration path as part of this: a partner who has exercised failure cases in a sandbox before going live has already run the rehearsal DORA would ask for.
Honest limits
Two cautions. First, DORA compliance is genuinely expensive for small firms, and the cost-benefit balance for a three-person fintech is contested even inside Europe; importing its full apparatus wholesale into a smaller market would be overkill. The transferable value is the priorities, not the paperwork. Second, resilience rules mitigate operational risk; they do not eliminate it, and a compliance-complete firm can still fail badly if the culture treats the framework as documentation rather than practice.
The lesson beyond Europe is not "copy DORA." It is that regulators now consider operational failure a solvency-grade concern, and the direction of travel is global. Platforms that build the dependency registers, incident discipline and testing habits now will find the eventual local rules — whatever form they take — largely descriptive of what they already do.