DORA (Digital Operational Resilience Act)

What is DORA (Digital Operational Resilience Act)?

When a bank's core banking platform goes down for 12 hours and management tells you it was "just an IT incident," the question for the engagement team is whether that incident was reported and what the regulatory consequences are. Since 17 January 2025, DORA provides the answer: every financial entity in the EU must manage and report on its digital operational resilience under a single regulation.

DORA replaces the patchwork of national ICT risk rules that previously governed financial entities in different Member States. Article 6 requires every in-scope entity to establish an ICT risk management framework covering identification, protection, detection, response, and recovery. That framework must be documented and reviewed at least once a year (Article 6.5), or more frequently if the entity's risk profile changes.

For statutory auditors, DORA matters on two levels. First, audit clients in the financial sector must now comply with DORA's requirements. An auditor assessing a bank's or insurer's going concern position needs to consider whether material DORA non-compliance creates regulatory risk (potential enforcement action, operational disruption from unmanaged ICT failures). Second, Article 6.6 requires that the ICT risk management framework be subject to internal audit by auditors with sufficient ICT knowledge. We've seen this on about half the engagements we review: the engagement team relies on internal audit's DORA work under ISA 610 without checking whether internal audit actually has the ICT competence that Article 6.6 demands. In the Netherlands, audit firms subject to Wta oversight should expect the AFM to ask how DORA compliance was factored into the risk assessment for financial sector clients.

Article 28 introduces mandatory due diligence on ICT third-party providers. Financial entities must maintain a register of all contractual arrangements with ICT providers, classified by whether the provider supports critical or important functions. National competent authorities (the AFM in the Netherlands, BaFin in Germany) collected these registers and forwarded them to the ESAs by 30 April 2025.

Worked example: Groupe Lefevre S.A.

Client: Belgian holding company with banking and insurance subsidiaries, FY2025, consolidated revenue EUR 185M, IFRS reporter. A 50-person mid-tier firm in Brussels performs the statutory audit.

Step 1: identify DORA compliance obligations in the risk assessment

During planning, the engagement partner confirms that two subsidiaries (a credit institution and an insurance undertaking) fall within DORA's scope under Article 2(1). Although the holding company itself is outside scope, the consolidated financial statements reflect the subsidiaries' regulatory exposure. DORA's four pillars (ICT risk management, incident reporting, resilience testing, third-party risk management) are mapped against the subsidiaries' disclosed compliance status.

Documentation note: record the DORA scope assessment per Article 2(1), identifying which group entities are in scope. Cross-reference the subsidiaries' DORA compliance status reports obtained from management.

Step 2: evaluate the ICT risk management framework

Lefevre's banking subsidiary reports EUR 4.2M in annual ICT spending and contracts with 38 ICT third-party providers, of which 7 support critical functions (core banking platform, payment processing, cloud infrastructure, cybersecurity monitoring). Management's Article 28 register is obtained and tested to confirm whether the classification of critical versus non-critical providers aligns with the subsidiary's own business impact assessment.

Documentation note: record the number of ICT third-party providers, the critical function classifications reviewed, whether the Article 28 register is complete and current, and any providers supporting critical functions that lack contractual provisions required by Article 30.

Step 3: assess the financial statement impact

DORA compliance costs (EUR 1.1M in FY2025 for both subsidiaries combined, covering gap assessments and system upgrades) are evaluated for correct classification as operating expenses rather than capitalised amounts. Separately, the team considers whether the risk of regulatory fines for any identified DORA gaps triggers a provision or contingent liability under IAS 37 .

Documentation note: record the expenditure classification assessment. Document whether any identified non-compliance creates a present obligation under IAS 37.14 or a contingent liability under IAS 37.86 .

This approach is defensible because the engagement team traced DORA's regulatory requirements into the risk assessment and tested register completeness, then evaluated the financial statement consequences of both compliance costs and enforcement exposure.

Why it matters in practice

• Practitioners auditing financial sector clients frequently treat DORA as an IT governance matter outside the scope of the financial statement audit. That is a SALY reflex from pre-2025 engagement planning, and it no longer holds. DORA non-compliance creates measurable financial consequences: regulatory fines up to 2% of global turnover and mandatory remediation costs that affect both asset recoverability and revenue recognition timing. ISA 315.12 requires the auditor to obtain an understanding of the entity's regulatory environment. Ignoring DORA during risk assessment leaves a gap that an engagement quality reviewer will question.
• Financial entities must maintain an Article 28 register of ICT third-party contractual arrangements. Auditors who accept management's assertion that the register is complete without testing it against the entity's actual vendor payments and IT asset inventory miss a straightforward corroborative procedure. "Appears reasonable. Waive further pursuit." is not defensible here. Incompleteness in that register carries its own regulatory consequences, and it only takes a reconciliation to the AP ledger to test it.
• What makes DORA genuinely difficult for mid-tier firms is that it demands ICT expertise that most engagement teams simply do not have in-house. You can read the regulation, but evaluating whether a client's threat-led penetration testing programme under Article 26 actually meets the TIBER-EU framework requires specialist knowledge. Too many teams paper over that gap rather than admit the competence shortfall and bring in the right expert.
• In our experience, the Article 28 register is also the single best source of information for understanding a financial client's operational dependencies. If you are doing nothing else with DORA on a financial sector engagement, reconciling that register against actual vendor payments will tell you more about the client's real risk profile than management's own risk committee slides.

DORA vs. NIS2 (Network and Information Security Directive)

For audit clients in the financial sector, DORA is the binding framework. NIS2 matters only where a client operates in both a financial and a non-financial sector. Article 1.2 of DORA establishes its lex specialis status.

Related terms

Related tools

Related reading

Frequently asked questions