DORA Audit Readiness: The 30-Day Sprint That Saves Your Next Examination

The Examination Is Coming. The Question Is When.

On January 17, 2025, DORA became applicable across the European Union. For the first twelve months, most national competent authorities operated in observation mode — collecting Registers of Information, assessing the landscape, building their supervisory capacity. That phase is over.

In 2026, the supervisory posture shifted decisively. Joint Examination Teams (JETs) — established under Delegated Regulation (EU) 2025/420 — are now operational. These multi-authority teams have the power to conduct on-site inspections, request evidence, interview management body members, and issue binding recommendations. The ECB's 2024 cyber resilience stress test across 109 directly supervised banks already demonstrated the supervisory appetite: banks were tested on their ability to respond to and recover from a severe but plausible cyber incident, and the results highlighted that recovery capabilities require significant improvement.

The enforcement toolkit is substantial. Under Art. 50-52, competent authorities can impose administrative penalties and remedial measures. Several Member States have transposed penalty frameworks allowing fines of up to 2% of total annual worldwide turnover, or up to EUR 10 million for individuals in management positions. The EBA has published detailed guidelines on supervisory expectations.

This is not a drill. This is your preparation framework.

Why 30 Days Is Enough (If You Start Now)

The 30-day sprint is not about building compliance from scratch. It assumes your institution has been implementing DORA requirements since the two-year transition period began in January 2023. The sprint is about closing the gap between "we've been working on it" and "we can demonstrate it under examination conditions."

The critical insight is that most examination findings are not about missing capabilities — they are about missing evidence. Industry data consistently shows that approximately 60% of audit findings relate to evidence gaps: documentation that exists but cannot be located, controls that function but lack test records, decisions that were made but lack audit trails, and corrective actions that were completed but never formally closed.

A 30-day sprint addresses this evidence gap systematically.

The Sprint Framework: Week by Week

Figure 1: The 30-day audit readiness sprint. Week 1 diagnoses gaps, Week 2 closes critical ones, Week 3 tests readiness through a mock examination, and Week 4 polishes documentation and briefs the team.

Week 1: Evidence Inventory and Gap Analysis (Days 1-7)

The first week is diagnostic. Before you can close gaps, you must map them.

Day 1-2: Pillar I — ICT Risk Management Framework (Art. 5-16)

Run through your asset register. Does every critical business function have mapped ICT dependencies? Does every asset have an owner, a criticality classification, and lifecycle status? Art. 8(1) requires the register to be "updated on a regular basis and at least once a year." If your last update predates your examination window, that is a finding.

Day 3-4: Pillar II — Incident Management (Art. 17-23)

Verify your incident classification criteria against Art. 18 materiality thresholds. The thresholds are specific: number of clients affected, transaction volume impacted, duration, geographic spread, data losses, economic impact. Your incident management process must classify against these criteria, not against ITSM severity levels.

Check: do you have evidence of the three-phase reporting process (initial notification within 4 hours, intermediate report within 72 hours, final report within 1 month)? Even if no major incident occurred, do you have evidence that the process exists, has been tested, and that staff know how to trigger it?

Day 5-6: Pillar III — Resilience Testing (Art. 24-27)

This is where most institutions are weakest. Art. 24(1) requires a "digital operational resilience testing programme as an integral part of the ICT risk management framework." Not optional. Not aspirational. Integral.

Day 7: Pillar IV — Third-Party Risk (Art. 28-44) and Cross-Cutting Gaps

The Register of Information is the single most auditable artifact under DORA. It must be complete, current, and available on request. Check that every ICT third-party contractual arrangement is registered, classified by criticality, and that contracts for critical services include Art. 30 mandatory provisions (audit rights, data location, subcontracting notification, exit clauses).

Compile your gap inventory into a severity-ranked backlog. Critical gaps (missing evidence for core requirements) go to Week 2. Medium gaps (incomplete documentation) go to Week 3. Low gaps (formatting, cross-references) go to Week 4.

Week 2: Critical Gap Closure (Days 8-14)

Week 2 is execution. Take your critical gap inventory and close the top items.

Priority 1: Missing board-level documentation

Art. 5(2) places explicit accountability on the management body. If your board has not formally approved the ICT risk management framework, or if no documented annual review exists, this is a critical gap. Draft the approval record, schedule an emergency board agenda item if necessary, and ensure the minutes reflect that the management body has "full responsibility for the implementation of the ICT risk management framework."

