DORA Compliance for Insurers: What Operations Teams Must Know in 2026

The Digital Operational Resilience Act — Regulation (EU) 2022/2554, universally abbreviated as DORA — became applicable on January 17, 2025. For insurance operations teams, that date has passed, but implementation work is ongoing, and the complexity of what DORA actually requires for claims-critical ICT systems is still being worked through by many firms. The purpose of this guide is to translate the regulation's five pillars into operational reality, with particular focus on what DORA means for claims platforms, third-party vendors, and the audit trail obligations that sit at the intersection of operational resilience and regulatory evidence. For a broader view of insurance compliance obligations across jurisdictions, see the Global Compliance Hub.

DORA applies to financial entities including insurance undertakings, reinsurance undertakings, and insurance intermediaries operating within the EU. It also applies to certain ICT third-party service providers that are designated as "critical" under the regulation. For insurers using cloud-based claims platforms — which now represents the majority of the market — the third-party provisions of DORA are among the most operationally significant aspects of the regulation.

Why DORA Exists and What It Is Trying to Solve

DORA was designed to address a structural problem in European financial services: firms had sophisticated frameworks for managing financial risk but inconsistent, often underdeveloped frameworks for managing the operational and cyber risks arising from their dependence on digital systems. The COVID-19 pandemic, a wave of ransomware incidents, and growing concentration risk in cloud infrastructure providers all accelerated the regulatory response.

For insurers, the particular concern is that claims processing has become almost entirely dependent on ICT systems. A claims platform outage is not a technology problem — it is a customer service failure, a regulatory risk, and a financial exposure. DORA formalises the expectation that insurers treat ICT operational resilience with the same rigour they apply to capital adequacy or conduct risk.

The Five Pillars of DORA Compliance

Pillar 1: ICT Risk Management

DORA requires insurers to establish and maintain a comprehensive ICT risk management framework. This is not a document exercise — it is a governance requirement. The framework must cover the identification, classification, protection, detection, response, and recovery dimensions of ICT risk.

Critically, DORA requires firms to identify their critical business functions and map the ICT assets — systems, data, infrastructure, third-party services — that support each function. For most insurers, claims processing is an obvious critical function. This means the claims platform, its underlying infrastructure, its integration points, and its data flows must all be documented in the ICT risk management framework.

The framework must be approved by the management body (board or equivalent). ICT risk is not delegated to IT. It is a board-level governance matter. For operations directors and CROs, this means being able to present claims platform risk exposure in terms the board can assess and approve — business continuity impact, recovery time objectives, incident history, and third-party dependency risk.

ICT risk management under DORA also requires firms to define recovery time objectives (RTOs) and recovery point objectives (RPOs) for critical business functions. For claims processing, this means answering specific questions: how long can the business operate without the claims platform? How much claims data can the business afford to lose in a disaster scenario? These parameters must be documented and tested, not merely estimated.

Pillar 2: ICT Incident Management and Reporting

DORA imposes a structured incident management and reporting framework with strict timelines that are among the most operationally challenging aspects of the regulation.

Insurers must have processes to detect, classify, and manage ICT-related incidents. The classification matters: DORA distinguishes between ICT incidents generally and "major ICT incidents" that trigger mandatory notification to the National Competent Authority (NCA). The criteria for classification as a major incident include factors such as the number of customers affected, the duration of service disruption, the geographic scope, and the economic impact.

For major incidents, the reporting timelines are tight:

• Initial notification: within 4 hours of classifying the incident as major, or within 4 hours of a firm becoming aware that an incident meets major criteria
• Intermediate report: within 72 hours of the initial notification, providing updated information on the incident status, impact assessment, and remediation actions
• Final report: within one month of the intermediate report, providing a comprehensive post-incident analysis including root cause, actions taken, and lessons learned

The 4-hour initial notification window is the most demanding. It requires firms to have automated detection capabilities, rapid classification processes, and clear escalation paths. A claims platform outage that begins at 9pm must be classified and notified by 1am if it meets the major incident threshold. Manual processes are not adequate for this timeline.

For insurers whose claims platform is operated by a third-party vendor, the incident notification chain becomes critical. If the vendor identifies an incident at midnight but does not notify the insurer until 6am, the insurer's 4-hour notification window may already have passed. DORA incident notification obligations flow down into vendor contracts — a point we return to in the third-party section.

Pillar 3: Digital Operational Resilience Testing

