DORA compliance checklist: 12 steps to audit-ready

Since DORA entered application on 17 January 2025, the firms scrambling before an audit aren't usually the ones missing policies. They're the ones who wrote the policies, filed them, and now cannot produce the evidence an examiner asks for because it lives scattered across spreadsheets, shared drives, and old email threads. A supervisor doesn't want to read your incident-response policy. They want proof you classified an incident against the thresholds and hit the reporting clock.

The checklist below is built to close that evidence gap step by step, so you can walk into an audit with a live view of your programme instead of a binder.

In this article:

• DORA readiness rests on five pillars — ICT risk management, incident reporting, resilience testing, third-party risk, and information sharing — that this 12-step checklist operationalises.
• A DORA audit assesses live, verifiable capabilities and continuous evidence: classification records, reporting timelines, and maintained registers that show a programme operating week to week.
• The Register of Information and third-party requirements are where most teams underestimate the work: only 6.5% of firms passed all data-quality checks in the ESAs' dry run.
• Threat-led penetration testing applies only to designated significant entities, but every entity owes a basic annual testing programme.
• Manual, spreadsheet-based tracking is the single biggest risk to staying audit-ready between review cycles.

What is a DORA compliance checklist?

A DORA compliance checklist turns the Digital Operational Resilience Act's obligations into concrete, auditable steps a resilience team can work through and evidence. It matters because supervisors in the EU, and increasingly elsewhere, are not asking whether you have a policy. They are asking whether you can prove live operational capability across five regulatory pillars.

DORA is not a light-touch regime. The EUR-Lex summary of the regulation sets out obligations spanning governance, incident handling, testing, and third-party oversight, all backed by binding technical standards. If your programme has treated DORA as a documentation exercise, the audit is where that assumption breaks.

This page is the tactical companion to our complete DORA compliance guide, which sets out scope and timeline before you start working the steps.

What a DORA audit actually assesses

An audit under DORA tests operational capability. According to EIOPA's DORA overview, the regulation applies to 20 different types of financial entity plus in-scope ICT third-party providers, and each is expected to evidence its obligations on demand.

The volume is real. The European Supervisory Authorities logged 3,383 major ICT-related incidents in 2025 across EU financial sectors under the new reporting regime. Every one of those was a live test of whether a firm's classification and reporting chain worked under pressure.

Last-minute preparation fails for a structural reason: continuous evidence cannot be back-filled. You cannot retrospectively manufacture six months of dashboard snapshots showing your Register of Information stayed current, or reconstruct a reporting timeline you never captured. The full DORA regulation runs to 64 articles, and the evidentiary burden is spread across almost all of them.

The five pillars that structure the checklist

DORA's obligations fall into five pillars, and each of the 12 steps below maps to one or more of them. Working the pillars first stops teams treating the checklist as an arbitrary to-do list and helps them see why governance has to come before third-party mapping.

The five pillars are ICT risk management, incident reporting, resilience testing, third-party risk, and information sharing. Each is fleshed out by binding regulatory and implementing technical standards the ESAs developed. The first tranche came through the ESAs Joint Committee consultation on DORA technical standards, and a second batch of policy products followed, covering incident reporting and oversight of critical third-party providers.

How the pillars map to auditable capabilities

Each pillar has to become an inspectable artefact. The checklist's job is to turn 'ICT risk management' from an abstract obligation into a documented framework with an annual review record, and to turn 'third-party risk' into a maintained register with due-diligence trails.

Here is how the pillars line up against the steps that follow.

The 12-step DORA audit-readiness checklist

These 12 steps are grouped loosely by pillar and written so each produces a capability a supervisor could inspect. Work them in order. The early steps — governance and function mapping — feed everything downstream, and skipping them leaves the later work built on sand.

Steps 1-3: Governance and ICT risk management framework

Start with accountability, because DORA does. Article 5 of the regulation makes the management body ultimately and non-delegably responsible for the ICT risk framework. You cannot push this to IT and call it done.

1. Assign management-body responsibility. Document who on the board owns the ICT risk framework, and evidence that they approve and oversee it (Article 5).
2. Document a sound ICT risk management framework. Cover identification, protection, detection, response, recovery, and communication, with an annual review as required under Article 6, and align it to the RTS on the ICT risk management framework (Delegated Regulation 2024/1774).
3. Evidence board-level oversight. Keep minutes showing the board reviewed the framework and understood its personal-liability exposure.

A framework that was signed off eighteen months ago and never revisited is a finding waiting to happen. Auditors ask for the review record, with dates, owners, and sign-off.

Steps 4-6: Critical function mapping and business continuity

You cannot protect what you have not mapped. This is where most of the analytical work sits, and where the function-mapping step goes deeper than there is room for here.

1. Map critical or important functions to their ICT assets. Trace each function to the systems, data, and processes it depends on.
2. Build ICT business continuity plans. Business continuity is a holistic process that begins with a business impact analysis, informs your BCPs and recovery strategies, and helps you maintain critical operations during and after disruption. See Articles 11-12 on ICT business continuity; ISO 22301:2019 gives you a recognised structure and its clauses 4-10 map cleanly onto DORA's continuity expectations.
3. Link each function to its supporting third parties. This feeds directly into the Register of Information at Step 11.

Manufacturing and energy firms in scope as ICT providers, or financial firms with heavy operational-technology dependencies, tend to find the dependency mapping harder than pure-play banks. Physical process control and ICT rarely sit in the same asset inventory.

Steps 7-8: Incident classification and reporting readiness

