Business Continuity Under DORA
Business continuity is a central requirement within DORA's Pillar 1 on ICT risk management. Article 11 requires every financial entity to establish, maintain, and periodically review an ICT business continuity policy. Article 12 builds on this by requiring dedicated ICT response and recovery plans that specify how the entity will restore operations after an ICT-related disruption.
Together, these two articles create a comprehensive continuity framework: the policy (Art. 11) sets out the strategic objectives and governance structure, while the response and recovery plans (Art. 12) provide the operational detail needed to execute during a crisis. Both must be approved by the management body and subjected to regular testing.
For financial entities already familiar with traditional business continuity management, DORA adds a specific ICT dimension. The regulation recognises that modern financial services depend heavily on technology infrastructure, and that continuity planning must address ICT-specific risks such as cyber-attacks, system failures, data corruption, and third-party service outages. This is distinct from broader business continuity planning, which also covers physical disruptions, pandemics, and other non-ICT scenarios.
ICT Business Continuity Policy (Art. 11)
Article 11 requires financial entities to establish a comprehensive ICT business continuity policy as an integral part of their overall ICT risk management framework. This policy provides the strategic foundation for all continuity and recovery activities.
Business Impact Analysis
The policy must be informed by a business impact analysis (BIA) that identifies critical and important functions, assesses the potential impact of severe disruptions, and quantifies the maximum tolerable downtime for each function. The BIA forms the basis for all recovery objectives and resource allocation decisions.
Recovery Objectives (RPO and RTO)
Financial entities must define recovery point objectives (RPO) and recovery time objectives (RTO) for each critical function. RPO determines the maximum acceptable data loss measured in time, while RTO sets the maximum acceptable duration before a function must be restored. These objectives must be realistic and supported by the entity's technical infrastructure.
Critical Function Identification
The entity must maintain a current inventory of all ICT systems, assets, and processes that support critical or important functions. This mapping enables the entity to understand dependencies, prioritise recovery efforts, and allocate resources effectively during a disruption.
Communication Plans
The ICT business continuity policy must include communication arrangements for crisis situations. This covers internal escalation paths, notification of competent authorities, communication with clients and counterparties, and coordination with critical third-party ICT service providers. Clear communication protocols reduce response times and prevent confusion during an incident.
Regular Review and Update
The policy must be reviewed and updated at least annually, or more frequently following significant changes to the ICT environment, organisational structure, or threat landscape. Lessons learned from incidents, tests, and near-misses must be incorporated into policy revisions. All changes require management body approval.
Response and Recovery Plans (Art. 12)
Where Article 11 sets the strategic framework, Article 12 requires the operational detail. Financial entities must develop, document, and maintain ICT response and recovery plans that translate the continuity policy into actionable procedures.
ICT response plans must define the immediate actions to be taken when an ICT disruption is detected. This includes incident classification criteria, initial containment measures, roles and responsibilities of the response team, decision authority for activating recovery procedures, and the triggers for escalation to senior management or the management body.
ICT recovery plans must detail the step-by-step procedures for restoring disrupted functions within the defined RTO and RPO targets. This encompasses switching to backup or redundant systems, restoring data from backups, validating the integrity of restored systems and data, and the criteria for declaring that normal operations have been resumed.
Escalation procedures must be clearly defined, specifying when and how incidents are escalated internally, when competent authorities must be notified, and how communication with external stakeholders (clients, market participants, payment systems) is managed. The escalation framework must align with the entity's incident reporting obligations under DORA Articles 17-23.
Lessons learned. After every activation of response or recovery plans, the entity must conduct a post-incident review to identify what worked, what failed, and what must be improved. These lessons must be documented and fed back into the continuity policy and recovery plans. Where the disruption was caused by or involved a third-party ICT provider, the review must also assess whether the contractual arrangements and exit strategies remain adequate.
Testing Requirements for BCP
A business continuity plan that has never been tested provides false assurance. DORA requires financial entities to test their ICT business continuity plans regularly to verify that they work in practice and that staff are prepared to execute them under pressure.
Annual testing. ICT business continuity plans must be tested at least once per year. For entities with complex ICT environments or those supporting critical financial market functions, more frequent testing may be appropriate and expected by supervisors.
Scenario-based exercises. Testing must go beyond simple tabletop discussions. DORA expects scenario-based exercises that simulate realistic disruption events, including cyber-attacks, ransomware incidents, data centre failures, cloud service outages, and simultaneous failures of multiple systems. Scenarios should be varied across testing cycles to cover different types of disruptions and different critical functions.
Documentation and reporting. All test results must be thoroughly documented, including the scenario used, participants, timeline of events, systems and functions tested, issues identified, and remediation actions. Test results must be reported to the management body, and significant deficiencies must be addressed through remediation plans with clear deadlines and accountable owners.
Broader resilience testing. BCP testing forms part of the wider digital operational resilience testing programme established under DORA Articles 24-27. This broader framework includes vulnerability assessments, network security reviews, gap analyses, and — for designated entities — threat-led penetration testing (TLPT) on a three-year cycle. BCP testing and resilience testing should be coordinated to avoid gaps and duplication, and to provide a comprehensive picture of the entity's operational resilience.
Third-Party Continuity
Financial entities increasingly depend on third-party ICT service providers for critical functions, from cloud infrastructure and payment processing to core banking platforms and cybersecurity services. DORA recognises that a continuity plan which only covers the entity's own systems is incomplete.
Critical provider coverage. The ICT business continuity policy must explicitly address scenarios in which a critical ICT third-party service provider suffers a disruption or becomes unavailable. This means continuity plans must include alternative arrangements, manual fallback procedures, or secondary providers that can maintain service delivery while the primary provider recovers.
Exit strategies. DORA requires financial entities to maintain credible exit strategies for all critical third-party ICT arrangements. An exit strategy must enable the entity to withdraw from the arrangement without disrupting its business activities, without limiting compliance with regulatory requirements, and without compromising the continuity and quality of services provided to clients. Exit strategies must be tested and updated as part of the regular continuity planning cycle.
Concentration risk. Where multiple critical functions depend on a single ICT third-party provider, or where several providers rely on the same underlying sub-contractor, the entity faces concentration risk. DORA requires financial entities to assess and manage this concentration risk as part of their continuity planning, ensuring that a single point of failure cannot bring down multiple critical functions simultaneously. The Register of Information required under DORA Art. 28 provides the data foundation for this assessment.
DORA and ISO 22301
ISO 22301 is the international standard for business continuity management systems (BCMS). It provides a structured approach to business continuity that includes policy development, business impact analysis, strategy formulation, plan development, exercising and testing, and continual improvement. Many financial entities have already adopted ISO 22301 as part of their broader resilience programmes.
The good news for entities with existing ISO 22301 certification is that the standard maps closely to DORA's business continuity requirements. Both frameworks require a management-body-approved continuity policy, regular business impact analysis, defined recovery objectives, documented response and recovery plans, periodic testing, and a cycle of continual improvement based on lessons learned.
Where ISO 22301 meets DORA
If your entity already holds ISO 22301 certification, you have a strong foundation for DORA compliance on business continuity. The BIA process, plan documentation, testing regime, and management review cycle from ISO 22301 all align with DORA Articles 11 and 12. However, you will likely need to enhance your existing framework with DORA-specific elements: ICT-focused recovery objectives (RPO/RTO for specific ICT systems rather than just business processes), explicit coverage of third-party ICT continuity, concentration risk assessment, incident reporting integration, and the specific governance reporting requirements that DORA mandates.
Entities without ISO 22301 can still meet DORA's requirements by building an ICT business continuity programme directly from Articles 11 and 12. However, adopting the ISO 22301 structure provides a well-tested management system framework that simplifies both initial implementation and ongoing maintenance. For organisations also subject to other regulatory frameworks, ISO 22301 provides a common language and structure that supports cross-framework compliance. See also how ISO 27001 maps to DORA's broader ICT risk management requirements.
How DORA GRC Helps
DORA GRC includes a dedicated BCP module that supports financial entities in building and maintaining their ICT business continuity arrangements in line with Articles 11 and 12.
Structured BCP workspace. Define your critical functions, map ICT dependencies, set RPO and RTO targets, and document your response and recovery plans in a structured format that aligns directly with DORA requirements. The module guides you through each element of Articles 11 and 12 to ensure nothing is missed.
Testing and exercise tracking. Schedule, document, and track the results of your BCP tests. Record scenarios, participants, findings, and remediation actions. Generate management body reports that summarise testing outcomes and open remediation items.
Third-party continuity integration. BCP plans connect directly with the third-party risk management module, so your exit strategies, concentration risk assessments, and provider continuity arrangements are maintained in one place and stay in sync.
Gap analysis. The free DORA assessment tool evaluates your current BCP maturity against DORA requirements and identifies specific gaps that need to be addressed. For a complete view of all DORA pillars and platform capabilities, explore the features page or DORA compliance guide.
Frequently Asked Questions
DORA Article 11 requires financial entities to establish a comprehensive ICT business continuity policy that includes business impact analysis, defined RPO and RTO targets for critical functions, communication plans for crisis situations, and regular review cycles. Article 12 adds the requirement for detailed ICT response and recovery plans that specify how to restore operations after a disruption, including switching to backup systems, escalation procedures, and post-incident lessons learned. Both the policy and plans must be approved by the management body and tested at least annually.
DORA requires testing at least once per year. Tests must use scenario-based exercises that simulate realistic disruptions such as cyber-attacks, infrastructure failures, and third-party outages. All test results must be documented and reported to the management body, and any deficiencies identified must be addressed through remediation plans with clear timelines. For entities with complex environments or systemically important roles, supervisors may expect more frequent testing.
Yes. DORA requires that ICT business continuity arrangements explicitly cover critical third-party ICT service providers. This means continuity plans must account for provider disruptions, include exit strategies for critical arrangements, and assess concentration risk where multiple functions depend on a single provider. Financial entities must ensure their contractual arrangements with critical providers include adequate continuity and disaster recovery provisions.
ISO 22301 is the international standard for business continuity management systems, and it maps closely to DORA Articles 11 and 12. Both frameworks require management-approved policies, business impact analysis, defined recovery objectives, documented plans, periodic testing, and continual improvement. Entities with ISO 22301 certification have a strong foundation for DORA BCP compliance, though they may need to add DORA-specific elements such as ICT-focused RPO/RTO definitions, third-party continuity provisions, concentration risk assessments, and regulatory reporting integration.