DORA ICT Risk for Financial Auditors: What You Need to Know

You’ve audited a mid-tier insurance company for four years. The IT environment section of your risk assessment looks the same as last year: a paragraph about the ERP system, a line on access controls, a note about backups. Since 17 January 2025, that file is no longer defensible. Your client now operates under a regulation that dictates exactly how they must manage, test, report, and govern ICT risk, and your risk assessment needs to reflect it.

DORA (Regulation (EU) 2022/2554) requires financial entities to maintain a documented ICT risk management framework, report major ICT incidents to regulators within hours, conduct operational resilience testing, maintain a register of all ICT third-party service providers, and share cyber threat intelligence with industry peers. For statutory auditors, DORA doesn’t change what ISA 315 (Revised 2019) requires, but it changes the environment your client operates in, and that changes both your risk assessment and your evaluation of internal controls.

What DORA actually requires from your client

DORA applies to 20 categories of financial entity: banks, insurance and reinsurance companies, investment firms, payment institutions, crypto-asset service providers, central securities depositories, and others listed in Article 2(1). If your client holds a licence from DNB, the AFM, or any other EU financial supervisor, they are almost certainly in scope. Microenterprises get a simplified framework under Article 16, but the core obligations still apply.

The regulation is structured around five pillars. Each one creates obligations your client must now meet, and each one produces documentation, controls, governance arrangements, and reporting obligations that affect your audit.

Pillar 1: ICT risk management

Article 6 requires every in-scope entity (except microenterprises) to maintain a documented ICT risk management framework, reviewed at least annually and after any major incident. The framework must cover identification, protection, detection, response, and recovery. Article 6(4) requires a dedicated control function for ICT risk, segregated from first-line operations using a three-lines-of-defence model. Article 6(6) requires internal auditors with sufficient ICT knowledge to audit the framework on a regular cycle.

Pillar 2: Incident reporting

Articles 17 to 23 require financial entities to classify ICT incidents by severity and report major ones to their competent authority. The initial notification must go out within four hours of classification.

Pillar 3: Digital operational resilience testing

Articles 24 to 27 require a testing programme that includes vulnerability assessments, network security testing, and scenario-based tests. For entities identified as significant, Article 26 mandates threat-led penetration testing (TLPT) at least every three years. This is a substantial investment for mid-tier entities, and your client may be grappling with how to scope it.

Pillar 4: ICT third-party risk management

Articles 28 to 30 require financial entities to maintain a complete register of all contractual arrangements with ICT third-party service providers. This register must be available at entity, sub-consolidated, and consolidated levels (Article 28(3)). Contracts with providers supporting critical or important functions must include specific provisions on audit rights, data access, exit strategies, and subcontracting limits. The ESAs collected these registers from national authorities by 30 April 2025.

Pillar 5: Information sharing

Article 45 encourages (but does not mandate) financial entities to participate in cyber threat intelligence sharing arrangements.

Why this changes your ISA 315 risk assessment

ISA 315 (Revised 2019) requires you to obtain an understanding of the entity’s IT environment as part of your risk assessment (ISA 315.26(d)). That understanding must be sufficient to identify risks of material misstatement arising from the entity’s use of IT. Before DORA, a financial entity’s ICT governance might have been a patchwork of internal policies and sector guidance from DNB or the AFM, shaped by whatever the entity’s own risk appetite dictated. DORA replaces that patchwork with a single, prescriptive framework.

This matters for your file in two ways.

First, your client now has a mandated control environment for ICT. If they are non-compliant, that is a control deficiency you must evaluate under ISA 265. The consequences of DORA non-compliance include fines of up to 2% of total annual worldwide turnover (or up to 1% of average daily worldwide turnover for ongoing breaches), contract terminations ordered by regulators, and personal liability for management bodies. A material DORA non-compliance could affect the entity’s ability to continue operating, which connects to your ISA 570 going concern assessment.

Second, DORA produces audit-relevant documentation that did not previously exist. The ICT risk management framework (Article 6), the register of ICT third-party providers (Article 28), incident logs (Articles 17–23), and resilience testing reports (Articles 24–27) are all now available for you to inspect. ISA 315.A88 notes that the auditor should consider whether the entity’s IT controls relevant to financial reporting are designed and implemented effectively. DORA’s mandated controls give you a structured baseline to assess against.