Having an incident policy on paper is not the same as being able to classify an event and hit the clock. Supervisors want proof you can do both under load.

1. Classify incidents against the RTS thresholds. Apply the criteria in the RTS on incident classification (Delegated Regulation 2024/1772) so 'major' is a defensible, criteria-based determination backed by documented evidence at the time of classification.
2. Evidence the reporting chain. Under Article 19, an initial notification is due within four hours of classifying an incident as major and no later than 24 hours from awareness, followed by intermediate and final reports.

The CrowdStrike outage of 19 July 2024 is the case study. A faulty Channel File 291 content update to the Falcon sensor sent roughly 8.5 million Windows devices into crash loops worldwide. Banking-sector losses were estimated at $1.15 billion, the London Stock Exchange's workspace platform went down, and major banks reported disruption to online banking and ATMs. A firm that could classify that event, trigger the clock, and evidence its notifications was in a very different position from one still assembling a timeline from memory a week later.

Steps 9-10: Resilience testing and TLPT where applicable

DORA runs a two-tier testing regime. Every entity owes a baseline; only some owe the advanced tier.

1. Run the basic annual testing programme. All entities must test their ICT tools and systems annually under Articles 24-27.
2. Prepare advanced threat-led penetration testing if designated. TLPT applies at least every three years to designated significant entities and follows the TIBER-EU framework, updated in 2024 to align with DORA. Confirm your designation status before scoping anything — most firms do not fall into it.

The common mistake is over-scoping. A mid-market firm that is not designated does not need a full red-team engagement and should not burn its budget building one before checking. The TIBER-EU methodology is the reference if you are in scope.

Steps 11-12: Register of Information and ongoing evidence

The Register of Information is where readiness is won or lost. Article 28 of DORA requires you to maintain a register of all ICT third-party contractual arrangements, with pre-contract due diligence, ongoing monitoring, and documented exit strategies.

1. Build and maintain the Register of Information. Capture every ICT third-party arrangement, flag which support critical functions, and record concentration risk and exit plans.
2. Establish continuous, dashboard-based evidence. Treat evidence as a live feed the whole year, so an audit request pulls a current view rather than kicking off a fire drill.

The scale of the register problem is documented. In the ESAs' 2024 dry-run exercise, only 6.5% of nearly 1,000 firms passed all 116 Register of Information data-quality checks. Data quality is the failure mode — teams that invested effort but neglected accuracy and completeness still failed.

The Finastra breach of November 2024 shows why the register matters operationally. Unauthorised access to a Secure File Transfer Platform the London-headquartered fintech used for client operations exposed over 400GB of data affecting financial institutions worldwide. A firm with a complete register knew immediately whether Finastra sat behind one of its critical functions. A firm without one spent days finding out.

Which DORA requirements teams most often miss

Certain obligations consistently trip up small resilience teams because they demand cross-team data and continuous upkeep, with accountability spread across multiple owners. Naming them early lets you put effort where audits actually fail.

Register of Information and third-party concentration risk

Mapping every critical function to its ICT third parties is data-heavy, and almost no team gets it complete on the first pass. The concentration-risk and exit-strategy requirements under the Article 28 third-party regime are the ones most often skipped, because they require a judgement about systemic exposure that goes beyond recording supplier names and contract dates.

Third-party risk demands continuous maintenance. The US Treasury Department breach of December 2024 came through a compromised BeyondTrust identity and remote-support platform, which a Chinese state-sponsored group used to reach Treasury workstations. It was reported to CISA as a major incident on 8 December. Around the same period, CSIS recorded Chinese cyber-espionage operations up 150% overall in 2024, with attacks against financial sectors rising as much as 300%. A register that stops at your direct suppliers misses exactly the supply-chain path these intrusions exploit.

What non-compliance costs you

DORA carries a real penalty regime, and enforcement is live.

The DORA penalty regime

The numbers are set out in Articles 50-52 of the regulation. Financial entities face administrative penalties of up to 2% of total annual worldwide turnover. Critical third-party providers face fines up to €5 million, and individuals up to €1 million in personal liability.

The financial exposure is only part of it. An audit failure erodes standing with the regulator and with clients who increasingly ask about DORA posture in their own due diligence. The reputational cost outlasts the fine.

How to stay audit-ready between review cycles

The hard part of DORA is not passing one audit. It's staying continuously evidenced so you never rebuild the checklist from scratch, and this is where manual tooling breaks down first.

Continuous evidence instead of manual processes

A short operating pattern keeps the checklist current between reviews:

1. Instrument each of the 12 steps with a live evidence source (register export, test log, board-minute repository) rather than an annual document.
2. Set a monthly review cadence where owners confirm their evidence is current and flag drift before it becomes a finding.
3. Track the Register of Information against the ESA data-quality checks as a standing report, reviewed on the same monthly cycle as everything else.
4. Rehearse incident classification quarterly so the four-hour clock is muscle memory before you need it.

A dashboard that surfaces a stale register entry or an overdue test in March gives you six months to fix it before an examiner asks. Spreadsheets do the opposite: they hide the gaps until someone goes looking.

The threat picture keeps moving, which is why static evidence ages so badly. Cyber was rated the highest risk by business-continuity practitioners for both the next year and the next 5-10 years in the BCI Horizon Scan Report 2025. Evidence assembled once a year cannot keep pace with a risk that changes weekly.

If your BCM programme is the foundation you are evidencing DORA against, ISO 22301 certification gives you a recognised management-system spine that examiners understand.

Discover how Fortiv's reporting and dashboard solutions help resilience teams evidence DORA compliance without living in spreadsheets →