# Business continuity and disaster recovery Servers starting after a disaster do not prove that business has resumed. People, facilities, suppliers, information and technology must work together. This guide builds from business impact to continuity plans, technical recovery, communications, exercises and improvement records. Numeric examples are fictional, not ready-made organizational targets or mandatory deadlines. Original SecNet educational content with fictional examples, not publication/endorsement by referenced organizations. Page exercise choices last only for the open session; no real organizational data is collected. 2026.10 · 2026-10-21 ## Concepts **BCM / BCMS** — Managing continuity through policy, ownership, resources, measurement and improvement; BCMS is the management system. **BCP** — The plan describing who continues priority business activities during disruption, how, and at what minimum capacity. **DR / DRP** — Controlled recovery of technology/data and its executable plan; supports the technical capability within business continuity. **BIA** — Analysis with business owners of impact over time, priority activities and resource dependencies. **MTD / MTPD** — The disruption window before impact becomes unacceptable; define the chosen term and measurement start in the plan. **RTO** — Target time to resume a service at a defined minimum level; distinguish it from measured recovery time. **RPO** — Target expressed as how far back recoverable data may go before disruption; backup frequency alone does not prove achievement. **WRT** — Time for business validation, reconciliation and backlog after technical restoration. State explicitly whether it is included in RTO. **Failover / failback** — Controlled move to an alternate environment and controlled return; manage data divergence and duplicate processing in both directions. **Hot / warm / cold** — Readiness levels: hot is operating/ready, warm partially prepared, cold provides basic space/infrastructure. Validate actual capacity, data and recovery timing through agreements and tests. **HA / yüksek erişilebilirlik** — An approach to keeping services available after component failure. Shared failures, data corruption and site loss still need recovery strategies. **Call tree** — A notification chain defining who contacts whom, for which event, through which channel, how non-response escalates and who receives acknowledgement. ## Process map ### 1. Bound the service Business owner + continuity coordinator Describe the customer outcome, minimum capacity and dependencies. Approved service scope and owners. ### 2. Impact and objectives Business owner + IT + risk Reconcile disruption tolerance, RTO/RPO and funding assumptions through BIA. Objectives, rationale, measurement start and acceptance owner. ### 3. Plan and communicate Incident commander + team leads Connect activation, deputies, call tree and alternate working. Versioned BCP/DRP and tested alternate communications. ### 4. Recover under control Recovery lead + security + business Validate the clean recovery point and dependency order, then run acceptance tests. Timestamped steps, data reconciliation and decision record. ### 5. Prove and improve Exercise lead + risk owner Compare measured time against objectives; track gaps with owners and deadlines. Test report, residual-risk decision and retest outcome. ## How continuity, DR and incident response fit together Business continuity keeps priority products and services operating at an agreed minimum level during disruption. IT disaster recovery restores their technology and data. Incident response coordinates containment, understanding and safe intervention. A ransomware event may activate all three plans; avoid competing command structures. Describe the protected service: “critical order acceptance and dispatch” is more useful than “ERP”. Include earthquake, fire, flooding, staff unavailability, building access, power, communications and supplier failure. Human safety comes first. Make exclusions and accepted reduced capacity visible rather than promising the entire normal service. Plans that work together | Plan | Main question | Example output | | --- | --- | --- | | BCP | At what minimum capacity can the business continue? | Alternate process, staffing and workplace | | DRP | How do we restore technology and data? | Dependency-ordered, tested recovery steps | | Incident response | How do we contain the threat and preserve evidence? | Containment, investigation and security checks | | Crisis communications | Who receives which verified information, and when? | Approved status message and decision log | - [ ] Business owner, crisis decision-maker and technical recovery lead know their roles. Reference: [ISO 22301:2019 · BCMS; Amendment 1:2024](https://www.iso.org/standard/75106.html), [ISO/IEC 27031:2025 · ICT readiness](https://www.iso.org/standard/27031) ## BIA: assess business impact before technology Bring the service owner, operations, finance, IT and relevant control teams into the business impact analysis. Ask what changes after 30 minutes, four hours, a day or longer. Record safety, contractual, customer, regulatory and reputational impacts alongside revenue. These intervals illustrate analysis; choose periods that match the actual business cycle. Risk assessment examines causes, likelihood and controls; BIA focuses on business impact as disruption continues. Map minimum people, skills, applications, data, facilities and external services for each activity. Assess month-end, payroll and seasonal peaks separately. Do not infer criticality from server count or an unsupported “very critical” label; retain impact assumptions, calculation method and the approving owner. - [ ] BIA results translate into service priorities and recovery dependencies. Reference: [NIST SP 800-34 Rev. 1 · updated 11 November 2010](https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final) ## How to set RTO, RPO and disruption tolerance RTO is a business-driven objective, not a backup-product brochure value. RPO defines the acceptable data-loss window. Specify when disruption measurement starts, the capacity required at resumption and where business reconciliation sits in the timing. Name technical RTO and end-to-end business objectives separately when their boundaries differ. For a fictional order service, assume eight-hour disruption tolerance, a two-hour end-to-end objective and 15-minute RPO. A test with 20 minutes for decisions, 80 for restore and 42 for validation takes 142 minutes, missing the 120-minute target. An 80-minute restore alone does not justify a pass. A 15-minute backup schedule also fails to prove RPO when the last usable recovery point is three hours old. - [ ] Objective, measured result and accepted risk occupy separate fields. Reference: [NIST SP 800-34 Rev. 1 · updated 11 November 2010](https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final), [NIST SP 800-184 · Cybersecurity Event Recovery](https://csrc.nist.gov/pubs/sp/800/184/final) ## Choosing continuity and recovery strategies Compare alternate suppliers, remote work, secondary facilities, manual records, spare capacity and regional recovery against the same business objective. Labels such as hot, warm and cold matter less than usable capacity, data currency, staff access and genuinely independent dependencies. Two regions using one identity provider and administrator account may share a failure mode. Replication can support availability while also copying accidental deletion or encryption. Separate provider recovery commitments from your tenant-level responsibilities for data, identity and configuration. Approve cost, test evidence and unmet objectives together. If the target is unfunded, record an explicit risk decision rather than silently lowering it. - [ ] Shared regional, identity, key, network and supplier failure points were assessed. Reference: [ISO/IEC 27031:2025 · ICT readiness](https://www.iso.org/standard/27031) ## Backup, replication and archive serve different purposes Backup supports return to a recovery point; replication maintains copies; archive supports a defined retention and access purpose. Address scope, version history, offline or immutable copies, separate administration and key recovery together. Inspect who can alter immutability controls, not merely whether a console displays the feature. A file listing or successful backup notification does not prove business usability. Restore into an isolated environment and check decryption, application startup, consistency, access, connectivity and a business transaction. Record the last clean data point and how missing transactions will be reconstructed. Protect test data and plan to reapply deletion rules to restored older records. - [ ] A real restore and business-acceptance evidence exist for the selected copy. Reference: [NIST SP 800-184 · Cybersecurity Event Recovery](https://csrc.nist.gov/pubs/sp/800/184/final) ## Activation, accountability and initial decisions Who may activate the plan, who deputizes, and what thresholds apply? Use observable conditions such as service loss, estimated duration, security and safety impact rather than incident names alone. Record incident ID, confirmed scope, unknowns, initial decision, decision owner and next update time. An immediate restore after a cyber event can reintroduce an attacker or corrupted data. Agree clean-recovery conditions with security; coordinate evidence preservation and containment with restoration. Emergency accounts should be controlled, logged and tested. Never circulate passwords or one-time codes through a call tree. - [ ] Activation authority and an unavailable-person deputy are identified. Reference: [NIST SP 800-184 · Cybersecurity Event Recovery](https://csrc.nist.gov/pubs/sp/800/184/final) ## Call tree: an acknowledged notification chain Each node has an accountable role and deputy: the incident commander alerts team leads, leads notify their on-call staff, and acknowledgements return upward. Record roles, primary/alternate channels, response expectations, escalation thresholds and last validation. Personal contact lists belong in controlled storage, with a protected emergency offline copy rather than a public webpage. Move to the designated deputy and escalation level when someone is unreachable; do not retry indefinitely. Test independence from the outage: a chat application using the failed corporate identity system is not a reliable alternative. Include minimal incident context, the required action and a trusted coordination route. Automated “sent” status does not confirm a person accepted the task. Fictional role-based call tree; the organization sets time limits | Caller → accountable role | If no response | Confirmation required | | --- | --- | --- | | Incident commander → IT recovery lead | Recovery deputy → crisis authority | Task acknowledged and next update time? | | IT lead → identity / network / data teams | Team on-call and second authorized contact | Dependency, access and readiness | | Incident commander → business owner | Business-owner deputy | Minimum activity and manual-working decision | | Incident commander → legal / communications | Approved deputy and external-advice route | Verified facts, recipients and message approval | - [ ] Acknowledgements were tested out of hours and with the primary channel unavailable. Reference: [CISA CRR · Service Continuity resource guide](https://www.cisa.gov/sites/default/files/c3vp/crr_resources_guides/CRR_Resource_Guide-SC.pdf) ## DR runbook and controlled return For each runbook step record inputs, operator role, prerequisites, expected outcome, evidence and stop/escalation route. An illustrative order is coordination and safe access; identity, DNS, time and keys; network/platform; data; applications; integrations; business validation. Validate the actual order against CMDB relationships rather than applying one sequence to every system. Record recovery points, changes and measured times throughout the event. Control split-brain systems, duplicate payments/orders and data divergence. Failback is a separate change requiring reconciliation, capacity, security, approval, rollback and monitoring. Do not equate “server running” with full service recovery without business-owner acceptance. - [ ] Acceptance and stop conditions are included in the runbook. Reference: [NIST SP 800-184 · Cybersecurity Event Recovery](https://csrc.nist.gov/pubs/sp/800/184/final) ## How to plan exercises and evaluate outcomes A tabletop exercise tests decisions and roles; a call-tree test checks communications; a restore test checks technical capability. A controlled end-to-end exercise connects them. Define scope, success criteria, start/stop conditions, safety, rollback and observers in advance. Disruptive production tests require explicit authorization and the appropriate change process. Use response coverage, unreachable critical roles, measured recovery time, last usable data point, failed business tests and age of open actions rather than one overall score. Bound any success statement by scope and assumptions. Assign owners and deadlines; close a corrective action only after a retest demonstrates the fix. - [ ] Gaps have owners, deadlines and a retest decision. Reference: [NIST SP 800-184 · Cybersecurity Event Recovery](https://csrc.nist.gov/pubs/sp/800/184/final), [CISA CRR · Service Continuity resource guide](https://www.cisa.gov/sites/default/files/c3vp/crr_resources_guides/CRR_Resource_Guide-SC.pdf) ## A living plan, assurance and the first 90 days Review plans after system, supplier or role changes, new critical services, relocation and real incidents as well as on a schedule. One starting approach is scope/BIA in the first 30 days; strategies, call tree and runbooks in the next 30; controlled tests and action tracking in the following 30. This 90-day proposal is not a mandated standard or ready-made compliance program. In assurance work look beyond the plan file to version ownership, business approval, alternate access, real test results and evidence that findings were resolved. ISO 22301:2019 with its 2024 amendment is a management-system reference; ISO/IEC 27031:2025 addresses ICT readiness. This original guide does not reproduce the standards or replace certification. - [ ] Plan owner, last test and post-change review route are known. Reference: [ISO 22301:2019 · BCMS; Amendment 1:2024](https://www.iso.org/standard/75106.html), [ISO/IEC 27031:2025 · ICT readiness](https://www.iso.org/standard/27031) ## Decision examples and explained answers ### The team lead is unreachable Corporate email is also down. A critical team lead is not acknowledging the call tree. Which decision is better supported? **Resend on the same channel and mark acknowledged** — Revisit A send receipt is not task acceptance. Dependence on the failed channel leaves a critical role uncovered. Verify acknowledgement and use the deputy/escalation path. **Use an independent channel to the deputy and report to the incident commander** — Supported approach This makes ownership and acknowledgement visible. The alternate channel must actually be independent, contact data current and the responder authenticated. ### The backup job reports success The backup job is green, but decryption keys and application restoration have not been tested. What can the plan claim? **RTO and RPO achieved** — Revisit The job does not prove a usable recovery point or end-to-end timing. That conclusion confuses objectives with measured evidence. **Recovery capability is not yet demonstrated** — Supported approach An isolated restore, data age, key access and business-acceptance test are needed. Compare measurements with objectives and report gaps. ### The objective is 120 minutes Decision takes 20, restore 80 and business validation 42 minutes. The end-to-end objective is 120 minutes. What is the result? **80 minutes; objective achieved** — Revisit That is only the technical restore. The defined end-to-end measurement also includes decisions and validation. **142 minutes; target missed by 22 minutes** — Supported approach This respects the measurement boundary. Record causes and business impact; route improvement or explicit residual-risk acceptance to the accountable authority. ## Official references - [ISO 22301:2019 · BCMS; Amendment 1:2024](https://www.iso.org/standard/75106.html) — Management-system scope and published edition; the standard text is not reproduced here. - [ISO/IEC 27031:2025 · ICT readiness](https://www.iso.org/standard/27031) — Scope of the current guidance standard linking ICT continuity to business objectives. - [NIST SP 800-34 Rev. 1 · updated 11 November 2010](https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final) — Foundational BIA/system-contingency planning reference; not presented as a newly issued publication. - [NIST SP 800-184 · Cybersecurity Event Recovery](https://csrc.nist.gov/pubs/sp/800/184/final) — Recovery, testing and improvement context; organization-specific procedures still need design. - [CISA CRR · Service Continuity resource guide](https://www.cisa.gov/sites/default/files/c3vp/crr_resources_guides/CRR_Resource_Guide-SC.pdf) — People, information, technology and facility dependencies of service continuity.