DORA for the Insurance Sector

Building your DORA team? Insurers hire the DORA Compliance Officer first — a verifiable certification for exactly the profile supervisors and hiring teams look for. Browse all DORA certifications.

Why DORA Matters for Insurance Companies

The insurance sector is structurally different from banking when it comes to operational resilience, but the regulatory exposure is just as significant. Insurance carriers run long-tail data — life policies sold today create obligations 30-50 years out — on technology stacks that frequently combine 1980s mainframes (still alive in many insurers), 2000s policy administration systems, modern actuarial cloud workloads, and customer-facing digital channels built in the past five years. This patchwork creates an unusual operational risk surface: legacy data dependencies, complex integration layers, and digital interfaces all needing simultaneous resilience.

Beyond technology, insurers carry highly sensitive personal data: policyholder identities, beneficiaries, health information for life and health business, accident records, financial details, and behavioural data from telematics or smart-home sensors. A material data breach or processing outage in an insurer hits regulators (DORA + GDPR + national supervisors), customers (loss of trust, claims delays), and the broader market (reputational contagion).

DORA brings this entire risk surface under harmonised supervision. EIOPA, as one of the three European Supervisory Authorities, coordinates with national supervisors (BaFin, ACPR, IVASS, DNB, MFSA, FSC, etc.) to apply DORA across insurance entities. The framework explicitly recognises Solvency II as the prudential foundation but adds binding ICT-specific obligations that go beyond what Solvency II Pillar 2 alone delivers.

DORA Scope Across the Insurance Sector

DORA applies to a broad set of insurance-sector entities, with proportionality calibrating the depth of obligations. The five main scope categories:

DORA & Solvency II: How They Interact

For insurers, the most important regulatory question after "what does DORA require" is "what changes versus what we already do under Solvency II?" The answer matters because Solvency II is the prudential pillar of EU insurance regulation; DORA is operational resilience built on top of it.

Where DORA goes beyond Solvency II

• Specific ICT risk taxonomy: Solvency II treats operational risk including ICT in aggregate (SCR.OP module). DORA forces a granular ICT-specific risk taxonomy with eight asset categories and separate KRIs.
• Mandatory incident reporting framework: Solvency II's operational risk reporting is essentially internal (ORSA) plus supervisory dialogue. DORA imposes harmonised mandatory reporting with 4h/72h/1m timelines.
• Resilience testing programme: Solvency II requires testing capital adequacy through stress tests; DORA requires testing operational resilience through vulnerability scans, scenario tests, and TLPT.
• Register of Information: A regulatory artefact with no Solvency II equivalent — single biggest data lift for most insurers.
• Direct contractual rules: Article 30 mandatory clauses go beyond the EIOPA Outsourcing Guidelines, which were guidance.

Where DORA aligns with Solvency II

• Three lines of defence (DORA Article 6 ↔ Solvency II Pillar 2 governance)
• Board-level accountability (DORA Article 5 ↔ Solvency II Articles 41-44)
• Risk management function (DORA ICT risk function ↔ Solvency II risk management function — coordination required)
• Internal audit independence (DORA Article 6(6) ↔ Solvency II Article 47)

ORSA and DORA

The Own Risk and Solvency Assessment (ORSA) is the centrepiece of Solvency II Pillar 2. EIOPA expects insurers to integrate DORA-aligned ICT risk into ORSA from the 2025 cycle onwards. Practically this means: ICT risk scenarios in ORSA stress tests, ICT capital quantification methodology, ICT risk appetite alignment with overall risk appetite, and explicit linkage between DORA register of information and ORSA outsourcing risk assessment.

Critical Insurance Systems Under DORA Scrutiny

The systems supervisors target during DORA inspections at insurers reflect the operational reality of insurance: long policy lifecycles, complex calculation engines, cross-jurisdictional data flows.

Article-by-Article Requirements for Insurers

Pillar 1 — ICT Risk Management Art. 5–16

Insurers must maintain a board-approved ICT risk management framework integrated with Solvency II governance. The framework must address all critical insurance systems (above), define risk appetite for ICT risk, and provide independent ICT risk function visibility. The RTS on ICT risk framework (Commission Delegated Regulation 2024/1774) specifies minimum content for security policies, encryption, identity management, network segmentation, change management and ICT business continuity.

Pillar 2 — Incident Management & Reporting Art. 17–23

Standardised classification under the RTS on classification, with insurer-specific application: claims processing impact, policy administration outage, fraud detection failure, actuarial system compromise. Same 4h / 72h / 1-month workflow as banking. Reporting via national supervisor portal — most insurers use the EIOPA-coordinated harmonised template.

Pillar 3 — Resilience Testing Art. 24–27

Annual programme covering critical insurance systems. Mid-size insurers typically run 4-6 deep technical assessments per year (vulnerability, penetration, scenario-based) plus continuous monitoring. Designated insurers also conduct TLPT every 3 years (see below).

