DORA (Digital Operational Resilience Act)

What is DORA (Digital Operational Resilience Act)?

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, recovery, and learning. 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. The 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. The engagement team should evaluate whether the client's internal audit function meets this competence threshold when relying on its work under ISA 610. 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. The statutory audit is performed by a 50-person mid-tier firm in Brussels.

Step 1 — Identify DORA compliance obligations in the risk assessment

The engagement partner confirms that two subsidiaries (a credit institution and an insurance undertaking) fall within DORA's scope under Article 2(1). The holding company itself is outside scope, but the consolidated financial statements reflect the subsidiaries' regulatory exposure. The team maps DORA's four pillars (ICT risk management, incident reporting, resilience testing, third-party risk management) 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

The 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). The team obtains management's Article 28 register and tests 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, and whether the Article 28 register is complete and current. Note any providers supporting critical functions that lack contractual provisions required by Article 30.

Step 3 — Assess the financial statement impact

The team evaluates whether DORA compliance costs (EUR 1.1M in FY2025 for both subsidiaries combined, covering gap assessments and system upgrades) are correctly classified as operating expenses rather than capitalised. The team also 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.

Conclusion: the 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. 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. Incompleteness in that register carries its own regulatory consequences.

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

Frequently asked questions