DORA Article 11 sets out specific requirements for business continuity policies and plans (BCP) for financial entities. The DORA BCP requirements are more prescriptive than what most financial entities have traditionally maintained — they require documented policies, tested plans, and specific recovery capabilities for ICT disruptions.
What DORA Requires for Business Continuity
DORA's BCP requirements apply to ICT-related disruptions specifically. They complement rather than replace broader business continuity planning:
Policy: A documented ICT business continuity policy, approved by the management body.
BCP document: Plans specifying how the entity will respond to severe ICT disruptions, maintain critical functions, restore normal operations, and communicate during the disruption.
Crisis management procedures: Plans for managing the response to major incidents at a senior level.
ICT disaster recovery plan: Specific to the recovery of ICT systems, data, and infrastructure after a disruption.
Testing: All plans must be tested at defined intervals. Testing evidence must be documented.
The Business Continuity Policy
The ICT BCP policy is the governing document — it sets the principles and framework for continuity planning. It must cover:
- The scope of ICT systems and services covered
- The definition of critical functions and their minimum service levels
- Recovery objectives (RTO and RPO) for critical systems
- Governance — who is responsible for BCP development, testing, and invocation
- Review and update schedule
The management body must approve this policy. This is an explicit DORA requirement — the board cannot delegate BCP policy approval to IT or operations.
Recovery Time and Recovery Point Objectives
DORA requires defined RTOs and RPOs for all critical ICT systems. These must be realistic and achievable, not aspirational:
RTO (Recovery Time Objective): The maximum time a system can be unavailable after a disruption. For payment processing: typically 2–4 hours. For core banking: typically 4–8 hours for full restoration, with degraded mode operation possible sooner.
RPO (Recovery Point Objective): The maximum data loss acceptable — expressed as time. For transaction data: typically near-zero (minutes). For less critical data: hours.
Financial entities must conduct testing that demonstrates RTOs and RPOs are actually achievable — not just that the backup infrastructure exists.
The BCP Document: Required Contents
The BCP must include:
Critical functions and systems inventory:
- Which business functions are critical (cannot be suspended without significant impact)?
- Which ICT systems support those functions?
- What is the minimum service level for each critical function during a disruption?
Activation criteria:
- What events trigger BCP invocation?
- Who has authority to invoke the BCP?
- How are staff notified of BCP activation?
Response procedures:
- Step-by-step procedures for each major disruption scenario (ransomware, data centre failure, key vendor failure, etc.)
- Roles and responsibilities during the response
- Communication plan — internal (staff), external (customers, regulators)
Recovery procedures:
- How critical systems are restored
- Data recovery procedures
- Validation steps before resuming normal operations
Alternative operating procedures:
- How critical functions are maintained in a degraded mode while systems are recovered
- Manual backup procedures where system recovery takes hours
Dependencies:
- Key ICT third-party providers for critical systems
- Contact details for emergency support from each critical provider
- Escalation paths if providers do not respond within expected timeframes
Disaster Recovery Plan
The ICT disaster recovery plan covers system and data recovery specifically:
- Backup architecture (frequency, retention, off-site or air-gapped storage)
- Recovery site or cloud recovery environment
- Detailed recovery procedures for each critical system
- RTO and RPO for each system
- Testing schedule and results
BCP Testing Requirements
DORA requires BCP and DR plans to be tested. Testing must cover:
Tabletop exercises: Scenario-based discussions — walkthrough of how the team would respond to specific disruption scenarios. At minimum annual.
Technical recovery tests: Actual activation of recovery procedures — restoring from backup, failing over to DR site, testing manual procedures. At minimum annual for critical systems.
Full DR tests: End-to-end test of the disaster recovery plan including full system restoration from backup. Frequency depends on the criticality of systems.
Documentation: All tests must be documented with:
- Test scenario and objectives
- Participants
- Results — did recovery complete within RTO and RPO?
- Findings and remediation actions
Communication During Disruptions
DORA requires communication planning for BCP scenarios:
Internal communication: How staff are notified of a BCP event, where they can access information during the disruption (if primary systems are unavailable), and what their role is.
Customer communication: How customers are notified of service disruptions, what information is shared, and through what channels.
Regulatory notification: Integration with the DORA incident reporting procedure — major ICT incidents that trigger BCP also trigger the 4-hour notification obligation.