DORA Audit Requirements: What Financial Institutions Need to Know

Share:

Updated

Apr 24, 2026

5 min. read

DORA Audit Requirements: What Financial Institutions Need to Know

Share:

DORA Audit Requirements: What Financial Institutions Need to Know

In this article

If you work in financial services and “DORA audit” is showing up in your inbox, here is what you actually need to understand. The Digital Operational Resilience Act (DORA), formally Regulation (EU) 2022/2554, has been fully enforceable since January 17, 2025. Regulators are now actively supervising. The question is no longer whether you need to comply. It is whether you can prove it.

What DORA Is and Why It Hits Differently

DORA is a regulation, not a directive. That one word matters enormously. A directive lets member states adapt rules to local law with some flexibility. A regulation applies identically, directly, and immediately across all 27 EU member states. No national transposition, no jurisdictional wiggle room.

Its goal is straightforward: ensure that every regulated financial entity can withstand, respond to, and recover from information and communication technology (ICT) disruptions, including cyberattacks and third-party vendor failures. Before DORA, ICT risk rules were scattered across EBA (European Banking Authority) guidelines and national frameworks. DORA replaces all of that with a single binding rulebook.

Who Is in Scope

The regulation covers 20 categories of financial entities. Banks, insurers, investment firms, payment institutions, crypto-asset service providers under MiCA (the Markets in Crypto-Assets Regulation), and trading venues are all included. So are ICT third-party providers designated as “critical” by the ESAs (European Supervisory Authorities). Non-EU vendors serving EU financial entities are not exempt if they meet the designation criteria.

Proportionality applies, meaning smaller institutions face scaled expectations. But proportionality does not mean optional. Every in-scope entity must have a documented ICT risk framework, vendor audit rights, and a resilience testing program.

The Five Pillars Auditors Will Examine

PillarWhat Regulators Look For
ICT Risk ManagementDocumented framework with board sign-off
Incident ManagementStructured reporting within strict timeframes
Resilience TestingAnnual tests; advanced TLPT for significant entities
Third-Party RiskContractual audit rights, oversight, exit clauses
Information SharingCyber threat intelligence shared with regulators

Every supervisory examination maps back to these five areas. A gap in any one of them is a finding.

The Audit Obligations That Catch People Off Guard

  • Board accountability is personal. The management body must approve the ICT risk framework, set risk tolerance levels, and ensure adequate resources. Internal audit must review the framework at least annually and report directly to the board. This cannot be fully delegated to the CISO.
  • Vendor contracts must include audit rights. Under Article 30, any contract with an ICT provider supporting a “critical or important” function must grant both your auditors and regulators the right to inspect that provider’s systems and records. A function qualifies as critical or important if its disruption would materially affect your financial performance, stability, or service continuity. Many legacy contracts do not include these clauses. If yours do not, renegotiation is not optional.
  • The register of information is a supervisory deliverable. You must maintain a detailed register of all ICT third-party arrangements. National authorities collected the first registers in early 2025. France required submission by April 15, Germany by April 11. An incomplete register with missing audit rights for critical providers is exactly what examiners look for first.

Resilience Testing: The Audit That Runs on Your Live Systems

All in-scope entities must test ICT systems supporting critical functions at least once a year. That means vulnerability assessments, network security evaluations, and scenario-based exercises, all documented with findings and remediation status. Test records are audit evidence.

For systemically important institutions, DORA adds Threat-Led Penetration Testing (TLPT) under Article 26. TLPT is an intelligence-driven red team exercise run on live production systems, simulating the real tactics of sophisticated threat actors. The institution’s own security team, the blue team, is not told the test is happening. That is the point. The goal is to measure actual detection and response capability, not a rehearsed one.

The rules for TLPT are specific. Significant entities must conduct it at least once every three years. External testers must be engaged at least once every three cycles. Third-party vendors supporting critical functions must contractually agree to participate. A purple teaming debrief, where the red and blue teams review the exercise together, is mandatory at closure. The delegated regulation governing TLPT methodology, Delegated Regulation (EU) 2025/1190, became directly applicable on July 8, 2025. Practical TLPT execution for most designated entities is expected to begin around 2027, but preparation starts now.

What Non-Compliance Actually Costs

Regulators have real tools. Financial entities face fines of up to 2% of global annual turnover. Critical ICT third-party providers face up to 1% of average daily worldwide turnover per day of non-compliance, for up to six months. Regulators can also suspend or terminate contracts between financial entities and non-compliant vendors. That is not a hypothetical. It is a live enforcement option.

Where to Start

If you are building your compliance posture right now, this is the order that makes the most sense.

First, map every ICT system and third-party service against your business functions and identify which are critical or important. That mapping drives everything else. Second, audit your vendor contracts for Article 30 compliance and renegotiate where audit rights are missing. Third, document your ICT risk framework, get the board to approve it, and schedule your first internal audit review. Fourth, build your incident reporting workflow and test it before a real incident forces you to use it cold. Fifth, complete your register of information and confirm it meets your national authority’s format requirements.

None of these steps requires perfection. Regulators in the first supervisory cycle are looking for evidence of genuine, documented effort and a clear path to correcting known gaps. What they will not accept is no engagement at all.

Share this article

Post on Linkedin
Post on Facebook
Post on X

How useful was this post?

0 / 5. 0

Explore further

  • Third-party risk management
  • Checklists
  • Guide
  • Questionnaire
  • Compliance & Regulations
  • GRC
  • Guide
  • ISO 27001