DORA: Operational Resilience Evidence Requirements for EU Financial Entities

The Digital Operational Resilience Act represents a fundamental shift in how the EU regulates operational resilience in financial services. Where previous frameworks treated resilience as an adjunct to other compliance programs, DORA treats it as a standalone regulatory obligation with its own documentation standards, testing requirements, and supervisory enforcement mechanism.

For financial entities that were already operating under ISO 27001, SOC 2, or national cybersecurity regulations, DORA adds a layer of specificity that those frameworks do not fully address. For entities building their resilience programs from scratch, DORA sets a standard that is more demanding and more specific than most have encountered before.

This page covers what DORA requires, the four pillars of a compliant evidence program, where organizations consistently fall short, and what supervisory authorities examine when they review compliance.

What DORA Requires: The Four Evidence Areas

DORA's operational resilience requirements organize around four areas that together define what a compliant program must produce. Each area has specific documentation obligations that go beyond the policy level.

ICT Risk Management

Covered entities must maintain a comprehensive ICT risk management framework that identifies, classifies, and documents the ICT risks the entity faces. The framework must be current, reviewed regularly, and capable of being presented to supervisory authorities on request. An ICT risk register that was populated once and never updated does not satisfy this requirement.

ICT Third-Party Register

DORA introduces a specific requirement that distinguishes it from most other frameworks: a register of all ICT third-party arrangements. The register must document the nature of each arrangement, the services provided, the data involved, and the criticality of each provider to the entity's operations. This register is not optional for critical arrangements only. It applies to all ICT third-party relationships, and regulators can request it at any time.

Digital Operational Resilience Testing

DORA requires entities to conduct regular digital operational resilience testing. For significant entities, this includes threat-led penetration testing conducted by qualified external testers. For all covered entities, testing must produce documented outputs that are retained and available for supervisory review. The test happened is not sufficient. The test produced a record is what DORA requires.

Critical Third-Party Provider Oversight

DORA establishes a supervisory framework for critical ICT third-party providers, and it requires covered financial entities to demonstrate that they have assessed, monitored, and maintained oversight of their relationships with those providers. For entities relying on major cloud providers, core banking platforms, or other systemically important technology vendors, this oversight must be documented and current.

Where Organizations Consistently Fall Short

The gaps in DORA compliance programs follow predictable patterns. They are not the result of organizations ignoring the regulation. They are the result of organizations underestimating how specific DORA's evidence requirements are compared to the frameworks they were previously operating under.

The most common gap is the ICT third-party register. Organizations that have vendor management programs built around contract documentation and periodic reviews have the foundation of a register but not the structure DORA requires. The register must capture the operational dependencies, data flows, and criticality assessments that most existing vendor management programs do not formally document.

The second gap is testing documentation. Organizations that conduct tabletop exercises, scenario reviews, and resilience assessments frequently do not retain the structured outputs those exercises produce. DORA's testing requirements are satisfied by the documentation, not by the exercise itself. An organization that can describe its testing program but cannot produce records from it has a significant compliance gap.

The third gap is currency. DORA requires documentation that reflects the current state of the entity's ICT environment, vendor relationships, and risk posture. Organizations that built their initial compliance documentation in 2023 or early 2024 and have not maintained it through technology changes, new vendor relationships, or organizational shifts are operating with stale records that supervisory reviews will identify.

See also: DORA Requirements: How to Create Operational Resilience Evidence That Holds Up and Why Policies Fail Audits: The Missing Evidence Layer.

How DORA Relates to Other Frameworks

Organizations operating under ISO 27001, SOC 2, NYDFS Part 500, or SEC Regulation S-P will find overlapping requirements in several areas. The business continuity and vendor oversight documentation that satisfies NYDFS or SOC 2 provides a foundation for DORA compliance. But DORA adds specificity that those frameworks do not require.

The ICT third-party register has no direct equivalent in ISO 27001 or SOC 2. DORA's threat-led penetration testing requirements go beyond what either framework mandates. The critical provider oversight framework is DORA-specific and requires documentation that most organizations have not previously needed to produce.

The most efficient path for organizations operating under multiple frameworks is to build documentation that satisfies the most specific requirement in each area. For third-party risk, that is DORA's register requirement. For testing, that is DORA's documented output requirement. Documentation built to that standard satisfies the equivalent requirements in ISO 27001, SOC 2, and NYDFS without additional work.

See also: Business Continuity and Vendor Risk Evidence Across Frameworks and How to Align Operational Risk Documentation with Regulatory Requirements.

What Supervisory Authorities Examine

DORA supervision operates at the national level through each EU member state's competent authority, with the European Supervisory Authorities playing an oversight role for critical ICT third-party providers. When supervisory authorities examine a covered entity's DORA compliance, the requests follow a consistent pattern.

Authorities request the entity's ICT risk management framework documentation, its ICT third-party register, testing outputs from the most recent resilience testing cycle, and evidence of ongoing monitoring of critical third-party providers. They evaluate whether the documentation reflects the current state of the entity's operations, whether testing outputs are substantive rather than perfunctory, and whether the third-party register is comprehensive rather than limited to major vendors.

The supervisory standard is not perfection. Authorities are looking for programs that are real, maintained, and demonstrably operational. A program with identified gaps and a documented remediation plan is more defensible than one whose documentation suggests it was assembled in response to a supervisory inquiry.

Frequently Asked Questions