DORA ICT Risk: What Auditors Need to Check on Financial Sector Engagements

If you're auditing a bank, insurer, or payment institution in the EU, your client became subject to the Digital Operational Resilience Act on 17 January 2025. The regulation adds ICT risk management obligations that sit outside traditional financial statement audit territory. Most audit teams haven't adjusted their risk assessment procedures to account for them. That gap will show up in inspection files within the next two review cycles.

DORA (EU Regulation 2022/2554) requires EU financial entities to maintain an ICT risk management framework covering identification, protection, detection, response, and recovery of ICT-related risks, with direct implications for auditors performing financial statement audits and ISAE 3402 engagements on service organisations supporting these entities.

What DORA requires from financial entities

DORA applies to credit institutions, investment firms, insurance and reinsurance undertakings, payment institutions, electronic money institutions, and several other categories of financial entity listed in Article 2. The scope is broad. If your client holds a financial services licence in the EU, DORA almost certainly applies.

Article 6 requires each financial entity to establish an ICT risk management framework as part of its overall risk management system. This framework must include strategies, policies, procedures, ICT protocols, and tools necessary to protect all information assets and ICT assets. The management body (Article 5) bears direct responsibility for defining, approving, overseeing, and being accountable for the implementation of this framework.

The framework has five functional pillars, addressed in Articles 7 through 13. Identification (Article 8) requires the entity to identify, classify, and document all ICT-supported business functions, information assets, and ICT assets, including those managed by third-party providers. Protection and prevention (Article 9) covers the policies and controls that protect ICT systems. Detection (Article 10) requires mechanisms to detect anomalous activities. Response and recovery (Articles 11-12) address business continuity policies, ICT response plans, and backup and restoration procedures. Learning and evolving (Article 13) mandates post-incident reviews that feed back into the framework.

For the auditor, the question is not whether your client has an IT policy. The question is whether that policy meets the specific structural requirements DORA imposes.

The proportionality principle in Article 4 means these requirements apply differently depending on the entity's size, risk profile, and the nature and complexity of its ICT-supported services. A large credit institution with 2,000 employees and a complex trading infrastructure faces stricter expectations than a small payment institution with 30 staff. But proportionality does not mean exemption. Every entity within scope must have the framework. The depth of implementation varies; the obligation does not.

Article 6(5) requires the ICT risk management framework to be documented and reviewed at least once a year. Auditors should obtain the most recent version and confirm the review date. An ICT risk management framework last reviewed in 2023 does not meet the annual review requirement.

How DORA affects the financial statement audit

DORA does not create a new audit standard. It creates new regulatory requirements that change the entity's control environment, risk profile, and compliance obligations. Those changes flow into the audit through existing ISA requirements.

Under ISA 315.14, the auditor identifies and assesses risks of material misstatement by understanding the entity and its environment, including the regulatory framework. DORA is now part of that regulatory framework for every financial sector client. If your planning memorandum for a banking engagement doesn't reference DORA, you've missed a component of the entity's regulatory environment.

ISA 315.21-22 requires you to understand the entity's system of internal control. For a DORA-regulated entity, that system now includes the ICT risk management framework itself. A material weakness in the ICT risk management framework (for example, the entity has no documented ICT business continuity policy as required by Article 11) could indicate a control environment deficiency that affects your assessment of control risk.

The connection to financial statement assertions is sometimes indirect but real. If an entity's ICT recovery procedures are inadequate and a major outage disrupts financial reporting systems, that affects the completeness and accuracy of financial data. If third-party ICT providers process transactions without adequate oversight, that creates risks to the existence and valuation of recorded amounts. ISA 315.A190 recognises that IT-related risks can affect multiple assertions across financial statement line items.

DORA compliance failures can also trigger regulatory sanctions under Article 50, which creates a provision or contingent liability consideration under IAS 37. If your client has received a supervisory finding related to DORA non-compliance, you should evaluate whether a provision or disclosure is needed. This is no different from any other regulatory penalty exposure, but it requires the auditor to know enough about DORA to ask the right questions.

Third-party ICT provider oversight and what auditors verify

