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 and a line on access controls. 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 incidents within hours, test operational resilience, and maintain a register of all ICT third-party service providers, effective 17 January 2025.
For statutory auditors, DORA does not 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.
Key takeaways
- How DORA’s five pillars affect the IT environment assessment you perform under ISA 315.6 –9 on financial entity audits
- What Article 6 of DORA requires from your client’s internal audit function regarding ICT, and why that matters for your reliance decisions
- How to document DORA-related ICT risks in your working papers with specific file actions
- Where the Article 58 review stands and what it could mean for audit firms from 2026 onward
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, BaFin, 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.
The first pillar is 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 auditors (internal, here) with sufficient ICT knowledge to audit the framework on a regular cycle.
The second pillar is 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.
The third pillar is digital operational resilience testing. Articles 24 to 27 require a testing programme that includes vulnerability assessments, network security testing, scenario-based tests, and source code reviews where applicable. 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.
The fourth pillar is 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.
The fifth pillar is 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. On many engagements, the IT environment section was a tick box exercise: a paragraph rolled forward from last year with no real assessment behind it. 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) and contract terminations ordered by regulators. A material DORA non-compliance could affect the entity’s ability to continue operating, which connects to your ISA 570 going concern assessment. If your client also falls within scope of the NIS 2 Directive, the cumulative regulatory burden increases further.
Second, DORA produces audit-relevant documentation that did not previously exist in this form. 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
For 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.
For 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, or compromised access logs), 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 matters to your audit if the results 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, operations security, or data integrity controls), factor those into your control risk assessment.
For 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 or payment processing 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, data access, exit strategies, and subcontracting limits). Missing provisions may signal a control weakness. This is the check that generates the most review notes on first-year DORA engagements, because pre-2025 contracts almost never include these clauses.
The information sharing pillar has minimal audit implications. 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 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.
Where internal audit lacks ICT capability, your client may outsource ICT audit to a specialist firm (Article 6(10) permits outsourcing of compliance verification). If they do, you need to evaluate the competence of that outsourced provider just as you would evaluate in-house internal audit under ISA 610.12 .
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.
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).
Documentation note: Record in W/P A3.2 (IT Environment Understanding) that DORA applies to the entity effective 17 January 2025 and list the four documents obtained with dates and responsible persons.
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.
Documentation note: Record in W/P A3.2 the framework approval date, confirm board-level sign-off per Article 5(2), note the dedicated control function, and record that no post-incident review was triggered.
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.
Documentation note: Record in W/P A3.4 (Service Organisations) that two critical-function providers were identified, contracts include DORA-mandated provisions, and cross-reference to ISA 402 evaluation for each. Note that 12 non-critical providers were identified but do not support financial reporting processes.
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.
Documentation note: Record in W/P A3.5 that two minor ICT incidents were logged, neither classified as major under Article 18, and neither affected the integrity of financial reporting data.
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).
Documentation note: Record in W/P A3.6 that vulnerability testing was performed, one medium finding was identified and remediated, and TLPT was not required. Cross-reference the API gateway to IT general controls if the policy administration system feeds financial data.
Van Houten’s DORA compliance position is strong, and no additional audit procedures were needed beyond the standard programme. If the engagement partner had found gaps (a missing framework, an unreported major incident, a critical provider without Article 30 contract terms), each gap would have generated a specific follow-up procedure rather than a vague note about “ICT risk.”
What to do on your next financial entity engagement
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 stronger 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.
Common mistakes
Related content
- ICT risk management (glossary). The definition and governing DORA articles for ICT risk management in financial entities.
- ISA 315 risk assessment calculator. Use this tool to structure your risk assessment, including IT environment considerations.
- How to evaluate service organisations under ISA 402 . Practical guide to assessing outsourced service providers, directly relevant when reviewing DORA’s ICT third-party register.
Related ciferi content
Related guides:
Put audit concepts into practice with these free tools:
Frequently asked questions
Which entities fall under DORA?
DORA applies to 20 categories of financial entity listed in Article 2(1), including banks, insurance and reinsurance companies, investment firms, payment institutions, crypto-asset service providers, and central securities depositories. If your client holds a licence from DNB, the AFM, BaFin, 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.
Does DORA change ISA 315 requirements for auditors?
DORA does not change what ISA 315 (Revised 2019) requires, but it changes the environment your client operates in. Your client now has a mandated ICT control environment with specific documentation, governance, testing, and reporting obligations. ISA 315.26 (d) requires you to understand the entity’s IT environment, and DORA’s framework gives you a structured baseline to assess against. Non-compliance may constitute a control deficiency under ISA 265 .
What DORA documents should auditors request during planning?
Request four core documents as part of your ISA 315 information requests: the ICT risk management framework (Article 6), the ICT third-party service provider register (Article 28), the incident log (Articles 17–23), and the most recent resilience testing report (Articles 24–27). Request these at planning, not during fieldwork.
Will audit firms fall under DORA?
Article 58(3) required the European Commission to review whether statutory auditors and audit firms should be brought into DORA’s scope by January 2026. The ESAs published their joint report in December 2025, concluding that inclusion is not warranted at this stage. Audit firms remain outside DORA’s scope for now, but this could change if the Commission proposes legislation despite the recommendation.
How does DORA affect reliance on internal audit under ISA 610 ?
Article 6(6) requires that the ICT risk management framework be subject to internal audit by auditors with sufficient ICT knowledge and independence. If you plan to rely on internal audit ICT work under ISA 610 , you must 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), and its ICT-related work may be unreliable for your purposes.
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.