How to Prepare for a DORA Audit or Supervisory Review

A DORA (Digital Operational Resilience Act) audit or DORA supervisory review is a regulatory examination of how your organization meets DORA’s operational resilience duties in practice. It is not ISO certification and not just an internal audit. Examiners look for live processes, tested controls, and traceable evidence that match the regulation’s requirements.

Who Conducts It

1. Your National Competent Authority executes the review locally — examples include BaFin in Germany, Banque de France/ACPR in France, and the Central Bank of Ireland (CBI) in Ireland
2. The European Supervisory Authorities (ESAs) — EBA, ESMA, EIOPA — coordinate guidance and technical standards and support EU-level oversight for designated critical ICT third-party providers

What Examiners Assess

1. ICT risk management and governance
2. Incident response and reporting aligned to RTS/ITS fields and timelines
3. Third-party oversight, including subcontractors and flow-down obligations
4. Testing programs, including TLPT where designated
5. Documentation completeness, versioning, and traceability

What Triggers a Review

1. Routine supervisory cycle
2. Thematic review across a peer set
3. Follow-up on prior findings
4. Post-incident examination

What to Expect from Supervision

EU DORA supervisory reviews mirror established EBA-style ICT examinations — a formal request list, documented controls tied to obligations, live evidence walkthroughs, and findings with dated actions.

Treat it like a structured ICT inspection, not a paperwork exercise.

Read on to see how to prepare for a DORA compliance audit or supervisory review..

Run an internal gap analysis against DORA’s five pillars so you know where you stand before examiners arrive.

How to approach it

1. Use the five pillars as your frame: ICT risk management, incident reporting, resilience testing, third-party risk, information sharing
2. Perform a control-by-control check and capture gaps, owners, and due dates in your risk register
3. Validate that testing calendars run year-round and include retests to prove fixes
4. Confirm major-incident classification and report clocks are defined, rehearsed, and recorded

Validate with existing mappings

1. Map your in-place controls to ISO/IEC 27001 Annex A where relevant
2. Reuse NIS2 artifacts and processes where they meet the same DORA outcomes
3. Record equivalence so auditors can trace each obligation to a live control and evidence

Mock-audit methodology

1. Self-review against Annex I–IV with a regulator-style request list
2. Walk through real incidents and tests, show artifacts live, and time each step
3. Check traceability end-to-end: obligation → control → owner → evidence → last refresh

Checklist example excerpt

Document outcomes from the DORA assessment in your risk register and track owners and due dates on a cadence.

Supervisors expect traceable, verifiable evidence for every obligation. Centralize it so requests are answered quickly and consistently.

Recommended categories

1. Policies & Procedures: Risk management, incident response, outsourcing and third-party rules, change management
2. Registers & Logs: Vendors and subcontractors, incidents, assets, vulnerabilities
3. Reports: Risk reviews, test results and retests, board and committee packs
4. Records & Proof: Meeting minutes, approvals, system exports, screenshots, tickets, version histories

Make it exam-ready

1. Tag each artifact to the obligation and control it proves, with an owner and refresh cadence
2. Keep version history and snapshot sets before major changes
3. Pre-assemble a model incident evidence pack with timestamps, approvals, and draft reports

Keep a simple, category-based layout that mirrors request lists and how teams work, so every artifact maps to a control and the relevant RTS/ITS field.

Create an internal coordination model so requests, walkthroughs, and follow-ups run smoothly.

Build the audit coordination team

1. Risk and Compliance as overall coordinators and owners of the request log
2. IT and Security as technical SMEs for controls, testing, and tooling
3. Legal for regulatory interpretation and escalation thresholds
4. Procurement for contract artifacts and flow-down obligations
5. Business owners for service impacts, continuity assumptions, and approvals
6. Internal Audit for independent challenge and mock reviews

Clarify ownership and communications

1. Single point of contact for the regulator and a clear backup
2. Named evidence custodians per pillar with ready-to-show folders
3. A live request tracker with status, owner, and due date
4. A scribe to capture commitments, actions, and timestamps during meetings
5. An escalation path for overdue items and blockers

Prepare briefing materials for each pillar