Pillar 4 — ICT Third-Party Risk Management Art. 28–44

The Register of Information for insurers must capture not just hyperscaler relationships but also: policy administration vendors (Sapiens, Guidewire, Insurity, Duck Creek), actuarial platforms (FIS Prophet, Milliman AXIS, Moody's AXIS), claims technology (CoreLogic, Mitchell, Solera), reinsurance platforms, fraud detection (Shift Technology, FRISS), and underwriting workbenches.

Pillar 5 — Information Sharing Art. 45

Voluntary participation in cyber threat sharing. The European Insurance and Occupational Pensions community has established sector-specific threat-sharing mechanisms; FS-ISAC also has insurance-specific working groups.

TLPT for Designated Insurers

TLPT under Article 26 reaches the insurance sector, but with materially smaller scope than banking. Risk-based designation typically targets:

• Internationally Active Insurance Groups (IAIGs) — about 10 EU-headquartered groups
• Large life and non-life insurers above ~€20bn gross written premium
• Insurance groups with significant cross-border activity (5+ Member States)
• Selected reinsurers above significant retrocession volumes
• Industry estimate: 40-60 insurance groups in scope across the EU

Insurance-specific TLPT scoping considerations

Unlike banking where critical functions cluster around payments, trading and core banking, insurance TLPT must address a more dispersed surface. Common in-scope objectives include: simulated unauthorised access to policyholder PII at scale, fraudulent claim approval through workflow manipulation, actuarial data tampering affecting reserves, and ransomware-style impact on policy administration. Scoping conversations with NCAs typically focus on which 3-5 critical functions to test in cycle 1.

Full TLPT methodology guide →

Third-Party ICT Providers in Insurance

Insurance has a particularly long tail of specialised ICT providers, each with sector-specific functionality. The Register of Information often surfaces 200-500 distinct providers per mid-size insurer — significantly more than a comparable bank.

Common third-party categories

• Policy administration platforms: Often the single most critical relationship — vendor lock-in is real, exit strategies require 24-36 month horizons.
• Actuarial calculation vendors: Material because results feed into Solvency II SCR. Independent validation is a DORA testing requirement.
• Claims handling outsourcers (TPAs): Third-Party Administrators handling claims on behalf of insurers — both ICT relationship and operational outsourcing under EIOPA Outsourcing Guidelines.
• Cloud hyperscalers: AWS, Azure, GCP — primarily for data lakes, ML workloads, customer-facing apps. Concentration risk increasingly visible.
• Distribution platforms: Comparison websites, broker portals, embedded insurance APIs — increasingly material as digital distribution grows.
• Fraud detection providers: Increasingly ML-based, often shared between insurers (consortium models) — interesting Article 30 challenge for shared models.
• Reinsurance technology: ACORD-aligned platforms, treaty management — joint risk profile with reinsurer.

Incident Reporting for Insurers

The classification criteria (RTS on classification) apply identically across financial entities, but the manifestations are sector-specific. Incidents most commonly triggering "major" status at insurers:

• Customer portal or mobile app outage longer than 24 hours during a peak renewal period
• Claims processing system unavailability affecting more than 10% of in-flight claims
• Unauthorised access to actuarial models or pricing engines
• Data integrity incident in policy administration affecting policyholder records
• Ransomware impact on document management systems holding policy documents
• Identity provider compromise affecting agent/broker portals
• Reinsurance platform outage during a major claims event (e.g., catastrophe loss reporting)

Reporting workflow

Same harmonised template as banking. Submitted through the national supervisor portal — for most insurers this is the supervisor that authorises them under Solvency II. Cross-border groups submit at solo level to each home authority.

Full incident reporting workflow →

12-Month Insurance Implementation Roadmap

5 Insurance-Specific Implementation Pitfalls

1. Underestimating the policy administration vendor liftMost insurers run on 1-3 dominant policy administration vendors. Getting Article 30 mandatory clauses into long-standing master agreements is hard, slow, and frequently requires escalation. Plan 9-12 months for top vendors.
2. Treating ORSA and DORA as separate exercisesEIOPA expects ICT risk to be integrated into ORSA from 2025 onwards. Insurers running parallel DORA and ORSA workstreams without coordination produce duplicative artefacts that supervisors find inconsistent.
3. Missing the actuarial-system control gapActuarial calculation systems often run in spreadsheet/Python layers outside the formal IT estate. They feed Solvency II SCR — material data integrity risk. Most first-cycle DORA inspections find weak controls here.
4. Ignoring TPA and broker IT dependenciesThird-Party Administrators and brokers handle insurer data on insurer's behalf. Their ICT failures are insurer's regulatory exposure under DORA. Many insurers have not yet captured TPA technology in their registers.
5. Cyber underwriting profile vs DORA gapInsurers writing cyber insurance products often find their internal DORA maturity lags their underwriting profile assumptions — a credibility risk if their own incident becomes public.

Insurance FAQ

Further Reading