DORA for Insurance Companies — Requirements and Implementation Plan

DORA — the new standard of digital resilience for insurers

The DORA regulation (Digital Operational Resilience Act) introduces unified digital operational resilience frameworks for the entire EU financial sector. For insurance companies, this means the need for systematic management of risks associated with information and communication technologies (ICT) — from core insurance and claims management systems to customer portals and broker integrations.

DORA stands out from previous regulations in its comprehensiveness: it covers five interconnected pillars that together form a coherent digital resilience framework. Each pillar requires specific actions, documentation, and evidence of implementation. For insurers accustomed to supervisory recommendations, DORA means a transition from a recommendation-based approach to a legal obligation approach — with penalties that in Poland can reach PLN 20,869,500 or 10% of an insurance undertaking’s gross written premiums (Art. 18zm of the Act on Financial Market Supervision).

Pillar 1 — ICT risk management framework

DORA requires insurers to implement comprehensive, documented ICT risk management frameworks. These frameworks must cover identification of all ICT assets supporting critical and important functions — in the insurance sector, this includes policy systems, claims management systems, actuarial systems, distribution platforms, anti-fraud systems, and customer portals.

ICT risk assessment must account for insurance-specific threat scenarios: mass leakage of policyholder data, claims system unavailability during a natural disaster, manipulation of actuarial data, claims portal takeover, and compromise of broker API integrations.

The risk management framework must be approved by the insurance company’s board and reviewed at least annually. DORA requires designating a function responsible for ICT risk management at the management level — which in practice means a CISO or person in an equivalent role with direct reporting to the board.

Pillar 2 — ICT incident management

DORA establishes a unified ICT incident management process encompassing classification, reporting, and post-mortem analysis. The insurer must implement procedures for detecting, recording, classifying, and responding to ICT incidents.

Incident classification follows criteria defined by DORA: number of affected clients/transactions, duration of unavailability, geographic scope of impact, financial losses, and criticality of affected services. Significant incidents must be reported to the financial supervisory authority within specified deadlines.

An initial report must be submitted within 4 hours of classifying an incident as major, and no later than 24 hours after becoming aware of it (RTS 2025/301). An intermediate report — within 72 hours. A final report — within one month. These deadlines require automation of detection and escalation processes — manual procedures will not meet the requirements.

For insurance companies, preparing incident scenarios that account for industry specifics is particularly important: what if the claims system is encrypted by ransomware the day after a catastrophic hailstorm? What if health insurance policy medical data is leaked?

Pillar 3 — digital resilience testing

DORA requires regular digital resilience testing at multiple levels. The testing program must include vulnerability testing (vulnerability scanning, configuration assessment) at least annually, scenario testing (incident simulations, failover tests) at least annually, penetration testing of critical systems, business continuity and disaster recovery testing, and performance and stress testing.

Financial entities identified by the competent supervisory authority (large insurance undertakings) must additionally conduct advanced TLPT (Threat-Led Penetration Testing) every three years. TLPT is an advanced form of penetration testing based on real threat scenarios, encompassing a threat intelligence phase, an attack phase (red team), and an assessment phase (purple team).

The testing program must be approved by the board and cover all ICT systems supporting critical business functions. Test results must be documented, and identified vulnerabilities must be remediated within established timelines.

Pillar 4 — ICT third-party risk management

Insurers rely on many external ICT providers: cloud platforms, core insurance system providers, integrators, data providers, and analytics platforms. DORA requires comprehensive management of risks associated with these providers.

The ICT provider register must contain a complete list of ICT service agreements, identifying providers supporting critical and important functions. For each such provider, the insurer must conduct a risk assessment considering concentration (whether multiple critical functions depend on a single provider), substitutability (whether the provider can be replaced in case of failure or breach), data and processing location, and the provider’s security incident history.

ICT provider agreements must contain DORA-required clauses: audit rights, security SLAs, incident reporting obligations, exit conditions (including migration assistance), and data location guarantees.

DORA also introduces regulatory oversight of critical third-party ICT providers (e.g., major cloud providers) — an unprecedented mechanism giving supervisory authorities direct insight into provider security.

Pillar 5 — threat information sharing

DORA encourages (but does not require) insurance companies to participate in cyber threat information sharing mechanisms. Participation in sector information sharing groups (ISACs — Information Sharing and Analysis Centers) enables early warning about new threats, sharing indicators of compromise (IOCs), and coordinating responses to sector-wide incidents.

For insurers, information sharing has an additional dimension: data on cyberattacks against insured entities can inform actuarial models and cyber insurance product pricing. Understanding the real threat landscape enables better risk pricing and insurance product design.

Implementation plan — from audit to continuous compliance

Phase 1 — Gap Analysis (months 1-2): compare current practices with DORA requirements across five pillars, identify ICT risk management gaps, assess the testing program, and review ICT provider agreements. A security audit and DORA readiness audit provide an objective assessment.

Phase 2 — Planning (month 3): develop a prioritized roadmap, budget, resource allocation, and define compliance KPIs.

Phase 3 — Implementation (months 4-9): update ICT risk management frameworks, implement incident management processes, launch the testing program, update vendor agreements, and train the board and staff.

Phase 4 — Continuous compliance (ongoing): regular testing and audits, vendor monitoring, risk assessment updates, continuous SOC monitoring, and reporting to the board and supervisory authority.

nFlo supports insurance companies in DORA implementation — from gap analysis through penetration testing and TLPT to continuous monitoring. Our experience in the financial sector enables a pragmatic, cost-effective approach to regulatory compliance.

• Cybersecurity for Insurance

What takes the longest at first implementation

Read as a plan, the five pillars look evenly weighted. Measured in working days, they are not. The framework documents and the incident procedure can be drafted in weeks. The register of contractual arrangements with ICT third-party providers takes months, because it is not a document exercise — it requires going back to every business unit, finding contracts that were signed locally, and asking providers questions they may not have been asked before.

That asymmetry is worth planning around, because the register also gates the other pillars: it determines which functions are critical, and therefore what the testing scope and the contract terms have to cover. Starting there, and treating the rest as consequences of it, is how a DORA readiness and compliance audit is normally sequenced.

Related topics

See also:

• NIS2 for hospitals — compliance