# ICT Business Continuity & Disaster Recovery (DORA) > Draft the ICT business continuity policy and disaster recovery plan required by DORA Articles 11-12, covering recovery objectives, switchover procedures, backup policies, continuity testing, and crisis management. Tags: DORA, Business Continuity, Disaster Recovery, ICT Continuity, EU Regulation, Financial Services ## Example Prompts - Draft our ICT business continuity policy per DORA Art. 11 - Define RTO/RPO for all critical ICT services supporting business functions - Design the annual BCP/DRP testing program with switchover exercises - Document crisis communication procedures for major ICT disruptions URL: https://rakenne.app/skills/dora-business-continuity-ict/index.md Try this skill: https://rakenne.app/a/?skill=dora-business-continuity-ict ## Overview Draft the ICT business continuity policy and disaster recovery plan mandated by the EU Digital Operational Resilience Act (DORA), Articles 11-12 and RTS 2024/1774. Generic ISO 22301 business continuity plans are not enough for DORA because the regulation imposes ICT-specific continuity requirements: separate BCP and DRP documents, documented switchover and failback procedures, "appropriately ambitious" RTO/RPO validated through testing, a dedicated ICT crisis management function, and geographically separated backup for critical functions. ## What It Covers - **ICT Business Continuity Policy** (Art. 11(1)-(5)) -- scope, disruption scenarios, switchover procedures, crisis management function, crisis communication, interim measures - **ICT Disaster Recovery Plan** (Art. 11(6)) -- recovery procedures per ICT service, backup infrastructure activation, full-stack recovery testing, data integrity verification - **Backup and Restoration Policy** (Art. 12) -- backup scope and frequency, restore procedures, physical/logical separation, geographic separation for critical functions, retention schedule - **BCP/DRP Testing Program** (Art. 11(6)-(7)) -- annual test calendar, switchover exercises, third-party provider participation, test reporting and lessons learned - **Crisis Communication Procedures** (Art. 11(2)(e)) -- internal, client, public, and competent authority communication with backup channels - **Recovery Objectives Matrix** -- RTO, RPO, and maximum tolerable downtime per critical function, mapped to supporting ICT services ## Example Conversation > **You:** We are a mid-size payment institution regulated under DORA. We already have a generic corporate BCP, but our auditor flagged that it does not meet the DORA-specific ICT continuity requirements. Can you help us create the required documents? > > **Agent:** I will draft the three documents DORA requires: a dedicated ICT Business Continuity Policy (Art. 11), a separate ICT Disaster Recovery Plan (Art. 11(6)), and a Backup and Restoration Policy (Art. 12). First, I need to understand your entity context. What are your critical or important functions under Art. 3(22), and which ICT services support them? > > **You:** Our critical functions are real-time payment processing, client account management, and regulatory reporting. Payment processing runs on our core banking platform hosted in AWS eu-west-1, with a warm standby in eu-central-1. Account management is on the same platform. Regulatory reporting uses a separate data warehouse. > > **Agent:** Good. I have mapped three critical functions to their supporting ICT services. Now I need recovery objectives. For payment processing, what is the maximum acceptable downtime before you breach your PSP licence conditions, and how much transaction data can you afford to lose? > > **You:** Payment processing cannot be down for more than 2 hours, and we cannot lose more than 5 minutes of transaction data. Account management can tolerate 4 hours. Regulatory reporting can tolerate 24 hours since we have batch windows. > > **Agent:** I have built the Recovery Objectives Matrix. Payment processing: RTO 2h, RPO 5min. Account management: RTO 4h, RPO 1h. Regulatory reporting: RTO 24h, RPO 24h. I will now draft the switchover procedures for failing over the core banking platform from eu-west-1 to eu-central-1, and the crisis communication procedures. After drafting, I will run `dora_bcp_checker` to verify all Art. 11-12 requirements are covered. > > **Agent:** The checker reports zero errors and two warnings: one recommending that you document failback procedures for returning from eu-central-1 to eu-west-1, and one suggesting you add interim measures for degraded-mode operations during switchover. I will add both sections now. ## Sample Output Excerpt Excerpt from an ICT Business Continuity Policy drafted for a payment institution, showing the Recovery Objectives Matrix and switchover procedure sections. --- ### 3. Recovery Objectives Matrix | Critical Function | Supporting ICT Service | RTO | RPO | MTD | Tier | |---|---|---|---|---|---| | Real-time payment processing | Core banking platform (AWS eu-west-1) | 2 hours | 5 minutes | 4 hours | 1 | | Client account management | Core banking platform (AWS eu-west-1) | 4 hours | 1 hour | 8 hours | 1 | | Regulatory reporting | Data warehouse (AWS eu-west-1) | 24 hours | 24 hours | 48 hours | 2 | All RTOs are validated through annual switchover testing per Art. 11(7). Where testing reveals the target cannot be met, the infrastructure improvement plan in Annex C applies. ### 5. Switchover Procedures (Art. 11(4)) **5.1 Pre-conditions for switchover activation** Switchover from primary (eu-west-1) to standby (eu-central-1) is initiated when: - The ICT crisis manager declares a continuity event (see Section 8, Crisis Management Function) - Primary region availability drops below the threshold for two consecutive health checks (10 minutes) - A cyber attack renders the primary region unsafe for continued operation **5.2 Switchover sequence** 1. ICT crisis manager authorises switchover; communication lead sends initial notification to management body and affected business units 2. Database replication lag is verified (must be under RPO threshold before cutover) 3. DNS failover is triggered via Route 53 health-check automation; TTL is pre-set to 60 seconds 4. Load balancer in eu-central-1 is promoted to active; health checks confirm application availability 5. Smoke tests are executed against the standby environment (payment processing end-to-end, account query, balance check) 6. Communication lead confirms switchover completion to clients and competent authority **5.3 Failback procedures** After the root cause in eu-west-1 is resolved, failback follows the reverse sequence. Data synchronisation from eu-central-1 back to eu-west-1 is verified before cutover. A rollback plan is maintained in case failback introduces data integrity issues. ## Extension Tools The skill includes a validation tool that checks BCP/DRP documents for completeness against all DORA Art. 11-12 requirements. **`dora_bcp_checker`** -- Reads a BCP/DRP JSON document and validates that every mandatory section is present. The checker reports ERRORs for missing requirements and WARNINGs for incomplete sections. ### What the tool checks | Check area | What it validates | Severity | |---|---|---| | **Separate BCP and DRP** | Both `bcp` and `drp` top-level sections exist as distinct documents (Art. 11(1), Art. 11(6)) | ERROR if missing | | **Critical functions** | At least one critical function defined; each has mapped ICT services, RTO, and RPO (Art. 11(3)-(4)) | ERROR if missing | | **Third-party mapping** | Critical functions include ICT third-party provider references (Art. 28-29) | WARNING if missing | | **Switchover procedures** | Documented procedures for switching from primary to standby ICT infrastructure (Art. 11(4)) | ERROR if missing | | **Failback procedures** | Procedures for returning from standby to primary after resolution | WARNING if missing | | **Backup policy scope** | Backup scope, frequency, restore procedures, and restore verification defined (Art. 12(1)-(2)) | ERROR if missing | | **Physical/logical separation** | Backup systems separated from primary (Art. 12(4)) | ERROR if missing | | **Geographic separation** | Geographically separated backup for critical functions (Art. 12(5)) | ERROR if missing | | **Annual testing** | BCP/DRP testing program with annual cadence (Art. 11(7)) | ERROR if missing | | **Switchover testing** | Testing includes switchover exercises (Art. 11(4), Art. 11(7)) | ERROR if missing | | **Third-party test participation** | ICT providers participate in continuity testing (Art. 11(7), Art. 30(2)(g)) | ERROR if missing | | **Crisis communication** | Internal, client, public, and competent authority communication procedures (Art. 11(2)(e)) | ERROR if missing | | **Backup channels** | Out-of-band communication channels documented | WARNING if missing | | **Crisis management function** | Dedicated function with activation criteria and escalation procedures (Art. 11(5)) | ERROR if missing | | **Impact analysis** | Impact analysis of severe disruptions on critical functions (Art. 11(3)) | WARNING if missing | | **Interim measures** | Measures for continuing critical functions during recovery | WARNING if missing | ### Example validation output ``` ======================================================================== DORA BCP/DRP -- Completeness Check (Art. 11-12, RTS 2024/1774) ======================================================================== --- Errors (must fix) --- [ERROR] Missing failback procedures... (omitted for brevity) [ERROR] Backup policy missing restore verification (Art. 12(2)). --- Warnings (recommended) --- [WARNING] Missing interim measures for continuing critical functions during recovery. ======================================================================== ``` Run the tool after drafting or updating your BCP/DRP to verify regulatory completeness before submission. ## Getting Started Activate the *ICT Business Continuity & Disaster Recovery (DORA)* skill and the agent will walk you through each section of the required documents. Have this information ready: - Your entity type under DORA Art. 2(1) (credit institution, payment institution, investment firm, insurer, etc.) and your competent authority - A list of your critical or important functions as defined under Art. 3(22) and the ICT services that support each one - Current recovery infrastructure: secondary data centres, cloud disaster recovery regions, warm/hot standby environments - Existing BCP/DRP documentation (if any) and any audit findings or gap assessments - Backup infrastructure details: on-site and off-site backup, geographic separation, replication methods, backup frequency - ICT third-party service providers supporting critical functions, including cloud and managed service providers - Your target recovery time objectives (RTO) and recovery point objectives (RPO) for each critical function, or the business constraints that will help the agent recommend appropriate targets If you have already completed the *DORA ICT Risk Framework* skill, the agent will reference the asset inventory and risk assessment from that workspace -- you will not need to re-enter ICT asset and dependency information. The skill produces four deliverables: the ICT Business Continuity Policy, the ICT Disaster Recovery Plan, the Backup and Restoration Policy, and the BCP/DRP Testing Program. Each document includes a cross-reference table mapping its sections to the specific DORA articles they satisfy. --- Back to [Skill Library](https://rakenne.app/skills/index.md)