DORA establishes a mandatory testing programme for ICT systems. At a minimum, all in-scope firms must conduct annual testing of their ICT resilience, including vulnerability assessments, gap analyses, and scenario-based testing.

For significant firms — those that meet certain size and systemic importance thresholds — DORA requires Threat-Led Penetration Testing (TLPT) every three years. TLPT is a structured exercise in which red teams attempt to compromise systems using tactics modelled on real threat actors. It is substantially more intensive than a standard penetration test and must be conducted by approved providers using a defined methodology.

For claims operations, the testing requirement means that the claims platform and its integrations must be included in the ICT testing programme. A platform that processes policyholder data and payment instructions is a target for threat actors. The testing programme must include realistic scenarios: what happens if the claims platform is unavailable for 48 hours? What is the manual fallback? How are claims being processed during a system outage?

The claims workflow automation layer is particularly relevant here: firms that have automated claims processing to the point where manual fallback procedures are poorly defined or untested face higher resilience risk than firms that have maintained documented manual processes alongside their automation.

Pillar 4: Third-Party ICT Risk Management

This is where DORA has the most direct and immediate impact on insurance operations teams, and where many firms currently have the most significant gaps.

DORA requires insurers to maintain a comprehensive register of all ICT third-party service providers, documenting the services provided, the contractual arrangements, and the business functions each provider supports. Providers must be classified as "critical or important" based on the nature and scale of the services they provide. A cloud-based claims platform that processes all policyholder claims is, by any reasonable assessment, a critical ICT service.

For providers classified as critical or important, DORA requires:

• Enhanced due diligence before engagement and on an ongoing basis
• Contractual provisions that meet DORA's specific requirements (see below)
• Exit strategies that allow the insurer to migrate away from the provider without unacceptable disruption
• Business continuity arrangements that account for provider failure or disruption
• Regular review of the provider's resilience and security posture

DORA also establishes an oversight framework for ICT providers that are designated as "critical" at the EU level by the European Supervisory Authorities. These providers are subject to direct regulatory oversight. Insurers using designated critical ICT providers must cooperate with regulatory examinations of those providers.

Pillar 5: Information Sharing

The fifth pillar of DORA establishes a voluntary framework for sharing cyber threat intelligence and information across the financial sector. Insurers are encouraged, though not required, to participate in information-sharing arrangements. The rationale is systemic: a threat actor exploiting a vulnerability in one insurer's claims platform is likely targeting the same vulnerability across the sector. Early sharing of threat intelligence benefits the entire market.

In practice, many insurers are beginning to engage with sector-specific information sharing bodies, including Insurance-ISAC and national cybersecurity agencies. Operations teams should be aware of these arrangements and ensure their incident response processes include intelligence-sharing steps where appropriate.

Audit Trail and Logging Requirements Under DORA

DORA does not contain a single, explicit article that reads "audit logs must be immutable." What it does require is that ICT systems supporting critical functions maintain logs that are sufficient to reconstruct events, detect anomalies, and support incident investigation and regulatory review. The integrity of those logs is implied by their purpose: a log that could have been altered is not a reliable basis for incident reconstruction or regulatory evidence.

For claims operations specifically, DORA's logging requirements mean:

• The claims platform must maintain sufficient operational logs to support incident reconstruction — what was the state of the system before the incident, during it, and after?
• Log retention must meet the timeframes relevant to incident investigation and regulatory review — in practice, a minimum of five years for records relating to critical functions is prudent
• Log integrity must be demonstrable — the insurer and regulator must be able to verify that logs have not been altered
• Logs must be accessible to regulatory authorities on request

The audit trail system at the claims platform level must therefore provide not just a record of claims decisions but a technically verifiable operational log that meets DORA's incident reconstruction standard.

What DORA Requires in Claims Platform Vendor Contracts

DORA Article 30 specifies the minimum contractual provisions required for contracts with ICT third-party service providers of critical or important functions. For operations teams reviewing or renegotiating claims platform contracts, the following provisions are mandatory:

• A clear description of the services provided and service levels, with financial penalties for breaches
• Data location — the contract must specify where data is stored and processed, and any countries involved
• Incident notification provisions — the vendor must notify the insurer of incidents within timeframes that allow the insurer to meet its own DORA reporting obligations
• Right of access and audit — the insurer and, where relevant, regulators must have the right to audit the vendor's operations and systems
• Business continuity provisions — what happens if the vendor is unable to deliver services? What are the insurer's remedies?
• Exit and data portability provisions — the insurer must be able to migrate to an alternative provider without losing data or operational continuity
• Cooperation with regulatory oversight — the vendor must cooperate with regulatory examinations

