DORA for Insurance: Why Pillar I Hits Differently for Underwriters

The Insurance Blind Spot

When the Digital Operational Resilience Act entered application on January 17, 2025, the initial wave of compliance activity concentrated on banking. The ECB's 2024 cyber resilience stress test of 109 directly supervised banks dominated headlines. The EBA's RTS and ITS publications targeted credit institutions first. And most DORA implementation guides were written by banking consultants, for banking audiences.

This left insurance in a regulatory blind spot — not because DORA excludes insurance, but because the industry assumed that proportionality meant deferral. It does not. DORA Art. 2(1) explicitly scopes in insurance undertakings, reinsurance undertakings, institutions for occupational retirement provision (IORPs), and insurance intermediaries meeting specific thresholds. EIOPA, not the EBA, is the designated competent authority for supervising these entities' DORA compliance — and EIOPA has made clear that it expects substantive implementation, not checkbox exercises.

The proportionality principle in Art. 4 scales requirements to size, risk profile, nature, scale, and complexity of services. Art. 16 provides a simplified ICT risk management framework for entities that meet certain criteria. But proportionality does not eliminate obligations — it calibrates them. A mid-size insurer with 50,000 policyholders and a fully digital claims platform has a fundamentally different ICT risk profile than a Tier 1 bank, but its customers are no less harmed when a ransomware attack freezes claims processing for two weeks.

Why Insurance ICT Risk Is Structurally Different

The banking sector's ICT risk centers on transaction processing: payments, settlement, trading. Downtime means money stops moving. Insurance ICT risk operates on a different axis: data intensity, long-tail liability, and actuarial dependency.

Underwriting Systems as Critical Functions

Under DORA Art. 3(22), a critical or important function is one "the disruption of which would materially impair the financial performance, the soundness or the continuity of services and activities" of the financial entity. For insurers, this maps directly to:

Policy administration systems. The system of record for all active policies. Downtime means no new policies can be issued, no renewals processed, no endorsements applied. For a large commercial insurer processing 500+ endorsements daily, even 24 hours of downtime creates a backlog that takes weeks to clear.

Claims management platforms. Claims are the product. When a natural disaster hits and 10,000 policyholders file claims simultaneously, the claims platform is the critical function — not an ancillary system. Art. 11's response and recovery requirements must be calibrated to peak claims scenarios, not average daily volumes.

Underwriting engines. Modern underwriting relies on real-time data feeds (credit scores, property valuations, weather data, IoT telemetry) processed through algorithmic pricing models. An underwriting engine outage does not just delay quotes — it blinds the insurer to risk selection, potentially leading to adverse selection if manual workarounds bypass pricing controls.

Actuarial computation platforms. Solvency II requires quarterly actuarial valuations. The computational infrastructure supporting these valuations — often running on dedicated HPC clusters or cloud-based compute farms — is an ICT dependency that directly supports regulatory capital calculations. A compromise of actuarial models creates solvency reporting risk.

The Proportionality Decision Tree

Art. 4 states that financial entities shall implement DORA requirements "taking into account their size and overall risk profile, and the nature, scale and complexity of their services, activities and operations." Art. 16 goes further, providing a simplified ICT risk management framework for specific entity types.

The practical question is: which requirements apply at which calibration?

The key insight: the ICT third-party risk register (Art. 28(3)) applies to all in-scope entities regardless of size. There is no proportionality carve-out for the register. Every insurer, regardless of whether it qualifies for Art. 16 simplified treatment, must maintain and report its register of ICT third-party arrangements supporting critical or important functions.

This is where insurance compliance teams consistently underestimate the effort. A typical mid-size insurer has 40-80 ICT third-party relationships, many of which are industry-specific: claims adjusting networks, reinsurance platforms, broker management systems, telematics data providers, catastrophe modeling services, and InsurTech partners providing embedded insurance capabilities.

Insurance-Specific ICT Risk Mapping

DORA Art. 5(1) requires financial entities to have "a sound, comprehensive and well-documented ICT risk management framework." For insurers, this framework must address risks that banks rarely encounter.

The Reinsurance Chain

Reinsurance is a third-party ICT dependency that has no banking equivalent. A primary insurer ceding risk to a reinsurer depends on electronic data interchange (EDI) for treaty management, claims bordereaux, and premium accounting. If the reinsurance platform fails during a catastrophe event — precisely when reinsurance recovery matters most — the primary insurer faces both operational disruption and potential solvency pressure.

Art. 28(1)(a) requires financial entities to identify and assess risks "arising from contractual arrangements on the use of ICT services." Reinsurance treaty administration increasingly operates through shared platforms (e.g., Sequel, ACORD messaging). These platforms are ICT third-party service providers under DORA, even though the underlying relationship is reinsurance, not technology.