Chapter V of DORA (Articles 28-44) imposes detailed requirements on how financial entities manage their relationships with third-party ICT service providers. This is where DORA intersects most directly with audit work, because the quality of third-party oversight affects the auditor's reliance on controls operated by service organisations.

Article 28.2 requires the financial entity to adopt a strategy on ICT third-party risk. Article 30 specifies the contractual provisions that must appear in agreements with ICT providers, including audit rights, data location requirements, and incident notification procedures. For providers of critical or important functions (defined in Article 3(22)), the requirements are stricter: the entity must conduct a risk assessment before entering the arrangement (Article 28.4) and must maintain a register of all ICT third-party arrangements (Article 28.3).

What does the auditor check? Under ISA 402.9, the auditor of a user entity must obtain an understanding of how the entity uses service organisations and the nature of the services provided. For DORA-regulated entities, this understanding now extends to whether the entity has classified its ICT providers correctly, whether contractual arrangements meet DORA requirements, and whether the entity monitors provider performance as required by Article 28.6.

When a third-party ICT provider is material to the entity's financial reporting (for example, a cloud-based core banking system or a payment processing platform), the auditor needs evidence about controls at the provider. This typically means obtaining an ISAE 3402 Type II report or performing alternative procedures under ISA 402.12-13. DORA does not change this requirement, but it does mean you should verify whether the entity has actually exercised its audit and access rights under Article 30(3)(e).

Incident reporting and resilience testing

DORA Articles 17-23 establish a mandatory ICT-related incident reporting framework. Financial entities must classify ICT-related incidents according to criteria set out in Article 18 (including duration, data losses, criticality of services affected, and geographical spread) and report major incidents to their competent authority. Article 19 sets specific reporting timelines: an initial notification, an intermediate report, and a final report.

For auditors, incident reporting matters in two ways. First, material ICT incidents that occur before the date of the auditor's report are subsequent events under ISA 560. An incident that damages the entity's financial reporting infrastructure or triggers a significant regulatory response could require disclosure or adjustment. Second, the pattern of incidents reported (or not reported) tells you something about the reliability of the entity's ICT controls.

Articles 24-27 cover digital operational resilience testing. Financial entities must conduct testing programmes that include vulnerability assessments and, for entities identified under Article 26, threat-led penetration testing (TLPT) at least every three years. The results of resilience testing directly inform the auditor's evaluation of the operating effectiveness of IT general controls. If the entity's most recent TLPT identified critical vulnerabilities that remain unremediated, that finding affects your assessment of ICT-related control risk.

DORA's impact on ISAE 3402 engagements

Service auditors performing ISAE 3402 engagements on ICT service providers that serve DORA-regulated financial entities face additional considerations. DORA Article 30(3)(e) gives financial entities (and their competent authorities and resolution authorities) audit and access rights over the ICT provider. This means the service organisation's ISAE 3402 report may need to demonstrate compliance with contractual obligations that now explicitly reference DORA requirements.

The control objectives in an ISAE 3402 report for a provider serving DORA-regulated entities should address the specific areas DORA mandates: ICT security policies (Article 9), detection mechanisms (Article 10), business continuity and disaster recovery (Articles 11-12), and incident management and reporting support (Articles 17-19). A Type II report that covers only generic IT controls without addressing these DORA-specific obligations may not satisfy the financial entity's oversight requirements.

For the service auditor, this means conversations with management about control objectives should reference DORA requirements directly. A control matrix that pre-dates January 2025 and was built for a pre-DORA environment will need updating. The gap analysis should assess whether each DORA-relevant control objective has been addressed and whether the testing protocol covers the specific procedures DORA requires.

Worked example: auditing ICT risk at a mid-size Dutch insurer

Scenario: Veenstra Verzekeringen N.V. is a mid-size Dutch insurance company with €85M in gross written premiums. It uses three third-party ICT providers: a cloud-hosted policy administration system (Solera Platform B.V.), an outsourced claims processing service (Rijnmond Services B.V.), and a data centre provider for disaster recovery (NordHost GmbH). The engagement team is performing the 2025 financial statement audit.

1. During planning, the engagement partner confirms that Veenstra falls within DORA's scope as an insurance undertaking under Article 2(1)(j). The team adds DORA to the regulatory framework section of the planning memorandum and identifies ICT risk management as a component of the entity's control environment.