The five pillars and what each means for your file

ICT risk management

The question on your file is whether your client has the Article 6 framework in place and whether the management body has approved it. Article 5(2) requires the management body to define, approve, oversee, and be responsible for all ICT risk management arrangements. If the board has not formally approved the framework, document the governance gap under ISA 265.

Framework review matters too. If the framework exists but has not been reviewed after a major incident (as Article 6(5) requires), that is a second gap.

Incident reporting

Your file question is narrower. You are not the regulator. But if your client experienced a major ICT incident during the period under audit and that incident affected financial data integrity (corrupted transaction records, disrupted reconciliation processes, lost audit trail data), you need to evaluate whether the financial statements are affected. Ask whether any incidents were classified as major under Article 18. Review the incident log. If a major incident occurred and the entity failed to report it, that is a potential regulatory non-compliance with financial statement implications.

Resilience testing

The relevance to your audit depends on whether testing identified weaknesses in IT general controls you rely on. Request the most recent resilience testing report. If the report identifies control gaps in areas relevant to financial reporting (access management, change management, data integrity controls), factor those into your control risk assessment.

Third-party risk

The register of ICT service providers (Article 28(3)) is the document to request. If your client outsources its general ledger hosting, payment processing, or data warehousing to a third party, you already need to consider ISA 402 (audit considerations relating to an entity using a service organisation). DORA’s register makes the identification of those relationships systematic. Where a service provider supports a critical function and the contract predates DORA, check whether the contract has been updated to include the mandatory provisions of Article 30 (audit rights, access, exit strategies). Missing provisions may signal a control weakness.

Information sharing

The audit implication is minimal. Participation is voluntary. Note its existence in your understanding of the entity’s control environment if they participate, but do not treat non-participation as a deficiency.

Article 6 and the internal audit question

Article 6(6) is the paragraph that most directly touches the statutory auditor’s work. It states that the ICT risk management framework (for entities other than microenterprises) shall be subject to internal audit on a regular basis. Those auditors must possess sufficient ICT knowledge, skills, and expertise, and appropriate independence.

If you plan to rely on internal audit work under ISA 610, you must now evaluate whether the internal audit team has the ICT competencies DORA requires. An internal audit function that cannot demonstrate ICT expertise cannot comply with Article 6(6). If it cannot comply, its ICT-related audit work may be unreliable for your purposes. This is not a theoretical concern. The ECIIA’s 2024 survey of 70 insurance industry respondents found that many internal audit teams were still in early stages of building DORA-specific ICT audit capability as of late 2024.

Worked example: Van Houten Verzekeringen N.V.

Van Houten Verzekeringen N.V. is a mid-sized Dutch insurance company with €87M in gross written premium and 140 employees. The engagement team is performing the 2025 statutory audit.

1. Obtain the DORA documentation set

Request the ICT risk management framework (Article 6), the ICT third-party register (Article 28), the most recent incident log (Articles 17–23), and the latest resilience testing summary (Articles 24–27).

2. Evaluate the ICT risk management framework

Van Houten’s framework was approved by the management board on 15 December 2024, covers all five DORA risk management areas (identification through recovery), and names a Chief Information Security Officer as the dedicated control function under Article 6(4). The framework has not yet been reviewed post-incident because no major incidents occurred in the period.

3. Review the ICT third-party register

Van Houten’s register lists 14 ICT service providers, of which two support critical functions: a cloud hosting provider for the policy administration system (Mendrix B.V., €420K annual contract) and an outsourced data centre operator (DataPort GmbH, €185K annual contract). Both contracts were renegotiated in Q4 2024 to include Article 30 provisions.

4. Check the incident log

No incidents were classified as major during 2025. Two minor incidents were logged: a four-hour email outage in March and a failed software patch in June that was rolled back within two hours. Neither affected financial data.

5. Assess resilience testing

