Digital Operational Resilience Act (DORA)

What the authority establishes

A harmonized digital-operational-resilience regime for EU financial entities. Chapter V requires ICT third-party risk to be managed within the ICT risk framework and includes strategy, contractual, concentration, register-of-information, criticality, exit, and oversight provisions.

DORA turns ICT supplier dependency into a structured, reportable resilience obligation. Buyers need complete contractual inventories, service and critical-function mappings, concentration views, subcontractor information, ongoing monitoring, tested exit strategies, and auditable evidence. The ESAs began oversight of designated critical ICT third-party providers after the first 2025 designation cycle.

The record is written for operational interpretation, not legal advice. Applicability depends on entity type, jurisdiction, relationship, service, data, criticality, contractual commitments, and later authority guidance.

Who should read it

The primary audiences named in this review are EU banks, insurers, investment firms, payment institutions, and other in-scope financial entities, group risk, operational-resilience, ICT-risk, procurement, and legal teams, ICT third-party service providers serving EU financial institutions, outsourcing and vendor-management teams. Those roles may divide responsibility differently, but the operating record should still show scope, accountable ownership, evidence, review, exceptions, and the final decision.

Third-party lifecycle implications

ICT Third-Party Strategy

Teams should determine what this authority expects at the ICT third-party strategy stage, which function owns the judgment, what evidence must be retained, and what later change would reopen the record.

Pre-Contract Risk Assessment

Teams should determine what this authority expects at the pre-contract risk assessment stage, which function owns the judgment, what evidence must be retained, and what later change would reopen the record.

Contracting

Teams should determine what this authority expects at the contracting stage, which function owns the judgment, what evidence must be retained, and what later change would reopen the record.

Register Maintenance

Teams should determine what this authority expects at the register maintenance stage, which function owns the judgment, what evidence must be retained, and what later change would reopen the record.

Ongoing Monitoring

Teams should determine what this authority expects at the ongoing monitoring stage, which function owns the judgment, what evidence must be retained, and what later change would reopen the record.

Concentration Analysis

Teams should determine what this authority expects at the concentration analysis stage, which function owns the judgment, what evidence must be retained, and what later change would reopen the record.

Incident And Resilience Management

Teams should determine what this authority expects at the incident and resilience management stage, which function owns the judgment, what evidence must be retained, and what later change would reopen the record.

Exit And Transition

Teams should determine what this authority expects at the exit and transition stage, which function owns the judgment, what evidence must be retained, and what later change would reopen the record.

Capabilities that may support the work

These links identify relevant operating capabilities; they do not state that any product creates compliance.

Intake And Inventory

establishing an accountable record of relationships, products, owners, and critical services. Buyers should test the workflow against their own scope and evidence requirements.

Inherent Risk Tiering

using relationship context to determine proportional diligence and review. Buyers should test the workflow against their own scope and evidence requirements.

Due Diligence And Assessments

collecting and reviewing evidence before and during a relationship. Buyers should test the workflow against their own scope and evidence requirements.

Evidence Collection

preserving source material, responses, and reviewer context. Buyers should test the workflow against their own scope and evidence requirements.

Continuous Monitoring

bringing material external and internal change into an owned response workflow. Buyers should test the workflow against their own scope and evidence requirements.

Issue Remediation

assigning findings, deadlines, exceptions, and closure evidence. Buyers should test the workflow against their own scope and evidence requirements.

Fourth-Party Visibility

identifying and explaining important downstream dependencies. Buyers should test the workflow against their own scope and evidence requirements.

Regulatory Mapping

connecting program records to obligations and examination needs. Buyers should test the workflow against their own scope and evidence requirements.

Reporting

turning program activity into operator, executive, and board-ready information. Buyers should test the workflow against their own scope and evidence requirements.

Offboarding

closing access, data, evidence, and residual obligations when a relationship ends. Buyers should test the workflow against their own scope and evidence requirements.

What software cannot decide

Software can structure records, route work, preserve evidence, surface change, and support reporting. It cannot determine legal applicability, set risk appetite, negotiate accountable contract terms, validate every external claim, accept residual risk, or make management responsible for an outcome. Those remain organizational decisions.