Documentation note: "Veenstra Verzekeringen N.V. is subject to Regulation (EU) 2022/2554 (DORA) as an insurance undertaking. DORA's ICT risk management requirements have been included in our understanding of the entity's regulatory environment per ISA 315.14."

2. The team requests Veenstra's ICT third-party register (required by Article 28.3) and verifies that all three providers are included. Solera Platform B.V. and Rijnmond Services B.V. are classified as providers of critical or important functions. NordHost GmbH is classified as non-critical.

Documentation note: "Obtained the entity's ICT third-party register dated 15 March 2025. Two of three providers classified as critical/important. Classification criteria per Article 3(22) reviewed and found consistent with the entity's dependency on these services."

3. For the two critical providers, the team obtains ISAE 3402 Type II reports. Solera Platform's report covers the period 1 January to 31 December 2025 with no exceptions. Rijnmond Services' report covers only 1 January to 30 June 2025 (a six-month report), and the team identifies two control deviations related to incident response notification timing.

Documentation note: "Rijnmond Services B.V. ISAE 3402 Type II report covers only H1 2025. Gap period from 1 July to 31 December 2025 requires additional procedures per ISA 402.12. Two deviations noted in incident notification controls. Assessed impact on our evaluation of control risk for claims processing completeness and accuracy."

4. The team reviews Veenstra's incident register for 2025 and identifies one major ICT incident (a four-hour outage of the policy administration system in September 2025) that was reported to De Nederlandsche Bank under Article 19. The team evaluates whether the incident affected financial data integrity and confirms that the entity performed a post-incident review as required by Article 13.

Documentation note: "Major ICT incident reported to DNB on 14 September 2025. Entity conducted post-incident review per DORA Article 13. No impact on financial data completeness or accuracy identified based on management's analysis and our review of reconciliations performed after system restoration."

A reviewer would see a file that connects DORA requirements to specific audit procedures, traces third-party ICT risks through to the ISA 402 evaluation, and documents the assessment of ICT incidents as potential subsequent events.

Practical checklist for financial sector engagements

1. Confirm whether DORA applies to your client by checking the entity categories in Article 2. Add DORA to the regulatory framework section of your planning memorandum if it does (ISA 315.14).
2. Obtain and review the entity's ICT third-party register (Article 28.3). For each provider of critical or important functions, verify that a current ISAE 3402 Type II report or equivalent evidence is available and that audit rights exist in the contract (Article 30(3)(e)).
3. Ask management whether any major ICT incidents were reported to the competent authority during the period under audit. Evaluate their subsequent events implications under ISA 560.
4. Review the entity's most recent digital operational resilience testing results (Articles 24-27). Assess whether unremediated vulnerabilities affect your evaluation of IT general controls.
5. For ISAE 3402 engagements on ICT service providers, verify that control objectives address DORA-specific requirements (ICT security, detection, business continuity, incident management) and not only generic IT controls.
6. Check whether the entity's management body has formally approved the ICT risk management framework as required by Article 5. Absence of this approval is a control environment deficiency.

Common mistakes on DORA-affected engagements

• Treating DORA as "IT audit only" and excluding it from the financial statement audit risk assessment. The AFM's supervisory approach to DORA implementation makes clear that the regulation affects governance and risk management at the entity level, not just IT operations. If the auditor's ISA 315 understanding of the entity omits DORA, the risk assessment is incomplete.

• Accepting pre-2025 ISAE 3402 reports from ICT providers without checking whether the control objectives address DORA-specific requirements. A report issued before January 2025 was designed for a pre-DORA control environment and may not cover incident reporting, resilience testing, or contractual provisions now mandated by the regulation.

Related content

• ISAE 3402 glossary entry: Explains the service auditor's report framework that applies to ICT providers serving DORA-regulated entities.
• ISAE 3402 audit pack: Includes the control matrix, testing protocol, and gap analysis structure relevant to ICT service provider engagements under DORA.
• FUTURE POST: ISA 402 user auditor checklist: Covers the procedures for evaluating service organisation reports, which directly supports DORA third-party oversight work.