Five pillars, five evidence streams
DORA organises into five areas, and structuring the audit around them keeps coverage clear and maps to how supervisors think:
| Pillar | Core evidence |
|---|
| ICT risk management | The ICT risk-management framework + management-body approval |
| ICT incident management & reporting | Classification criteria, major-incident reports, timelines |
| Digital operational resilience testing | Test programme, results, remediation; TLPT for some entities |
| ICT third-party risk | Register of information, contracts, oversight, exit strategies |
| Information sharing | Arrangements for sharing cyber-threat information (where adopted) |
Pillar 1 — ICT risk-management framework
- Obtain the ICT risk-management framework and confirm it's documented, current, and covers the entity's ICT systems and dependencies.
- Confirm management-body approval — DORA requires the governing body to own and approve the framework (see the responsible-person section below).
- Trace controls to risks as with any risk-based regime (see risk-based auditing): identified ICT risks should map to controls, and back.
Pillar 2 — Incident classification and reporting
DORA has specific criteria for what makes an ICT-related incident major, and reporting timelines for major incidents to the competent authority. The audit must test both the classification and the timeline.- Confirm the classification criteria are implemented so staff can consistently decide whether an incident is major.
- Walk through a real incident: was it classified correctly, and if major, were the initial / intermediate / final reports submitted within DORA's deadlines?
- Where there have been no major incidents, test classification against a scenario — the frequent gap is inconsistent or absent classification rather than late reporting.
Pillar 3 — Resilience testing
DORA requires a programme of digital operational resilience testing, and for certain significant entities, threat-led penetration testing (TLPT) on a multi-year cycle.- Obtain the testing programme and confirm it's risk-based and covers critical systems.
- Ask for results and remediation — testing without tracked remediation of what it found is a finding. Re-perform or sample to confirm the fixes landed.
- For TLPT-scoped entities, confirm the test was conducted to the required standard and the findings fed back into the framework.
Pillar 4 — Third-party ICT risk (the prescriptive one)
DORA's third-party regime is more detailed than most, and it has a named artefact regulators expect to see: the register of information on all contractual arrangements for ICT services.- Obtain the register of information and test it for completeness against the actual ICT contracts — a register that omits a critical provider is a serious finding.
- Sample contracts and confirm they carry DORA's required clauses (access and audit rights, exit support, service levels, sub-contracting terms, location of data and processing).
- Check oversight of critical providers is real — not just contracted but monitored — and that exit strategies and concentration-risk analysis exist for critical dependencies.
Generic IT view
Auditor confirms ICT suppliers have contracts and concludes third-party risk is managed. The register of information is never requested, and concentration risk (three critical services all with one cloud provider) goes unexamined.
DORA-aware
Auditor pulls the register of information, reconciles it against the contract list (finds one critical SaaS provider missing), samples three contracts for the required audit-rights and exit clauses (finds one lacks exit support), and flags the single-cloud concentration as a resilience risk. Three DORA-specific findings a generic IT audit would miss.
The responsible person — management-body accountability
As with NIS2, DORA puts the management body squarely in scope: it bears final responsibility for the ICT risk-management framework, must approve it, and must maintain adequate knowledge of ICT risk. Board approval of the framework and evidence of management-level ICT-risk competence are things to seek directly (see roles & responsibilities) — their absence is a finding, not a footnote.
Scope note — DORA plus its technical standards
DORA is a regulation (directly applicable, no national transposition), but much of its operational detail lives in the Regulatory and Implementing Technical Standards (RTS/ITS) that attach article-by-article. A thorough DORA audit tests against the relevant RTS/ITS, not the Level-1 text alone — the register-of-information format and the incident-classification thresholds, for instance, are specified in the technical standards.
The DORA audit checklist
Everything above is the method. The
DORA audit checklist
applies it across the whole regulation — every obligation as a scored
question, with suggested evidence and a finding level on each, and a
Regulatory Compliance Matrix mapping every paragraph to the questions that
cover it. Download the matrix and the sample free from the product page to
see the coverage before you decide.
See the DORA checklist →