Priority 2: Asset register completeness

If your ICT asset register has gaps — shadow IT, unregistered cloud services, unmapped dependencies — Week 2 is when you close them. Focus on critical and important functions first (Art. 3(22) definition). Every critical function must have a complete dependency chain: business process, supporting applications, databases, infrastructure, and third-party services.

Priority 3: Testing evidence

If your testing programme lacks execution evidence, prioritize at least one documented resilience test before the examination. A properly documented test with findings and remediation tracking is infinitely more valuable than a comprehensive testing programme that has never been executed.

Priority 4: Incident response readiness

Conduct a tabletop exercise of your DORA incident reporting process. Document it. Include the classification decision tree, the reporting timeline, and role assignments. This evidence demonstrates that your institution can execute the three-phase reporting within mandated timelines.

Week 3: Mock Examination (Days 15-21)

Week 3 simulates the examination itself. The purpose is to discover gaps that internal teams have become blind to.

The Mock Protocol:

1. Select an examiner: Internal audit, external consultant, or a senior team member who was not involved in implementation. The examiner must be independent — this is where Separation of Duties applies to the preparation process itself.

1. Follow the supervisory playbook: Examiners typically start with the Register of Information (Art. 28(3)), then move to the ICT risk management framework (Art. 6), then drill into specific pillars based on the institution's risk profile.

1. Request evidence chains: For any control or process, the examiner should ask: "Show me the evidence." Not the policy. Not the procedure. The evidence that the policy was followed, the procedure was executed, and the outcome was recorded.

1. Test response times: Ask the team to produce specific evidence within 30 minutes. If it takes longer than that to locate a board approval, a test report, or an incident classification record, the evidence management system is a liability.

Week 4: Polish, Documentation, and Readiness Confirmation (Days 22-30)

The final week is about presentation and confidence.

Day 22-24: Documentation polish. Ensure all documents have version numbers, approval dates, and clear ownership. Cross-reference between documents: the ICT risk management framework should reference the testing programme, which should reference the incident management process, which should reference the asset register. Examiners follow links. Broken references are findings.

Day 25-27: Evidence packaging. Organize evidence into an "audit pack" structure. Per DORA pillar, create an index that maps each requirement to the corresponding evidence artifact, its location, its date, and its owner. The examiner should be able to navigate from any DORA article to the relevant evidence in under two minutes.

Day 28-29: Readiness confirmation. Run a final checklist pass (see the 50-item checklist below). Any remaining red items must have a documented remediation plan with target dates — examiners accept "we identified this gap and are remediating it by [date]" far more readily than "we didn't realize this was required."

Day 30: Team briefing. Brief all staff who may interact with examiners. They should know: where evidence lives, who owns each pillar, what the examination process looks like, and what not to say (do not volunteer information outside the question scope; do not speculate on compliance status; do not refer to informal processes that are not documented).

The 50-Item DORA Audit Readiness Checklist

Pillar I — ICT Risk Management (12 Items)

1. ICT risk management framework approved by management body (Art. 6(1))
2. Management body accountability documented (Art. 5(2))
3. Annual ICT risk report to management body (Art. 14)
4. ICT asset register complete and current (Art. 8(1))
5. Business impact analysis with derived RTO/RPO (Art. 11(1))
6. Data classification applied to all assets (Art. 8(4))
7. ICT security policies approved and distributed (Art. 9)
8. Anomaly detection and monitoring in place (Art. 10)
9. ICT business continuity plans documented (Art. 11)
10. Communication plans for incidents established (Art. 14)
11. Learning and evolving process documented (Art. 13)
12. Capacity management and monitoring active (CDR Art. 9)

Pillar II — Incident Management (8 Items)

1. Incident classification criteria aligned with Art. 18 thresholds
2. Three-phase reporting process documented (Art. 19)
3. Incident response roles and escalation paths defined
4. Post-incident review process with root cause analysis (Art. 13)
5. Staff trained on DORA incident classification
6. Evidence of at least one incident response exercise
7. Regulatory notification templates prepared
8. Incident log maintained with timeline and impact data

Pillar III — Resilience Testing (10 Items)

1. Digital operational resilience testing programme documented (Art. 24)
2. Testing programme approved by management body
3. Annual vulnerability assessments completed (Art. 25)
4. Scenario-based testing derived from current threat landscape
5. Recovery testing with measured RTO vs target RTO (Art. 11(6))
6. Testing findings tracked with remediation evidence
7. TLPT assessment completed (if in scope per Art. 26)
8. Testing covers all critical and important functions
9. Independent testers used where required
10. Test results reported to management body

