DORA audits are conducted by financial supervisory authorities — EBA, ESMA, EIOPA, and national competent authorities (e.g., ECB, PRA, BaFin, CBI). For significant financial entities, proactive supervision is built into DORA's oversight model. For all financial entities, the risk of an audit following a major incident is real. Being unprepared does not reduce your obligation — it creates additional findings and demonstrates to regulators that the risk management framework exists only on paper.
What DORA Auditors Examine
DORA audits are broadly structured around the five pillars of operational resilience:
1. ICT Risk Framework
- Is there a documented ICT risk management framework?
- Was it approved by the management body?
- Has a risk assessment been conducted and is it current?
- Does the risk treatment plan address identified risks?
2. ICT Incident Management
- Is there a documented incident management procedure?
- Has the procedure been tested?
- Are historical incidents documented?
- Were major incidents reported within the required timeframes?
3. Digital Operational Resilience Testing
- Is there a testing programme?
- Are test results documented?
- Is remediation tracked?
- For significant entities: TLPT conducted and documented?
4. ICT Third-Party Risk Management
- Is the Register of Information complete, current, and in the required format?
- Are critical providers identified with supporting analysis?
- Do contracts with critical providers include Article 30 minimum provisions?
- Is pre-contract due diligence documented?
5. Governance
- Is the management body adequately engaged with ICT risk?
- Are there board-level reports on ICT risk?
- Is there a named owner of DORA compliance?
The Document Pack Auditors Will Request
Prepare these documents before any audit inquiry:
ICT Risk Framework:
- ICT risk management framework document (board-approved, version-controlled)
- Current ICT risk assessment and risk register
- Risk treatment plan with control owners and target dates
Incident Management:
- Incident management procedure
- Incident log from the past 24 months
- Evidence of incident response testing (tabletop exercises, drill records)
- For any major incidents: notification records (were the 4-hour and 72-hour deadlines met?)
Resilience Testing:
- Testing programme plan
- Results from the past 24 months of testing (vulnerability assessments, pen tests)
- Remediation tracking for findings
- TLPT results (if applicable)
Third-Party Risk:
- Register of Information (in ESA template format)
- Due diligence records for critical providers
- Sample contracts with critical providers (demonstrating Article 30 compliance)
- Exit strategy documentation for critical providers
Governance:
- Board/management meeting minutes showing ICT risk was discussed
- Management body approval of the ICT risk framework
- Board ICT risk reports
Common DORA Audit Findings
Register of Information incomplete or out of date. Missing providers, inaccurate criticality assessments, or data that has not been updated in 12+ months. This is the most common finding in early DORA examinations.
No documented criticality assessment. The register lists providers but the criticality determination is missing or undocumented. Criticality must be assessed and the rationale documented.
Article 30 provisions missing from contracts. Existing contracts with critical providers do not include audit rights, incident notification obligations, or exit assistance provisions. A gap that requires systematic contract renegotiation.
No board approval of the ICT risk framework. The framework exists but there is no evidence the management body approved it. This is an Article 5 failure and creates personal accountability concerns.
Testing programme exists but results are not documented. Pen tests and vulnerability scans have been done, but the results and remediation are not properly recorded. Testing without documentation satisfies neither DORA nor regulators.
How to Prepare Before Receiving an Audit Notice
Gap assessment:
- Map your current documentation against the DORA requirements
- Identify what is missing or incomplete
- Prioritise by audit risk: incomplete RoI and missing contract provisions are most visible
Register of Information review:
- Export and review every row — are all providers listed? Is criticality current? Are data locations accurate?
- Confirm contracts are in place and include Article 30 provisions
Incident documentation review:
- Review all incidents from the past 24 months
- Confirm major incidents were notified on time
- Ensure post-incident reports are on file
Governance evidence:
- Locate board minutes or resolutions approving the ICT risk framework
- Confirm ICT risk appears in regular management reporting
Document management:
- All documents should be version-controlled with dates
- Document the review/approval history
- Ensure documents are in a form that can be produced quickly