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?
SecNet.Work · 2026.10 · Sources checked: 2026-10-21
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 AI-assisted SecNet educational content. Examples are fictional, not publication or endorsement by referenced organizations. Implementation decisions require organization-specific approval.
Process map
Select a step to see its owner, action and exit evidence.
Bound the service
- Owner
- Business owner + continuity coordinator
- Action
- Describe the customer outcome, minimum capacity and dependencies.
- Exit evidence
- Approved service scope and owners.
Contents and quick navigation
- Concepts
- How continuity, DR and incident response fit together
- BIA: assess business impact before technology
- How to set RTO, RPO and disruption tolerance
- Choosing continuity and recovery strategies
- Backup, replication and archive serve different purposes
- Activation, accountability and initial decisions
- Call tree: an acknowledged notification chain
- DR runbook and controlled return
- How to plan exercises and evaluate outcomes
- A living plan, assurance and the first 90 days
- Decision practice
- Downloadable workpapers
Put the concepts in context
- 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.
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.
| 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 |
Related primary references: ISO 22301:2019 · BCMS; Amendment 1:2024 ↗ISO/IEC 27031:2025 · ICT readiness ↗
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.
Related primary references: NIST SP 800-34 Rev. 1 · updated 11 November 2010 ↗
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.
Related primary references: NIST SP 800-34 Rev. 1 · updated 11 November 2010 ↗NIST SP 800-184 · Cybersecurity Event Recovery ↗
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.
Related primary references: ISO/IEC 27031:2025 · ICT readiness ↗
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.
Related primary references: NIST SP 800-184 · Cybersecurity Event Recovery ↗
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.
Related primary references: NIST SP 800-184 · Cybersecurity Event Recovery ↗
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.
| 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 |
Related primary references: CISA CRR · Service Continuity resource guide ↗
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.
Related primary references: NIST SP 800-184 · Cybersecurity Event Recovery ↗
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.
Related primary references: NIST SP 800-184 · Cybersecurity Event Recovery ↗CISA CRR · Service Continuity resource guide ↗
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.
Related primary references: ISO 22301:2019 · BCMS; Amendment 1:2024 ↗ISO/IEC 27031:2025 · ICT readiness ↗
Explore the reasoning behind your decision
Fictional learning situations, not an exam, score or compliance assessment. Choices and review checks last only on this open page and are not saved to your account.
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?
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?
Workpapers for your organization
Complete the four blank Markdown workpapers in your controlled organizational environment. The full guide includes tables, all decision rationales and sources.
Full guide and explained examplesMarkdown · ENBIA workpaperAssess the service, time-dependent impact and dependencies together.Call-tree workpaperAdd real contact details only to the controlled organizational copy.DR runbook workpaperDependency-ordered technical steps and business acceptance.Exercise and findings recordSeparate objectives from measurements; assign ownership and retest for each gap.
0 / 10 review checks selected on this page; these do not create operational evidence.
References and next work
References support the subject context; procedures and examples are original SecNet material. Verify legal applicability and current standard editions for actual use.
- ISO 22301:2019 · BCMS; Amendment 1:2024 ↗
Management-system scope and published edition; the standard text is not reproduced here.
- ISO/IEC 27031:2025 · ICT readiness ↗
Scope of the current guidance standard linking ICT continuity to business objectives.
- NIST SP 800-34 Rev. 1 · updated 11 November 2010 ↗
Foundational BIA/system-contingency planning reference; not presented as a newly issued publication.
- NIST SP 800-184 · Cybersecurity Event Recovery ↗
Recovery, testing and improvement context; organization-specific procedures still need design.
- CISA CRR · Service Continuity resource guide ↗
People, information, technology and facility dependencies of service continuity.