Pillar IV — Third-Party Risk (12 Items)

1. Register of Information complete and current (Art. 28(3))
2. All ICT third-party arrangements classified by criticality
3. Art. 30 contractual provisions verified for critical arrangements
4. Concentration risk assessment documented (Art. 29)
5. Exit strategies documented for critical providers (Art. 28(8))
6. Due diligence evidence for onboarding decisions
7. SLA monitoring and performance evidence
8. Subcontracting arrangements mapped and approved
9. CTPP designations reviewed for impact (ESA designation list)
10. Annual third-party risk review completed
11. Data processing and storage locations documented (Art. 30(2)(c))
12. Audit rights clause confirmed in critical contracts

Pillar V and Cross-Cutting (8 Items)

1. Information sharing arrangements documented (Art. 45)
2. Threat intelligence integration evidenced
3. Audit trail integrity verified (append-only, tamper-detected)
4. RBAC and access controls documented and tested
5. Staff awareness and training records maintained
6. Proportionality assessment documented (Art. 4)
7. Cross-module evidence traceability (finding, evidence, control, test linked)
8. Remediation SLAs tracked for all open findings

What Examiners Actually Look For

Based on early supervisory signals from the ECB, ESMA, and national competent authorities, examination focus areas cluster around five themes:

1. Governance substance, not form. Examiners distinguish between management bodies that genuinely oversee ICT risk and those that rubber-stamp reports. They look at board minutes, challenge questions, decision records, and whether the management body has ever rejected or modified an ICT risk proposal. Art. 5(2) accountability is personal — directors who cannot articulate their institution's top ICT risks face follow-up questions.

2. Testing that produces evidence, not reports. A testing programme that generates PowerPoint decks is not testing. Examiners want to see measured recovery times, documented deviations between plan and actual, corrective actions raised from test findings, and evidence that those corrective actions were tracked to closure. The chain must be unbroken: test plan, execution evidence, findings, remediation, retest.

3. Third-party risk that reflects reality. The Register of Information is the first document examiners request. It must be complete, accurate, and demonstrate that the institution understands its ICT supply chain — including sub-outsourcing arrangements and concentration risk. An institution that cannot identify its top 5 third-party dependencies by criticality has a structural gap.

4. Incident readiness under pressure. Examiners may run a live scenario: "A critical service provider has experienced a data breach affecting your customer data. Walk me through your next 4 hours." The response must demonstrate Art. 18 classification, Art. 19 reporting timelines, internal escalation, customer notification, and evidence preservation. Hesitation or confusion is a finding.

5. Continuous improvement, not point-in-time compliance. DORA Art. 13 requires that financial entities "learn and evolve" from ICT-related incidents and resilience testing. Examiners look for feedback loops: did last year's test findings inform this year's risk assessment? Did an incident trigger an asset register update? Is the framework iterating based on evidence?

The Evidence Architecture That Survives Examination

Figure 2: The evidence chain that survives examination. When an examiner pulls any thread, the entire chain should follow — from risk assessment through control, test, finding, remediation, and board reporting.

The institutions that perform best under examination share a common characteristic: their evidence is organized as an integrated chain, not a collection of standalone documents.

When an examiner pulls any thread, the entire chain should follow. If the chain breaks — a finding that cannot be traced to a test, a risk that cannot be linked to an asset, a control that has no test evidence — the examiner has found a gap.

Key Takeaways

• The supervisory shift from observation to active examination is underway in 2026. JETs are operational. Penalty frameworks are in place. The question is when, not whether.
• 60% of examination findings relate to evidence gaps, not missing capabilities. The 30-day sprint closes this gap systematically.
• Week 1 diagnoses. Map every DORA requirement to existing evidence. Identify critical, medium, and low gaps.
• Week 2 executes. Close critical gaps: board approvals, asset register completeness, testing evidence, incident readiness.
• Week 3 tests. Run a mock examination with an independent examiner. Discover what internal teams have become blind to.
• Week 4 polishes. Cross-reference documents, package evidence, brief the team.
• The 50-item checklist organized by DORA pillar provides a comprehensive verification framework.
• Evidence chains matter more than individual documents. Examiners follow links. Build traceability from risk to control to test to finding to remediation.