Van Houten conducted a vulnerability assessment in Q1 2025. The report identified one medium-severity finding: an unpatched vulnerability in the policy administration system’s API gateway. Remediation was completed in April 2025. No TLPT was required (Van Houten is not classified as significant for this purpose).

The audit file now contains a documented, structured ICT risk assessment that reflects DORA’s requirements. A reviewer sees exactly what the engagement team obtained and what it found. The connection to the financial statement audit is explicit. Van Houten’s DORA compliance position is strong, and no additional audit procedures were needed beyond the standard programme.

What to do on your next financial entity engagement

1. Add a DORA applicability check to your engagement acceptance and continuance procedures. Confirm whether the entity falls within the 20 categories listed in Article 2(1). Record the result.
2. Request the four core DORA documents (ICT risk framework, third-party register, incident log, resilience testing report) as part of your ISA 315 information requests. Do this at planning, not at fieldwork.
3. Evaluate whether the management body approved the ICT risk management framework per Article 5(2). If no board-level approval exists, document the governance gap under ISA 265.
4. For any critical ICT third-party provider identified in the register, perform the ISA 402 assessment. Check whether the contract includes Article 30 provisions.
5. Review the incident log for any major incidents during the audit period. For any major incident, evaluate whether financial data integrity was affected.
6. If you plan to rely on internal audit ICT work under ISA 610, verify the ICT competencies of the internal audit team or their outsourced ICT audit provider against Article 6(6).

Article 58: will audit firms fall under DORA?

Article 58(3) of DORA required the European Commission, by 17 January 2026, to review whether statutory auditors and audit firms should be brought into DORA’s scope (either by amending DORA itself or by amending the Audit Directive 2006/43/EC). The Commission sent its consultation request to the ESAs on 29 October 2025.

In December 2025, the ESAs published their joint report in response. Their conclusion: including statutory auditors and audit firms within DORA’s scope is not warranted at this stage. The ESAs noted that auditors do not run transactional systems and do not process real-time financial flows. Existing requirements through ISQM 1 and the Audit Directive already cover ICT risk.

Accountancy Europe made a similar argument. DORA inclusion would duplicate existing obligations and increase costs without improving market stability.

The CEAOB acknowledged that both pathways (DORA inclusion or Audit Directive amendment) could result in enhanced ICT security, but did not recommend immediate inclusion. For now, audit firms remain outside DORA’s scope. That could change if the Commission decides to propose legislation despite the ESAs’ recommendation. Watch for any legislative proposal during 2026.

Regardless of whether audit firms fall under DORA, the regulation’s impact on your financial entity clients is already live. The practical question is not whether your firm is in scope. It is whether your audit file reflects the ICT control environment your client now operates in.

Common mistakes

• Copy-forward IT environment sections. Treating the IT environment section of the risk assessment as a copy-forward exercise on financial entity engagements. DORA created an entirely new control environment with mandated documentation and regulatory consequences that did not exist before January 2025. The AFM and DNB will expect to see auditors engaging with these.
• Not requesting the ICT third-party register. Failing to request the ICT third-party register (Article 28(3)) during planning. This register is the single fastest way to identify ISA 402 relationships you may not have known about, and it is now a mandatory document your client must maintain.

Related Ciferi content

Related guides:

Put audit concepts into practice with these free tools:

Frequently asked questions

Further reading and source references

• Regulation (EU) 2022/2554 (DORA): the full text of the Digital Operational Resilience Act, including Articles 2 (scope), 5–6 (ICT risk management), 17–23 (incident reporting), 24–27 (resilience testing), 28–30 (third-party risk), and 58 (review clause).
• ISA 315 (Revised 2019), Identifying and Assessing Risks of Material Misstatement: the standard governing the IT environment understanding that DORA now shapes.
• ISA 402, Audit Considerations Relating to an Entity Using a Service Organisation: directly relevant when evaluating ICT third-party providers from the DORA register.
• ISA 265, Communicating Deficiencies in Internal Control: the standard for documenting and communicating DORA governance gaps.
• ESAs Joint Report (December 2025): the ESAs’ response to the Commission’s Article 58 consultation on including audit firms within DORA’s scope.