Claims Supply Chain

A motor insurance claim involves the policyholder, the insurer's claims team, an approved repairer network (connected via claims platform APIs), a telematics provider (if usage-based), a fraud detection system (often third-party), and potentially a legal services provider. Each link in this chain is an ICT dependency. Under Art. 28, the insurer must assess and manage each of these dependencies — and under Art. 30, contractual provisions must address security requirements, data access, exit strategies, and audit rights.

Actuarial Model Integrity

Solvency II's Own Risk and Solvency Assessment (ORSA) depends on actuarial models. These models increasingly run on cloud infrastructure and consume external data feeds. A compromise of actuarial model integrity — whether through data manipulation, unauthorized parameter changes, or infrastructure failure — creates regulatory capital risk. Art. 9(1) requires protection and prevention measures for ICT systems that, for insurers, must explicitly cover actuarial computation infrastructure.

The EIOPA Supervision Dimension

EIOPA has been explicit about its DORA expectations for insurance. In its 2024 supervisory convergence work programme, EIOPA flagged digital operational resilience as a priority area, noting that insurance entities' ICT risk management maturity varies significantly across member states.

The practical implication: NCAs supervised by EIOPA will apply DORA with insurance-sector specificity. Questions will target:

• Claims processing resilience. What is the maximum tolerable disruption for claims processing? What happens during a catastrophe event when claims volumes spike 10-50x above normal?
• Actuarial system integrity. How are actuarial models protected against unauthorized modification? What is the recovery plan for actuarial computation infrastructure?
• Broker/intermediary chain. How does the insurer assess ICT risks in its distribution chain, particularly for intermediaries that handle customer data and premium collection?
• Legacy system risk. Insurance has some of the oldest core systems in financial services. Many policy administration systems run on mainframes or legacy platforms with limited vendor support. Art. 7(2)(d) specifically references the need to account for "the age of ICT systems and supporting infrastructure."

Building the Insurance DORA Framework

Step 1: Map Insurance-Specific Critical Functions

Do not start with the IT asset register. Start with the insurance business: what functions, if disrupted, would materially impair policyholders, solvency, or regulatory standing? For most insurers, the critical function hierarchy is:

1. Claims processing and payment (policyholder impact)
2. Policy administration and renewal (revenue and coverage continuity)
3. Underwriting and pricing (risk selection and financial soundness)
4. Regulatory reporting — Solvency II, EIOPA, NCA (compliance continuity)
5. Reinsurance treaty management (solvency and capital protection)

Step 2: Calibrate RTO/RPO to Insurance Timelines

Banking RTOs are measured in minutes to hours (payment systems, settlement). Insurance RTOs should be measured against business-relevant timelines: claims processing SLAs (typically 5-15 business days for standard claims, 24-48 hours for emergency first-notification-of-loss), regulatory reporting windows (quarterly for Solvency II), and peak event scenarios (24-hour surge capacity for catastrophe claims).

Step 3: Build the Insurance Third-Party Register

Map every ICT service provider in the insurance value chain — not just IT vendors. Include claims adjusting networks, reinsurance platforms, broker management systems, telematics providers, catastrophe modelers, medical networks (for health/life), legal services platforms, and InsurTech partners providing embedded capabilities.

Step 4: Test Against Insurance Scenarios

Art. 25 testing must use scenarios relevant to insurance. A scenario where the core claims platform fails during a major weather event is more relevant than a generic DDoS test. A scenario where the actuarial computation platform is compromised two weeks before the Solvency II quarterly valuation deadline tests both recovery capability and regulatory reporting continuity.

The Proportionality Trap

The most dangerous misreading of DORA for insurance is that proportionality means "less work." It means different work — calibrated to insurance-specific risks, timelines, and dependencies. An insurer that applies banking-derived DORA templates without adaptation will comply on paper while missing the actual risks. An insurer that uses proportionality as a justification for minimal effort will face pointed questions from its NCA when the next catastrophe event reveals that its claims platform has a 72-hour recovery time and no documented impact tolerance.

DORA's value proposition for insurance is not compliance for its own sake. It is the structured governance of ICT risks that, if unmanaged, can delay claims payments to policyholders, compromise actuarial integrity, or create solvency reporting failures. For an industry built on the promise to pay, operational resilience is the promise made real. For more on the proportionality debate across financial services, see our proportionality practical lessons analysis.

---

This guide reflects DORA Regulation (EU) 2022/2554, EIOPA supervisory expectations, and Solvency II framework interactions as applicable in 2025. Specific NCA implementation may vary by member state.

---