Many existing claims platform contracts predate DORA and do not contain these provisions. Insurers should prioritise contract remediation as part of their DORA compliance programme. A contract renewal is an opportunity; a regulatory review before contract remediation is a risk.

Common DORA Compliance Gaps in Claims Operations

Based on the structure of the regulation and the operational realities of insurance claims, the most common gaps in DORA compliance for claims operations are:

No Comprehensive ICT Asset Register Including Claims Platform

Many insurers have an IT asset inventory but not a structured ICT risk register that documents the claims platform, its data flows, its integration dependencies, and its classification as a critical ICT service. The claims platform is often treated as a technology vendor relationship rather than a critical operational infrastructure element with formal risk classification.

No Incident Response Playbook for Claims Platform Outages

DORA requires documented incident response processes. Most insurers have general cyber incident response plans, but a specific playbook for claims platform outages — including the DORA notification timelines, manual fallback procedures, and customer communication protocols — is often absent. A claims platform outage has different characteristics and consequences from a general IT incident, and the response playbook should reflect this.

No Formal Business Continuity Testing of Claims Processing

DORA requires resilience testing that includes realistic scenarios. For claims processing, this means testing what happens when the claims platform is unavailable. Many insurers have never formally tested their manual fallback for claims processing. The result is that RTO and RPO figures for claims processing are aspirational rather than tested. A DORA examination will probe whether RTOs have been validated by actual testing.

No Contractual DORA Provisions in Vendor Agreements

As noted above, many claims platform contracts predate DORA and lack the mandatory provisions. The right to audit, incident notification SLAs, data location specifications, and exit provisions are often absent or inadequate. Insurers that have not updated their claims platform contracts since January 2025 are likely non-compliant with DORA's third-party provisions.

Inadequate Log Integrity for Incident Reconstruction

DORA's incident reconstruction requirement implies log integrity. Firms whose claims platforms maintain mutable audit logs — where records could be altered without detection — cannot demonstrate that their incident reconstruction capability meets the DORA standard. Claims automation platforms must provide verifiable, tamper-evident operational logs as a baseline.

How Regure Supports DORA Compliance

Regure was designed with regulatory compliance as a core architectural requirement, not a retrofit. Several aspects of the platform's design are directly relevant to DORA compliance for insurers:

Data residency: Regure offers EU data residency options with documented data location, supporting the contractual requirements of DORA Article 30.

Incident notification: Regure's operational monitoring and incident notification processes are designed to provide customer notification within timeframes that support DORA's 4-hour initial notification window. Contractual incident notification SLAs are available.

Audit log integrity: Regure's append-only, cryptographically chained audit trail provides the log integrity required for DORA incident reconstruction. Every operational event is permanently recorded and verifiable.

Right of audit: Regure's contractual arrangements include right-of-audit provisions for insurers and, where required, their regulators.

Exit and data portability: Regure maintains documented exit procedures and data portability capabilities, supporting DORA's exit strategy requirements.

Business continuity: Regure's platform maintains documented RTO and RPO commitments, supported by regular testing and audit documentation.

A Practical DORA Action Plan for Claims Operations

For operations teams working through their DORA compliance programme, the following sequence reflects both regulatory priority and practical achievability:

1. Map the claims platform and all related ICT dependencies into your ICT risk register. Classify the claims platform as critical or important.
2. Review existing claims platform contracts against DORA Article 30 requirements. Identify gaps. Prioritise contract remediation.
3. Develop and document a claims platform outage incident response playbook with DORA notification timelines built in.
4. Conduct a formal business continuity test for claims processing that validates your RTO and RPO assumptions.
5. Verify that your claims platform's audit and operational logs meet DORA's integrity and retention requirements.
6. Ensure your claims platform vendor can provide documentation of their own DORA compliance posture, including security testing, incident response, and business continuity.

DORA represents a structural shift in how the EU regulates digital operational resilience — and claims processing sits squarely within its scope. Firms that treat DORA as a documentation exercise rather than an operational reality will find that regulatory examinations expose the gap. The firms that are best positioned are those whose claims platforms have resilience, auditability, and incident response built into their architecture.

To understand how Regure's claims automation platform supports your DORA compliance programme — including audit trail integrity, incident notification, contractual provisions, and data residency — book a demo. Our team includes compliance specialists who can walk you through the specific DORA requirements and how the platform addresses each one.