1. One-page summary of obligations and how you meet them
2. Control map references to policies, procedures, and technical controls
3. Key artifacts list with location, owner, and last refresh
4. Open issues with owners, due dates, and planned retests
5. Short demo scenarios you can walk through live
6. Talking points and handoffs so SMEs answer consistently

Supervisors test how your program runs in practice, not just whether documents exist.

Sample DORA audit questions

1. How is your ICT risk framework integrated with enterprise risk management?
2. Show us your incident classification logic.
3. When did you last test critical system failovers?
4. Which ICT providers are classed as critical and why?

How to answer well

1. Keep answers short and show the artifact live
2. Reference the control ID and, where relevant, the RTS/ITS field it satisfies
3. Point to time-bound outcomes such as test dates, findings, and retests
4. Name the accountable owner and the next scheduled refresh
5. Log any remediation as a dated action during the session

Run a realistic rehearsal so you can produce clean, complete evidence on demand.

Run a mock supervisory review

1. Use Internal Audit or an external specialist to issue a regulator-style request list
2. Recreate the end-to-end flow: intake, evidence collection, walkthroughs, findings, actions
3. Time every stage so you know where delays occur and who unblocks them
4. Score each area on evidence quality, not just policy presence

Verify reporting clocks in practice

1. Confirm when the clock starts for a major incident and who authorizes the classification
2. Prove your reporting cadence works under pressure — initial within 4 hours after classification and ≤24 hours from detection, intermediate at 72 hours, final at 1 month
3. Check weekends and holidays do not break your timing model
4. Validate draft fields match RTS/ITS templates so data is reusable

Close gaps and keep evidence fresh

1. Assign owners and due dates for each finding and remediation
2. Schedule retests to show closure and attach proof to the original finding
3. Update policies, procedures, and registers and capture version history
4. Snapshot the before/after evidence set so improvements are visible

Use this as a planning model. Adapt durations to your size and complexity.

Days 0–15

1. Confirm scope, owners, and the operating rhythm
2. Stand up the consolidated register for services, systems, data, and vendors
3. Align incident forms to RTS/ITS fields and clocks

Days 16–30

1. Populate the evidence library and assign refresh cadences
2. Publish the annual test plan and schedule retests for open findings
3. Identify critical suppliers and required flow-down updates

Days 31–60

1. Run the first incident tabletop and a continuity drill
2. Launch supplier evidence collection on a calendar
3. Prepare TLPT scoping notes if designated by your authority

Days 61–90

1. Execute a mock review with a realistic request list
2. Close high-risk remediation items and snapshot updated evidence
3. Produce an executive pack with status, gaps, and next-quarter actions

Model Incident Evidence Pack

1. Incident summary including classification and start-clock decision
2. Timeline with key timestamps and approvals
3. RTS/ITS-aligned initial, intermediate, and final report drafts
4. Root-cause notes and impact assessment
5. Evidence of user or service notifications where required
6. Follow-up actions with owners and due dates
7. Links to logs, screenshots, and ticket history

Typical Regulator Request List

1. Governance charter, RACI, and committee minutes
2. Risk register with KRIs/KPIs and treatment plans
3. Annual test plan, results, and retests
4. Incident intake forms and model evidence pack
5. Vendor register, tiering, SLAs, flow-down clauses, and artifact calendar
6. TLPT scope memo if designated and evidence of finding closure
7. Reporting pack for leadership with trends and exception queues

Centralize what matters and automate the admin so your team can focus on substance.

Centralize documentation and evidence

1. One place for policies, registers, reports, and records with consistent tagging to obligations and controls
2. Owner, refresh cadence, and last-updated date on every artifact
3. Version history and snapshots you can export for exam packs

Use workflows for incident reporting and vendor tracking

1. Configurable forms mirror RTS/ITS data fields and clocks so the 4h / ≤24h / 72h / 1 month timeline is built into the workflow
2. Third-party flow-down obligations, evidence calendars, and audit rights tracked in one place
3. Supplier due diligence, contract clauses, and renewal checkpoints in a single register

Automate reminders and generate audit-ready reports

1. Automated reminders for review cycles, evidence refreshes, and retests
2. Prebuilt dashboards and report packs for leadership and regulators drawn from the same source of truth