DORA Audit: Requirements, Checklist & How to Prepare

What Is a DORA Audit?

A DORA audit is any structured review of a financial entity's compliance with the Digital Operational Resilience Act — Regulation (EU) 2022/2554 — and its 13 supplementing Regulatory and Implementing Technical Standards. The word "audit" is used loosely across the industry, and the first step to preparing properly is to recognise that it refers to three quite different exercises with different owners, triggers and consequences.

What they share is the reference standard: every DORA audit measures the entity against the same body of binding rules — the 64 articles of DORA plus the RTS/ITS. What differs is who runs the review, whether participation is mandatory, and what happens when a gap is found. A gap discovered by your own internal audit becomes a remediation action. The same gap discovered by a competent authority during a supervisory inspection becomes a formal finding — with potential capital, enforcement and reputational consequences attached.

That asymmetry is the single most important idea on this page. It is why mature institutions invest in audit readiness: the cheapest place to find a DORA gap is in a review you commissioned yourself.

The Three Types of DORA Audit

Internal Audit Requirements Under DORA Art. 6(6)

Article 6(6) is the explicit DORA mandate for internal audit. It states that the ICT risk management framework must be subject to internal audit by auditors "on a regular basis in line with the financial entity's audit plan", and that those auditors must possess "sufficient knowledge, skills and expertise in ICT risk, as well as appropriate independence".

Three obligations flow from this short sentence, and supervisors test each of them:

Competence

The auditors must genuinely understand ICT risk — not just financial or process auditing. A generalist internal audit function that ticks "ICT framework reviewed" without the technical depth to challenge encryption design, network segmentation, recovery testing or sub-outsourcing chains will itself become a finding. Many institutions co-source the technical depth: internal audit owns the plan and the opinion, a specialist firm supplies the ICT expertise.

Independence

The auditor cannot review a function they help operate or design. Internal audit sits in the third line of defence; the ICT risk function and the CISO sit in the second and first. The reporting line of internal audit must run to the audit committee / management body, not to the CIO. Supervisors check the organisational chart and the reporting lines, not just the policy.

Follow-up by the management body

Article 6(6) is not satisfied by producing a report. The management body must formally receive audit findings, decide on remediation, allocate resources and track closure. Board minutes must evidence this loop. An audit finding that sits open for three cycles with no documented management response is, in supervisory eyes, worse than the original gap — it signals a governance failure under Article 5 accountability.

Frequency

DORA sets no fixed interval — it is risk-based, governed by the audit plan. In practice: significant institutions and critical or important functions are reviewed at least annually; lower-risk areas on a 2-3 year rotation so that the whole ICT risk framework is covered within a defined cycle. The audit plan itself, and its risk-based rationale, is something supervisors will ask to see.

Supervisory Inspections: How They Work

Supervisory review under DORA is exercised by national competent authorities and, for SSM-significant banks, by the ECB Joint Supervisory Teams. It takes two forms: off-site review (analysis of submitted documentation — the Register of Information, incident reports, the resilience testing programme) and on-site inspection (a supervisory team physically reviewing controls, interviewing staff, sampling evidence).

Triggers

• Routine cycle — for banks, ICT risk is reviewed within the SREP; weaknesses can feed Pillar 2 capital add-ons.
• Thematic review — supervisors run cross-market reviews on a chosen theme (e.g. Register of Information data quality, third-party concentration).
• Incident-triggered — a major ICT incident report often prompts a focused review of the affected controls.
• Risk-based escalation — prior findings, peer outlier metrics or whistleblower information.

Powers

Under Articles 50 and related provisions, supervisors can require information, conduct on-site inspections, demand remediation within deadlines, impose administrative penalties (up to 2% of total annual worldwide turnover for entities, EUR 1 million for natural persons), issue public censure, and apply qualitative measures. For designated Critical ICT Third-Party Providers, the Lead Overseer regime adds direct ESA oversight (see third-party risk).

DORA Audit Scope by Pillar

Whether internal or supervisory, a DORA audit walks the five pillars. Use the table below as the backbone of an audit programme — each row is a testable control area with its article anchor.

Run the free 45-point DORA compliance checklist to get a fast structured read across all five pillars before you scope a formal audit.

The Evidence a DORA Audit Demands

DORA audits are evidence-driven. A control that exists but is not documented is, in audit terms, a control that does not exist. Assemble and keep current the following audit file:

• Board-approved ICT risk management framework and ICT business continuity policy, with the approval minutes
• The Register of Information in the ITS XBRL/XML format, with data-quality controls
• Incident log with classification rationale for every incident and the reports submitted for major ones
• Resilience testing programme and reports — vulnerability assessments, scenario tests, and TLPT attestation where designated
• Third-party contracts showing Article 30 mandatory clauses, plus the concentration and sub-outsourcing analysis
• Board and committee minutes evidencing active ICT risk oversight and follow-up on prior findings
• RTO/RPO test results proving recovery objectives are validated end-to-end, not just documented
• Prior internal audit reports and the management body's documented response and closure tracking

How to Prepare: DORA Audit Readiness

Audit readiness is a deliberate programme, not a scramble before the supervisor arrives. A proven sequence:

1. Scope and self-assess

Map your entity against all five pillars and the 13 RTS. The free DORA compliance checklist gives a fast structured baseline; a formal gap analysis turns it into a prioritised backlog with ownership and effort estimates.

2. Close the evidence gaps

For every control, ask "could I hand a supervisor the evidence today?" Where the answer is no, the gap is documentation, not control design — and that is the fastest category to fix.

3. Run a mock inspection

A readiness assessment that mirrors the supervisory scope, ideally run by people who have seen real inspections. It surfaces the findings a supervisor would raise — while they still cost only remediation effort.

4. Validate the recovery claims

The most common evidence failure is RTO/RPO that look fine on paper but were never tested end-to-end. Schedule and document the test before the audit, not during it.

5. Brief the management body

Article 5 accountability means the board must be able to speak to the ICT risk position. A pre-audit board briefing is a standard part of readiness work.

The 7 Most Common DORA Audit Findings

1. Incomplete Register of InformationMissing LEIs, inconsistent service taxonomy, and almost universally weak sub-outsourcing data below Tier 2. The single most frequent finding in 2025 inspections.
2. Incident classification governanceOutdated internal thresholds causing under-reporting of major incidents; no clear, empowered classification decision owner.
3. Recovery objectives not validatedRTO/RPO documented but never tested end-to-end, or tested only in isolated components rather than full failover.
4. Article 30 clauses missing from contractsLegacy vendor master agreements never re-papered with audit rights, exit, sub-outsourcing and data-location clauses.
5. Superficial board oversightICT risk reaching the board as a status colour rather than quantitative KRIs; minutes that do not evidence real challenge or follow-up.
6. Internal audit lacks ICT depthA generalist internal audit function reviewing the ICT framework without the competence to challenge it — a finding under Article 6(6) itself.
7. Open findings left unremediatedPrior audit or inspection findings carried for multiple cycles with no documented management response — read by supervisors as a governance failure.

DORA Audit FAQ

Related DORA Resources