The EU’s Digital Operational Resilience Act has applied to financial entities since 17 January 2025, and it did something few regulations do: it wrote internal audit into the text. Article 6 requires the ICT risk management framework to be audited by auditors with sufficient knowledge, skills and expertise in ICT risk and appropriate independence, at a frequency commensurate with the entity’s ICT risk, with a formal follow-up process for critical findings. That makes DORA both a subject internal audit has to cover and a standard internal audit is itself measured against. This guide treats the regulation as an evergreen structure rather than a compliance project: what the five pillars require, which delegated regulations fill in the detail, what internal audit tests under each, how the function’s own obligations work, a test program, a scoping record template and a worked example at a Dutch payment institution’s first DORA audit.
In this guide
- What DORA is, who it covers and how proportionality works
- The five pillars and the delegated regulations behind them
- Pillar 1: the ICT risk management framework
- Pillar 2: incident classification and the reporting clocks
- Pillar 3: resilience testing and TLPT
- Pillar 4: ICT third-party risk and the register of information
- Pillar 5: oversight of critical providers, and information sharing
- Where the regime stands in 2026
- Internal audit’s own obligations under Article 6
- The test program
- The DORA audit scoping record
- Worked example: Helder Payments’ first DORA audit
- Common mistakes
- Related guides
What DORA is, who it covers and how proportionality works
DORA is Regulation (EU) 2022/2554 of 14 December 2022, directly applicable in every member state without transposition, applying from 17 January 2025. It consolidates ICT risk requirements that had been scattered across sectoral rules and supervisory guidelines into one regime for the financial sector, and it extends that regime to the ICT providers the sector depends on. The scope covers the breadth of EU-regulated finance: credit institutions, payment and electronic money institutions, investment firms, crypto-asset service providers, central securities depositories, central counterparties, trading venues, managers of alternative investment funds and management companies, insurance and reinsurance undertakings and intermediaries, and several more, alongside ICT third-party service providers, which are brought in directly through the oversight framework and indirectly through the contractual obligations imposed on the entities they serve.
Proportionality is built in rather than assumed. Article 4 requires the rules to be applied in proportion to the entity’s size, risk profile and the nature, scale and complexity of its services, and Article 16 provides a simplified ICT risk management framework for a defined set of small and non-interconnected entities, with the detail of both the full and the simplified frameworks set out in Commission Delegated Regulation (EU) 2024/1774. The management body’s accountability is not proportionate: Article 5 makes it responsible for defining, approving, overseeing and being accountable for the ICT risk management framework, for the digital operational resilience strategy, for the policy on ICT third-party arrangements, for adequate budget, and for keeping its own knowledge of ICT risk current through training. For an internal auditor, that article is the first test in every DORA engagement, because a framework the board has not approved and does not understand fails at the top regardless of what the technology looks like.
The five pillars and the delegated regulations behind them
The regulation’s chapters map to five pillars, and the level-two texts, the regulatory and implementing technical standards adopted as delegated and implementing regulations, carry most of the operational detail that an audit tests against. The table is the map; the sections that follow take each pillar in turn.
| Pillar | Chapter and articles | Core requirement | Level-two texts | What internal audit tests |
|---|---|---|---|---|
| 1. ICT risk management | Chapter II, Articles 5 to 16 | Governance by the management body; a documented framework covering identification, protection, detection, response and recovery, backup, learning and communication; reviewed at least annually; audited | Delegated Regulation (EU) 2024/1774 on ICT risk management tools, methods, processes and policies, and the simplified framework | Framework completeness against the RTS; board approval and review; the strategy; the audit and follow-up process itself |
| 2. ICT-related incident management, classification and reporting | Chapter III, Articles 17 to 23 | An incident management process; classification against harmonized criteria; reporting of major incidents to the competent authority on fixed clocks; voluntary reporting of significant cyber threats | Delegated Regulation (EU) 2024/1772 on classification criteria and materiality thresholds; Delegated Regulation (EU) 2025/301 on report content and time limits; Implementing Regulation (EU) 2025/302 on forms | Classification operating; clocks met; incident log completeness; root-cause and lessons learned |
| 3. Digital operational resilience testing | Chapter IV, Articles 24 to 27 | A risk-based testing program run at least annually across ICT systems supporting critical or important functions; threat-led penetration testing at least every three years for entities identified by their authorities; tester requirements | RTS on threat-led penetration testing, aligned with the TIBER-EU framework | Program coverage; remediation of test findings; TLPT scoping, tester independence and remediation |
| 4. Managing ICT third-party risk | Chapter V Section I, Articles 28 to 30 | A strategy and policy on ICT third-party risk; a register of information on all contractual arrangements; pre-contract assessment; contractual provisions including audit and access rights and exit strategies; concentration risk | Delegated Regulation (EU) 2024/1773 on the policy for ICT services supporting critical or important functions; Implementing Regulation (EU) 2024/2956 on the register templates; Delegated Regulation (EU) 2025/532 on subcontracting | Register completeness and accuracy; contracts against Article 30; concentration and exit; subcontracting chains |
| 5. Oversight of critical ICT third-party providers | Chapter V Section II, Articles 31 to 44; information sharing Chapter VI, Article 45 | Designation of critical providers by the European Supervisory Authorities; direct oversight by a Lead Overseer; entities manage the risks of using designated providers; voluntary information-sharing arrangements | Delegated Regulations (EU) 2025/295 and 2025/420 on oversight conditions and joint examination teams | Whether designated providers are identified in the register; how oversight findings reach the entity; participation in information sharing |
Pillar 1: the ICT risk management framework
Articles 5 to 16 describe a framework rather than a control list, and the audit tests the framework’s existence, completeness and operation in that order. Article 6 requires a sound, comprehensive and well-documented framework that identifies, protects against, detects, responds to and recovers from ICT risk, documented and reviewed at least once a year and after major incidents, with a digital operational resilience strategy that sets out how the framework is implemented. Articles 7 to 14 fill in the functions: ICT systems and tools that are reliable, capacious and resilient (Article 7); identification of ICT-supported business functions, assets and dependencies, with the inventory kept current and reviewed (Article 8); protection and prevention including access, patching, encryption and change management (Article 9); detection with mechanisms that flag anomalous activity and allow multiple layers of control (Article 10); response and recovery with a business continuity policy and ICT response and recovery plans that are tested (Article 11); backup policies, restoration and recovery procedures with testing and segregated restoration systems (Article 12); learning and evolving including post-incident reviews and awareness training for staff and the management body (Article 13); and communication policies for clients, counterparties and the public (Article 14). Delegated Regulation 2024/1774 turns these into specific policy and procedure requirements, and its articles are the criteria the audit maps the entity’s documents against.
The audit approach is a two-level mapping. The first level maps each requirement in the regulation and the RTS to a document or a process at the entity, which produces the coverage picture and the gaps; the second tests a selection of the mapped controls for operation, drawing on the specialist guides for each function: the patch and vulnerability guide for Article 9, the incident response guide for Articles 10 and 11, the backup and recovery guide for Article 12, and the IAM guide for access. The asset and dependency inventory under Article 8 deserves particular attention, because everything else in DORA assumes the entity knows which ICT assets support which critical or important functions, and the inventory reconciled to independent sources is the first substantive test in most first-year audits.
Pillar 2: incident classification and the reporting clocks
Articles 17 to 23 require an ICT-related incident management process that detects, manages and notifies incidents, a classification of every incident against harmonized criteria, and reports to the competent authority for those classified as major. The classification criteria in Delegated Regulation 2024/1772 are the ones the audit re-performs: clients, financial counterparts and transactions affected; reputational impact; duration and service downtime; geographical spread; data losses; criticality of the services affected; and economic impact, with materiality thresholds that decide whether an incident is major. The reporting clocks in Delegated Regulation 2025/301 are fixed: an initial notification within four hours of classifying the incident as major and no later than 24 hours from becoming aware of it, an intermediate report within 72 hours of the initial notification, and a final report within one month of the intermediate report, on the forms in Implementing Regulation 2025/302. Significant cyber threats may be reported voluntarily.
Three tests carry the pillar. Completeness of the incident log against detection sources (the monitoring platform, the service desk, the provider’s notifications), because an incident that never entered the log was never classified. Re-performance of classification on a sample of logged incidents, including the ones classified as not major, since the failure mode is under-classification. And the clocks on every major incident in the period, measured from the timestamps in the log, the classification record and the submission receipt, because a report that was correct and late is a breach. Where the entity has had no major incidents, the test is a tabletop: take a plausible scenario through the classification criteria and the reporting workflow with the people who would run it, and time it. The incident response audit guide carries the wider program.
Pillar 3: resilience testing and TLPT
Articles 24 to 27 require a digital operational resilience testing program, proportionate to the entity, that runs appropriate tests on all ICT systems and applications supporting critical or important functions at least yearly, from a menu that includes vulnerability assessments and scans, open-source analyses, network security assessments, gap analyses, physical security reviews, questionnaires and scanning software, source code reviews where feasible, scenario-based tests, compatibility testing, performance testing, end-to-end testing and penetration testing. Entities identified by their competent authorities must additionally carry out threat-led penetration testing at least every three years on live production systems supporting critical or important functions, following the RTS aligned with the TIBER-EU framework, using testers who meet the requirements of Article 27, with findings and remediation reported to the authority.
The audit tests the program’s existence and coverage against the inventory of critical or important functions, the independence of the testers (internal or external, with the independence conditions met for internal testers), the remediation of findings with prioritization and closure evidence, and the TLPT cycle where it applies: scope agreed with the authority, threat intelligence used, the test run on production, the attestation obtained and the remediation plan tracked. Internal audit does not perform the tests, and it should be careful not to become the entity’s tester by default; its role is assurance over the program, and the patch and vulnerability guide covers the recurring scanning layer that most of the annual program consists of.
Pillar 4: ICT third-party risk and the register of information
Articles 28 to 30 place the entity’s reliance on ICT providers under its own risk management framework, with full responsibility remaining with the entity. Article 28 requires a strategy on ICT third-party risk and a policy on the use of ICT services supporting critical or important functions (detailed in Delegated Regulation 2024/1773), a register of information on all contractual arrangements at entity, sub-consolidated and consolidated level, distinguishing those that support critical or important functions, kept in the templates of Implementing Regulation 2024/2956 and reported to the competent authority on request and on the supervisory cycle; pre-contract due diligence covering the provider’s suitability and the risks of the arrangement; and the right to terminate in defined circumstances. Article 29 requires assessment of concentration risk and of subcontracting chains, with Delegated Regulation 2025/532 setting out what the entity must determine when critical functions are subcontracted. Article 30 lists the contractual provisions that every arrangement must contain, with additional terms for critical or important functions: a complete description of functions and services, locations of services and data, provisions on availability, integrity and confidentiality, incident assistance, cooperation with authorities, termination rights and notice periods, and, for critical or important functions, service levels with quantitative and qualitative targets, notification of developments that could affect performance, business contingency and testing obligations, unrestricted rights of access, inspection and audit for the entity and its authorities, and exit strategies with transition periods.
For internal audit this pillar is a data problem before it is a contract problem. The register is only as good as the population it was built from, and the completeness test reconciles it to accounts payable, to the cloud and SaaS spend, to the identity provider’s federation list and to the network’s external connections, in the way the vendor master guide and the end-user computing guide reconcile their inventories. A sample of critical-function contracts is then read against Article 30 clause by clause, the subcontracting chains are traced for the same sample, the exit strategies are tested for whether they could actually be executed (a plan that assumes a 90-day migration to a competitor that has never been contacted is a document), and the concentration analysis is checked for the one provider everyone knows about and the several nobody has counted. The Third-Party Topical Requirement guide covers the IIA requirement that applies to the same engagement from 15 September 2026, and the SOC 2 review guide the assurance reports that most of the due diligence rests on.
Pillar 5: oversight of critical providers, and information sharing
Articles 31 to 44 create a direct oversight regime for ICT third-party providers designated as critical by the European Supervisory Authorities. On 18 November 2025 the ESAs published the first list, designating 19 providers, each assigned a Lead Overseer with powers to request information, conduct investigations and inspections, issue recommendations and, ultimately, to have entities suspend or terminate the use of a provider that does not remediate. The designation does not relieve the entity of any obligation; it adds an information source, because the Lead Overseer’s recommendations and the provider’s responses are relevant to the entity’s own assessment, and the audit checks that designated providers are flagged in the register and that oversight outputs reach the entity’s third-party risk process. Article 45 permits entities to exchange cyber threat information and intelligence within trusted communities under arrangements that protect confidentiality and competition law, notified to the competent authority; the audit asks whether the entity participates and what it does with what it receives.
Where the regime stands in 2026
Eighteen months in, the regime has moved from readiness to supervision. The level-two texts were adopted between early 2024 and the spring of 2025, so the criteria an auditor tests against are settled: 2024/1772, 2024/1773 and 2024/1774 for classification, the third-party policy and the framework; 2024/2956 for the register templates; 2025/301 and 2025/302 for incident reporting; 2025/532 for subcontracting; 2025/295 and 2025/420 for the oversight machinery. The first register-of-information collections ran in 2025 and fed the ESAs’ designation of the 19 critical providers on 18 November 2025, and the 2026 collection cycle is under way, with national authorities opening their portals in the first quarter (Luxembourg’s CSSF, for example, opened its eDesk submission on 11 February 2026 for entities outside direct ECB supervision). It is reasonable to expect supervisory attention to follow the same path: the first-year questions were about whether the framework and the register existed; the second-year questions are more likely to be about whether the incident classification operates, whether the contracts were actually remediated and whether the board has reviewed the framework since approving it. An internal audit plan for 2026 and 2027 should assume the same shift, and the worked example below is deliberately a second-year picture rather than a first-year one.
Internal audit’s own obligations under Article 6
Article 6(6) says the ICT risk management framework shall be subject to internal audit by auditors on a regular basis in line with the entity’s audit plan, that those auditors shall possess sufficient knowledge, skills and expertise in ICT risk as well as appropriate independence, and that the frequency and focus of ICT audits shall be commensurate to the entity’s ICT risk. Article 6(7) adds that, based on the conclusions of the internal audit review, the entity shall establish a formal follow-up process, including rules for the timely verification and remediation of critical ICT audit findings. Four consequences follow for the function. The audit plan has to show ICT coverage that is risk-based and regular, which means the IT audit plan is itself evidence of conformance and a supervisor may ask for it. The auditors’ competence has to be demonstrable, through qualifications, experience, training records or co-sourcing arrangements, and a function whose ICT expertise consists of a generalist with a checklist should expect the question. Independence has to be actual: an auditor who helped design the framework cannot audit it. And the follow-up process has to exist as a process, with rules for verification and remediation of critical findings, which the issue validation guide and the issue log template supply, and which the Global Internal Audit Standards already require under Standard 15.2.
The obligation also settles a scoping question. DORA does not require a single annual “DORA audit”; it requires the framework to be covered regularly in proportion to risk, and a function can meet that through a cycle of engagements that together cover the five pillars, provided the mapping from engagements to pillars is documented and the gaps are visible. Most functions run a first-year readiness engagement across all five, then move to a cycle in which each pillar is covered at a frequency set by risk, with the incident and third-party pillars usually annual. The IIA’s Cybersecurity Topical Requirement, mandatory for assurance engagements on cybersecurity since 5 February 2026, overlaps heavily with pillars 1 to 3, and the Topical Requirement workbook shows how one engagement documents both.
The test program
| # | Pillar | Test | Pass condition |
|---|---|---|---|
| 1 | Governance | Inspect board approval of the framework, the strategy, the third-party policy and the budget; inspect board training records on ICT risk | Approved and reviewed within twelve months; training evidenced for the management body |
| 2 | 1 | Map framework documents to Delegated Regulation 2024/1774 article by article | Every required policy and procedure present, current and owned; gaps listed |
| 3 | 1 | Reconcile the ICT asset and function inventory to independent sources; confirm critical or important functions are identified and mapped | Inventory complete within tolerance; every critical function mapped to its assets and providers |
| 4 | 1 | Test a sample of protection, detection and recovery controls for operation (patching, access, logging, backup and restore) | Controls operate per the specialist guides’ criteria |
| 5 | 2 | Reconcile the incident log to detection sources; re-perform classification on a sample | Log complete; classifications reproduce; no under-classified major incidents |
| 6 | 2 | Measure the reporting clocks on every major incident, or run a timed tabletop | 4-hour/24-hour, 72-hour and one-month deadlines met or demonstrably achievable |
| 7 | 3 | Inspect the testing program against the inventory of critical or important functions; test remediation of findings | Annual coverage of all in-scope systems; findings prioritized and closed |
| 8 | 3 | Where TLPT applies, inspect scope, tester independence, attestation and remediation tracking | Cycle met; testers compliant with Article 27; remediation plan tracked |
| 9 | 4 | Reconcile the register of information to AP, cloud spend, federation and network sources; test template completeness | All arrangements registered; critical-function flag accurate; templates complete |
| 10 | 4 | Read a sample of critical-function contracts against Article 30; trace subcontracting chains | Required clauses present; subcontractors identified and assessed |
| 11 | 4 | Inspect concentration analysis and exit strategies; test one exit strategy for executability | Concentrations identified and accepted or mitigated; exit plan credible |
| 12 | 5 | Confirm designated critical providers are flagged and oversight outputs reach the third-party process | Flags accurate; recommendations tracked |
| 13 | Internal audit | Assess the function’s own conformance with Article 6(6) and (7): plan coverage, competence, independence, follow-up process | Evidence for each; gaps reported to the audit committee |
The DORA audit scoping record
One record per engagement that covers any part of the framework, so that the cycle’s coverage of the five pillars is visible to the audit committee and to a supervisor asking for the Article 6(6) evidence.
DORA audit scoping record
1. Entity and applicability. Entity type under Article 2; full or simplified framework (Article 16); TLPT designation status; consolidation level for the register; competent authority.
2. Engagement. Name and reference; period; pillars covered (1 to 5) and the articles within each; pillars deliberately excluded with the engagement that covers them and its date.
3. Criteria. Regulation articles; delegated and implementing regulations applied; supervisory guidance relied on; the IIA Cybersecurity Topical Requirement rows addressed.
4. Population records. Inventory of critical or important functions and assets (source and completeness test); incident log (reconciliation); register of information (reconciliation); testing program scope.
5. Article 6(6) evidence. Auditors assigned with competence basis (qualifications, experience, co-source); independence confirmation; frequency rationale against the entity’s ICT risk.
6. Findings and follow-up. Findings by pillar with ratings; critical findings under the Article 6(7) follow-up process with verification dates; management body communication.
7. Coverage map. Cycle view: each pillar with the last engagement date, the next planned date and the risk rationale for the frequency.
8. Sign-off. Lead auditor, CAE, dates; audit committee reporting reference.
Worked example: Helder Payments’ first DORA audit
Helder Payments B.V. is an illustrative Dutch-licensed payment institution: about 90 staff, merchant acquiring and payment initiation across eleven EU markets, a processing platform built in-house and hosted on a hyperscaler, a managed security operations provider, and a two-person internal audit function that co-sources IT audit from a firm. It is in scope of the full framework, not the simplified one, and its competent authority had not designated it for threat-led penetration testing. The first DORA audit was scoped as a readiness engagement across all five pillars at 320 hours, 200 of them co-sourced, in the second quarter of 2026, fifteen months after the regulation applied and after the entity’s first register of information submission.
The governance test set the tone. The management board had approved an ICT risk management framework document in December 2024 and had not seen it since; the digital operational resilience strategy was a section of the same document with no measures; and the board’s ICT training consisted of a one-hour briefing by the CTO. The Article 6 annual review had not happened. The asset and function inventory, tested under Article 8, held 214 assets against 340 found by reconciling the cloud tenant, the identity provider, the endpoint agent and the network inventory, and the mapping of assets to the three critical or important functions (acquiring settlement, payment initiation, and the merchant portal) had been done for settlement only. The incident log held 61 incidents for the period, of which the classification exercise re-performed under Delegated Regulation 2024/1772 changed two: a four-hour outage of payment initiation affecting merchants in three markets had been classified as not major on the grounds that no data was lost, and re-performance against the duration, geographical spread and clients-affected criteria classified it as major, which meant a report that should have been made within 24 hours had not been made at all.
| Pillar | Result | Finding and rating |
|---|---|---|
| Governance and framework | Framework approved once, never reviewed; strategy without measures; board training minimal; 14 of the RTS’s required policies present, 9 partially, 3 absent (ICT project management, ICT capacity, encryption policy) | High: Article 5 and 6 governance not operating; three policies to write, nine to complete |
| Inventory (Article 8) | 214 assets recorded against 340 found; two of three critical functions unmapped | High: the framework’s foundation incomplete; every other pillar’s scope depends on it |
| Incidents | 61 logged; two re-classified, one of them a reportable major incident not reported; log reconciliation found 9 provider notifications never logged | High: classification and reporting not operating; the missed report disclosed to the competent authority by management during fieldwork |
| Testing | Annual vulnerability scanning and one external penetration test on the platform; no testing of the merchant portal or of the settlement interfaces; 23 of 41 penetration test findings open past their dates | Medium: program coverage partial; remediation tracking weak |
| Third party | Register submitted with 38 arrangements; reconciliation found 57; the hyperscaler and the SOC provider flagged as critical, the settlement bank’s API provider and the KYC vendor not; 4 of 6 critical contracts lacked Article 30 audit-rights and exit clauses; one exit strategy (the hyperscaler) untested and, on inspection, not executable inside its own 12-month transition assumption | High: register incomplete and misflagged; contracts non-compliant; exit strategy not credible |
| Oversight and information sharing | Hyperscaler among the 19 designated providers in November 2025; not flagged; no process to receive oversight outputs; no information-sharing participation | Low: process to establish |
| Internal audit (Article 6(6) and (7)) | Audit plan showed one ICT engagement in two years; co-sourced competence adequate for this engagement; no formal follow-up process with rules for critical findings | Medium: self-reported to the audit committee with a plan |
Seven findings, four High. The report’s cover note made the point that the technical estate was in better shape than the framework around it: the platform was patched, the access model was clean, the backups restored in a test the co-sourced team observed. What DORA had exposed was the absence of the governance and inventory layers that turn a well-run platform into a demonstrably resilient financial entity, and the incident that went unreported was the consequence: nobody classifying incidents against the criteria, because nobody had been told that was their job. The follow-up process required by Article 6(7) was established as the first action, so that the other six had rules to be verified under; the register was rebuilt from the reconciled population and re-submitted; the six critical contracts were renegotiated over two quarters; and the second-year plan set the incident and third-party pillars at annual coverage, the framework at annual, and testing at biennial, with the rationale recorded in the scoping record’s coverage map. The business continuity and resilience guide covers the recovery-side testing the second year concentrated on.
Common mistakes
Auditing DORA as a document review, mapping policies to articles and stopping before any control is tested. Skipping the inventory reconciliation, so that every subsequent test runs on a population the entity chose. Accepting the incident log as complete. Re-performing classification only on the incidents management classified as major. Treating the register of information as a submission rather than a control, and never reconciling it to spend. Reading contracts for the presence of an audit-rights clause without asking whether the entity has ever exercised one. Accepting an exit strategy that no one has costed or timed. Ignoring the entity’s own obligations toward designated critical providers because “the ESAs oversee them now”. Letting internal audit become the testing program under pillar 3. And forgetting that Article 6(6) is a test of the audit function, so that the first finding a supervisor raises is about the auditors. The financial services AML and KYC guide and the operational risk guide cover the regulatory and operational risk context DORA sits in, and the backup and recovery guide Article 12’s specific requirements.
Related guides
- How to audit incident response
- How to audit backup and recovery
- How to audit patch and vulnerability management
- How to audit identity and access management
- The Third-Party Topical Requirement
- The Cybersecurity Topical Requirement workbook
- How to review a SOC 2 report
- How to audit the vendor master
- How to build the IT audit plan
- Issue validation
- Business continuity and organizational resilience
- Operational risk
- Third-party resilience: continuity when the failure is not yours
- Fourth parties and vendor concentration: the risk behind the risk
Leave a Reply