DORA is not a policy-production project. It requires a financial entity to demonstrate how it protects critical or important functions, responds to disruption, and restores service when its own systems or an ICT provider fail. The strongest evidence is not an approved document. It is a completed test, verified remediation, and a consistent record of decisions.
Regulation (EU) 2022/2554 has applied since January 17, 2025. It connects ICT risk management, incidents, resilience testing, and third-party risk in one operating model. Risk, security, continuity, procurement, and engineering teams therefore cannot maintain independent pictures of the same service.
Map the business function before the technology
Resilience mapping should begin with a critical or important function and the customer journey it enables. Only then should it identify data, applications, infrastructure, people, locations, providers, and subcontractors. A system may be technically available while the function remains unavailable because reference data, authorization, operations staff, or a provider connection is missing.
For each function, name business and technical owners, disruption tolerance, recovery objectives, dependencies, and loss scenarios. RTO and RPO cannot remain inherited values in a business-impact worksheet. They need to match the architecture, component recovery order, and achievable data restoration. A gap between the stated objective and a test result is a risk finding to manage, not a reason to edit the test report.
Maintain the map through change. New integrations, region moves, identity-platform changes, and supplier substitutions should trigger review before the next annual exercise.
Turn the ICT risk framework into operating controls
Every control needs an owner, cadence, evidence source, and escalation rule. A backup control, for example, does not end with a successful backup job. It covers integrity, separation, restoration, elapsed time, and alignment with the recovery point. A vulnerability control connects asset criticality, exposure, patch availability, remediation time, and an accountable exception.
The management body needs a concise risk view, but not a dashboard made only of status colors. Decision material should show the affected function, credible loss scenario, control, current evidence, residual risk, owner, and decision requested. Exceptions require expiry dates and review conditions.
Control design should also expose conflict. If availability objectives depend on a configuration that weakens security, the trade-off must reach the owner rather than being resolved informally by one team.
Join incident handling to regulatory reporting
Regulatory classification cannot run in a separate process days after the technical investigation. The incident record should collect the information needed for assessment: affected clients and counterparties, duration, geographic spread, data loss, service criticality, and economic impact. Each value needs a source and a confidence state so unverified assumptions do not become reported facts.
Commission Delegated Regulation (EU) 2025/301 requires an initial report within four hours of classification as major and no later than 24 hours after awareness, an intermediate report within 72 hours of the initial report, and a final report within one month. Automation can assemble evidence and track the clock, but qualification, approval, and external communication require clear accountability.
Exercise the reporting workflow with incomplete information. The process should support corrections and updates without delaying the first required submission in pursuit of false certainty.
Test capability rather than a presentation scenario
The testing program should include vulnerability assessments, configuration reviews, scenarios, compatibility, performance, end-to-end behavior, and recovery. Financial entities other than microenterprises must ensure that appropriate tests of all ICT systems and applications supporting critical or important functions occur at least yearly. Scope should also respond to risk and material change, not only the calendar.
Selected entities perform threat-led penetration testing at least every three years, with competent authorities able to adjust frequency. TLPT covers some or all critical or important functions and their live production systems, including relevant external dependencies within the validated scope. Findings need remediation plans, validation, and closure evidence. A red-team report alone does not improve resilience.
Test operational decisions as well as controls. Recovery order, emergency access, communications, evidence preservation, and authority to accept degraded service can determine the outcome even when technical safeguards work.
Govern the complete ICT service chain
The register of information should connect contracts to functions, services, data locations, subcontractors, dates, and substitutability. Due diligence must examine provider controls, concentration, and shared dependencies. Two nominally different suppliers may rely on the same cloud region, identity provider, or specialized operator.
Commission Delegated Regulation (EU) 2025/532 specifies factors for assessing subcontracting of ICT services supporting critical or important functions. The entity should understand what is subcontracted, where it is delivered, how the primary provider monitors it, and when a material change triggers objection, additional safeguards, or termination.
Connect contract commitments to engineering evidence. Notification language is weak if operations lack a monitored contact channel; portability clauses are weak if exported data has never been validated.
Make the exit plan executable
A termination clause is not an exit plan. The plan requires export formats, interface maps, migration order, access to documentation and logs, credential revocation, data-deletion rules, and a minimum operating mode during transition. The function owner should know the time, skills, and resources required to move to an alternative.
Exit tests can scale from exporting and validating data, through shifting a portion of traffic, to a full substitution exercise. Their purpose is to expose assumptions hidden by the contract. If an alternative cannot support a critical feature or migration requires unavailable expertise, that risk must reach a decision before an involuntary exit occurs.
Plan for provider distress, not just orderly termination. Access to knowledge, keys, data, and support may deteriorate before the contract officially ends.
Report evidence and residual risk
Useful measures include the share of functions with current dependency maps, recovery-test performance against RTO and RPO, age of open remediation, incident-classification time, completeness of reporting data, the share of critical providers with current resilience evidence, and time to execute an exit scenario. Each measure should have a threshold and a decision recipient.
Avoid compressing the program into one “DORA compliance score.” A high aggregate can conceal one material dependency with no proven recovery. Management should see the most consequential scenarios, current evidence, limitations, and the cost of action or inaction. Resilience improves when lessons from incidents and tests change architecture, contracts, operating procedures, and investment priorities.
Sources
- Regulation (EU) 2022/2554 on digital operational resilience for the financial sector
- Commission Delegated Regulation (EU) 2025/301 on major ICT-related incident reporting
- Commission Delegated Regulation (EU) 2025/532 on subcontracting ICT services
- European Supervisory Authorities: Guide to DORA oversight activities
Cybersecurity
Third-Party Cyber Risk Playbook After DBIR 2025
A supplier questionnaire is not a security control. At most, it records what a provider was willing and able to declare on a particular day. A third-party...
Cybersecurity
Post-Quantum Migration Plan for Critical Systems
A post-quantum migration does not begin with an algorithm choice. It begins by discovering where cryptography exists, how long information must remain...