Skip to content
FR

Disaster Recovery, Backups, Business Continuity, and Physical Safety

Step 35 of 38

CISSP Disaster Recovery: RTO, RPO, Backups, and Business Continuity

Introduction

CISSP disaster recovery turns business recovery objectives into tested backups, resilient services, and continuity procedures. This lesson completes Domain 7, Security Operations (13% of the exam, ISC2 exam outline effective 15 April 2024). It covers tasks 7.10 to 7.15: implement recovery strategies, implement disaster recovery (DR) processes, test disaster recovery plans, participate in business continuity (BC) planning and exercises, implement and manage physical security, and address personnel safety and security concerns. The business impact analysis and continuity requirements were introduced in Domain 1; here you turn those requirements into working recovery capabilities and test them.

The central goal is to sustain or recover critical business functions after disruption while protecting people and information. Fire, flood, ransomware, a failed storage array, a pandemic, or a cloud region outage all create the same question: how fast can we resume critical processes, and how much data can we afford to lose?

Learning objectives

After this lesson you can:

  1. Derive RTO, RPO, MTD, and WRT from a business impact analysis and use them to select recovery strategies.
  2. Compare backup types and storage strategies, and design backups that survive ransomware.
  3. Compare recovery sites (hot, warm, cold, mobile, cloud, mutual aid) and multi-site designs.
  4. Distinguish resilience, high availability, fault tolerance, and recovery, and apply redundancy such as RAID, clustering, and failover.
  5. Describe the DR process and select the right test type (read-through, walkthrough, tabletop, simulation, parallel, full interruption).
  6. Describe the BC plan lifecycle and the relationship between BCP, DRP, and incident response.
  7. Select physical controls for perimeters and interiors and address personnel safety (travel, duress, emergency management).

1. Recovery objectives and strategies

1.1 The key metrics

Metric Meaning Question it answers
MTD / MAO (maximum tolerable downtime / maximum acceptable outage) The longest a process can be unavailable before the organization suffers unacceptable harm "When does the business break?"
RTO (recovery time objective) Target time to restore a system or service after disruption; must be shorter than MTD "How fast must IT restore it?"
WRT (work recovery time) Time to verify data and resume normal work after systems are restored "How long to catch up after the technology works?"
RPO (recovery point objective) Maximum tolerable data loss measured in time "How old can the restored data be?"
MTTR / MTBF Mean time to repair / mean time between failures Reliability and maintenance planning

When RTO measures technical restoration and WRT is a separate subsequent business-recovery interval, plan RTO + WRT ≤ MTD. Define the boundaries consistently; frameworks and organizations may include validation or work resumption within their RTO. RPO drives backup frequency or replication; RTO drives the type of recovery site and automation.

1.2 Worked example: choosing a strategy from the BIA

Scenario. An online broker's order platform has MTD of 4 hours, WRT of 1 hour, and RPO of 5 minutes. A document archive has MTD of 5 days and RPO of 24 hours. The budget is limited.

Step by step.

  1. For the order platform, RTO must be at most MTD − WRT = 3 hours. A five-minute RPO cannot be met by nightly backups alone. Add a tested mechanism such as frequent log shipping or replication, with recovery points and lag monitored against that objective. Retain independent backups because replication can copy corruption or ransomware.
  2. A three-hour RTO makes an unequipped cold site unsuitable. A prepared warm standby, hot site, or cloud active/passive design may fit if provisioning, dependencies, restoration, validation, and cutover have been timed successfully. A site label alone does not prove its RTO.
  3. For the archive, successful daily backups can support a 24-hour RPO if the latest usable copy is available after the disaster. A cold site or cloud rebuild may be economical if tested restoration plus work resumption fits within five days.
  4. Tier the applications: spend more where the BIA shows higher impact.

Why not use a hot site for everything? It may exceed lower-impact systems’ needs and cost more; its actual recovery performance still requires testing. Why not nightly backup for everything? It fails the order platform's 5-minute RPO.

1.3 Backup types

Type What is copied Backup time Restore
Full All selected data Longest Simplest: one set
Incremental Changes since the preceding full or incremental backup in the chain Shortest Slowest: last full plus every incremental in order
Differential Changes since the last full backup Medium, grows each day Faster: last full plus the latest differential
Continuous data protection Records changes or transaction history continuously, subject to implementation Can support a short RPO Recovery depends on retained history, integrity, and replay time
Snapshots Point-in-time state at configured intervals RPO depends on snapshot frequency and usable copies May depend on the original storage; independent protected copies are still needed

Archive bits and change tracking decide what counts as "changed". In the traditional archive-bit model, incremental clears the bit; differential does not. Modern products may use journals or changed-block tracking instead; confirm the product’s chain and restore semantics.

1.4 Backup strategy and storage

  • 3-2-1 rule: at least three copies, on two different media types, with one copy off site. A modern extension is 3-2-1-1-0: one copy offline or immutable, and zero errors after restore verification.
  • Immutable and offline backups reduce ransomware exposure when production identities cannot modify them. Immutability, logical isolation, and a physical air gap are different controls: verify retention-lock mode, administration boundaries, key recovery, and restoration procedures rather than treating the labels as interchangeable.
  • Encryption protects backups in transit and at rest; protect the keys separately, because losing the key means losing the data.
  • Testing: a backup is not proven until a restore is. Perform regular restore tests and measure the time against RTO.
  • Off-site storage requires secure transport, distance sufficient to avoid the same regional disaster, and access controls. Electronic vaulting sends changes to a remote site in batches; remote journaling sends transaction logs more frequently; database shadowing/mirroring keeps a live copy.
  • Retention follows data lifecycle and retention requirements and the data owner’s approved rules, including preservation holds.

1.5 Recovery sites

Site Readiness Typical recovery time Cost Notes
Hot Fully equipped, current data, staffed or ready Minutes to hours Highest Mirrors production
Warm Hardware and connectivity, but data must be restored Hours to days Medium Common compromise
Cold Space, power, and cooling only Days to weeks Lowest Hardware must be procured
Mobile Trailers with equipment Days Varies Useful when a site must be near people
Cloud (DRaaS) Infrastructure on demand, pre-built templates Minutes to hours depending on design Pay-as-you-go Shared responsibility; test failover and network
Mutual aid / reciprocal agreement Partner provides capacity Variable Low Hard to enforce; capacity and compatibility risk
Multiple processing sites Several active sites Near-zero High Also supports load balancing

Key design points: the recovery site must be far enough from the primary to avoid the same disaster, with staffing, remote administration, connectivity, and supplier access planned for the selected location. Security controls at the recovery site must satisfy equivalent security and compliance objectives (access control, monitoring, patching) because attackers target weaker secondary sites.

1.6 Resilience, high availability, and fault tolerance

  • Resilience is the ability to absorb or adapt to disruption.
  • High availability (HA) keeps services running with minimal downtime using redundancy, clustering, and load balancing (for example, 99.99% availability allows about 52 minutes of downtime per year).
  • Fault tolerance continues operating without interruption after a component fails, usually through full redundancy (dual power supplies, mirrored systems).
  • Disaster recovery restores operations after a major outage; HA tries to prevent the outage from being noticed.

Common mechanisms:

Mechanism Purpose Note
RAID 1 (mirroring) Redundancy for disk failure A two-disk mirror survives one disk loss and provides 50% usable raw capacity
RAID 5 (striping with parity) Performance plus single-disk fault tolerance Needs at least 3 disks
RAID 6 Two parity blocks Survives two disk failures
RAID 10 Mirroring plus striping High performance and redundancy
Clustering / failover Another node takes over Active-active or active-passive
Load balancing Distribute traffic across healthy targets The load balancer and its dependencies also need redundancy; distribution alone does not remove every single point of failure
UPS and generators Power continuity UPS bridges the gap until generators start
Diverse carriers and paths Network redundancy Avoid shared conduits

RAID is not a backup. It protects against disk failure, not against deletion, corruption, or ransomware, which are replicated across the array immediately.

Single point of failure (SPOF) analysis is a core exercise: identify components whose loss stops the service, then add redundancy or accept the risk.

2. Disaster recovery processes

2.1 Phases

A disaster recovery plan (DRP) addresses restoring IT and operations after a significant disruption. Typical process:

  1. Response: detect, assess damage, declare a disaster per the plan's criteria and authority.
  2. Personnel: activate the DR team, contact lists, and decision makers; ensure safety of people first.
  3. Communications: inform employees, executives, customers, regulators, and vendors with prepared messages and alternative channels (the main systems may be down).
  4. Assessment: evaluate systems, facilities, and data.
  5. Restoration: follow the approved dependency and business-priority map, bringing up required infrastructure and security services before dependent applications.
  6. Validation and reconstitution: verify data, functionality, security, and business acceptance before declaring normal operation. Training and awareness prepare staff before activation.
  7. Lessons learned: update the plan after tests and real events.

Restoration order matters: bring up core dependencies first (power, network, directory services), because applications rely on them. During restoration, security controls such as access control and logging should be reinstated early, not "after things calm down".

2.2 Returning to the primary site

The recovery team restores the critical functions at the alternate site. The salvage team repairs the original facility. When the original or replacement permanent site is ready, use an approved, dependency-aware return plan with data synchronization, validation, staged cutover, rollback criteria, and business approval. Piloting a low-impact workload can reduce risk, but “least critical first” is not a universal order: shared services and tightly coupled applications may need different sequencing. Successful return includes validation and formal plan deactivation, followed by decommissioning the temporary arrangements and securely sanitizing any data left at the alternate site.

2.3 Plan content and maintenance

A good plan contains: scope and objectives, roles and responsibilities, activation criteria, contact lists, system dependencies and recovery order, step-by-step procedures, vendor and SLA details, locations of backups and credentials, and communication templates. Store copies off site and offline (the plan must be available when the network is not) and protect them as confidential information, because they describe weaknesses. Review after every significant change (new application, acquisition, new facility) and at least annually.

3. Testing disaster recovery plans

3.1 Test types, from least to most disruptive

Test What happens Disruption Typical purpose
Read-through / checklist review Team members review the plan separately None Find missing items and outdated contacts
Walkthrough / structured walk-through Team goes through the plan together, step by step None Validate logic and responsibilities
Tabletop exercise Facilitated discussion of a scenario None Decision making, communication, gaps
Simulation Scenario is played with some actions performed (for example, activating the call tree, restoring a test system) Low Test coordination and procedures
Parallel test Recovery systems are brought up and processing is run in parallel with production Low risk to production Prove the recovery site works without stopping production
Full interruption test In-scope production processing stops and moves to the alternate site Highest direct disruption risk in this comparison Strong evidence for the tested cutover; requires careful authorization and recovery safeguards

Exam trick: the parallel test processes data at the alternate site while production continues, then compares results. A full interruption test intentionally stops in-scope production. Other technical tests can still cause unintended disruption. “Full-scale exercise” describes scope and participation in some frameworks and does not necessarily mean a production shutdown. For most organizations the best path is to progress through the types as maturity grows: do not start with a full interruption test.

3.2 Test planning and results

  • Define objectives, scope, success criteria (did we meet RTO and RPO?), schedule, and rollback in case the test itself causes trouble.
  • Obtain management approval and inform stakeholders.
  • Document results, issues, and fixes. Track corrective actions to closure.
  • Include third parties (cloud, carriers, suppliers) where the recovery depends on them.
  • Test restores of backups, failover of clusters, and manual workarounds.

3.3 Worked example: choosing the right test

Scenario. A regional bank documented its DR plan last year. It has never run an exercise. The CIO wants to know if the plan works but does not permit an intentional interruption to customer transactions. The recovery site is a warm site.

Recommended path.

  1. Start with a read-through and a walkthrough to fix outdated contact lists and unclear roles (no disruption).
  2. Run a tabletop with executives and the communications team on a ransomware scenario to test decisions such as when to declare a disaster and who speaks to regulators.
  3. Perform a simulation that activates the call tree and restores a non-critical system from backup, measuring time.
  4. Run a parallel test of the core banking application at the warm site using a copy of recent data, and compare outputs and recovery times with RTO. Isolate test data and outbound effects so duplicate processing cannot send real payments or notifications.
  5. Only after repeated success, consider a full interruption test for a low-impact window if the board wants maximum assurance.

Why not full interruption first? It risks real outages and breaches the CIO's constraint. Why not stop at tabletop? Discussion does not prove that restores, networks, and licenses work at the alternate site.

4. Business continuity

4.1 BCP, DRP, and incident response

Plan Focus Scope
Business continuity plan (BCP) Keep critical business functions running or resume them within MTD Whole organization: people, process, facilities, suppliers, IT
Disaster recovery plan (DRP) Restore IT services and data Technology-focused part of continuity
Incident response plan (IRP) Detect and handle security incidents Triggers DR/BC if impact is severe
Crisis management / communication plan Executive decisions and external messaging Governs leadership response
Business resumption plan Return business processes to their intended operating state Business units and dependencies
Occupant emergency plan (OEP) Protect and account for people during emergencies, including evacuation or sheltering Life safety

4.2 BC planning lifecycle

NIST and ISO 22301 style steps: project initiation and management support, scope, business impact analysis (critical processes, dependencies, MTD, RTO, RPO), strategy selection, plan development, training and awareness, testing/exercises, maintenance and review. Senior management must approve and fund the plan; without executive sponsorship the program fails. Include external dependencies such as suppliers, carriers, outsourced services, and utilities, and require evidence of their continuity capabilities.

4.3 Continuity exercises and communications

Exercises involve business units, not just IT. Typical scenarios include loss of a building, loss of a key supplier, loss of a cloud region, pandemic staffing shortage, and cyberattack. Test communication: call trees, mass notification tools, and out-of-band channels. Document lessons learned, assign owners, and feed results into plan updates and awareness training.

5. Physical security

5.1 Principles

Physical security applies defense in depth using layers: deter, delay, detect, assess, respond. Follow CPTED (Crime Prevention Through Environmental Design): natural surveillance, territorial reinforcement, and natural access control through landscaping, lighting, and layout. Controls must be proportional to asset value and based on a risk assessment. Life safety always outranks property protection.

5.2 Perimeter controls

Control Function Notes
Fences Deter and delay Select height, anti-climb design, gates, visibility, and response arrangements from the threat assessment and local requirements; no generic height guarantees resistance
Bollards Deter or resist vehicle approach Select tested vehicle-barrier ratings, foundations, and layout for the threat; decorative bollards may not stop a vehicle
Lighting Deter and support surveillance Consistent coverage, avoid glare and dark spots
CCTV Detect, record, deter Needs monitoring and retention; integrate with alarms; consider privacy law
Guards and patrols Assess and respond Flexible, but costly and variable
Guard dogs Detect and deter Liability and safety considerations
Access-control vestibules (mantraps) Reduce tailgating with controlled sequential entry Detection, accessibility, and emergency egress must be designed and tested
Turnstiles Control flow Do not stop determined tailgating alone
Badge readers Authenticate access Pair with logs and review

5.3 Interior controls

  • Locks: key locks, combination locks, electronic locks, smart/biometric locks. Locks delay; they do not stop a determined attacker. Design for fail-safe (unlocks on power loss to protect life) versus fail-secure (stays locked). Provide code-compliant free emergency egress. A lock can remain fail-secure against entry while mechanical exit hardware still permits escape; the lock’s power-loss state and freedom to exit are separate design questions.
  • Intrusion detection: door contacts, motion detectors (infrared, microwave, ultrasonic), glass-break sensors, and alarm monitoring.
  • Secure areas: server rooms, wiring closets, evidence rooms, and media vaults with logged access, no shared accounts, and visitor escort.
  • Visitor management: sign-in, identification, badge with expiry, escort, and log retention.
  • Clean desk, secure storage, and equipment protection: cable locks, safes, and locked cabinets.
  • Utilities and environmental: redundant power, HVAC, water detection, and fire suppression (covered in lesson 10), which also support recovery.

5.4 Worked example: protecting a small data room

Scenario. A 200-person firm keeps its servers in a back office with a hollow-core door and a key lock. Cleaning staff, contractors, and several employees have copies of the key. A recent audit found a stolen laptop and an unexplained server reboot.

Solution.

  1. Replace the door with a solid-core door and a frame resistant to forcing; install an electronic badge lock with logging and fail-secure operation for the room, with emergency egress hardware that always allows exit.
  2. Restrict access to named administrators; remove the old key distribution and re-key.
  3. Add a door contact and motion sensor tied to an alarm service, and a camera at the entrance.
  4. Require escorted, logged access for contractors and cleaning outside the room.
  5. Add environmental sensors (temperature, water) and review access logs monthly.

Why not just add a better key lock? Keys cannot be audited or revoked quickly, and copies remain in circulation. Why not only cameras? Cameras detect and record but do not prevent entry or tell you who was authorized.

6. Personnel safety and security

Task 7.15 addresses concerns for people:

  • Travel safety: pre-trip risk assessment, safe-country guidance, secure accommodation, awareness of local laws, tracking and check-in procedures, and device security (clean loaner laptops, no sensitive data stored, use VPN, disable Wi-Fi/Bluetooth when unused, beware of border device inspection and public charging ports).
  • Duress: a covert way to signal coercion, such as a duress code at a keypad or alarm that appears to work normally but silently alerts security, or a duress word on the phone. Train staff not to resist robbery; life comes first.
  • Emergency management: occupant emergency plan (evacuation routes, assembly points, wardens, accountability roll call), fire drills, first aid, shelter-in-place, medical emergencies, workplace violence procedures.
  • Security training and awareness: new hires and regular refreshers on physical security, tailgating, visitor escort, and reporting.
  • Insider threats and personnel awareness: watch for behavior changes, enforce separation of duties and access reviews, offer support programs, and give confidential reporting channels.
  • Social media risks: public posts can reveal travel plans, building layouts (photos of badges, whiteboards), or security procedures that support social engineering.
  • MFA fatigue: attackers flood a user with push approvals hoping they accept one. Counter with number matching, phishing-resistant MFA (FIDO2), rate limiting, and awareness training.

7. Pitfalls and exam tips

  • People first: when a question involves life safety versus equipment, choose life safety.
  • RTO must be shorter than MTD; RPO sets backup or replication frequency, not recovery speed.
  • In a conventional full-plus-incremental chain, incremental backups reduce each backup’s volume but require more restore steps. Product design and data volume determine actual performance.
  • RAID is not backup. Replication copies mistakes and ransomware too.
  • Parallel test: both systems run at the same time. Full interruption test: production stops.
  • The recovery site needs security equal to the primary site.
  • Return to a permanent site through an approved, validated sequence based on dependencies, data consistency, risk, and business priorities.
  • Ensure free emergency egress; fail-secure ingress can coexist with mechanical escape hardware. Follow applicable building and life-safety requirements.
  • Without senior management support and funding, continuity programs fail.

8. Mini case study: flooded data center

Case. A manufacturing firm's primary data center floods after a pipe break at 03:00. The BIA values: order management MTD 8 hours, RTO 4 hours, RPO 15 minutes; email MTD 24 hours; HR system MTD 7 days. The firm has a warm site 300 km away with hardware but restored from nightly tape, and no tested failover. Backups are sent off site weekly. The DR plan lists a call tree that is stored on the flooded file server.

Questions and commented solutions.

  1. Which requirements are not met by the current design? Order management needs 15-minute RPO and 4-hour RTO. Nightly tape (24-hour RPO) and weekly off-site storage fail RPO; restoring from tape at a warm site likely fails RTO. The plan was not available because it was stored only on the affected server.
  2. What is the correct response sequence? Ensure personnel safety first; declare the disaster according to criteria; activate the DR team using an offline copy of the call tree; restore core dependencies at the warm site first (network, identity, DNS), then order management, then email, then HR.
  3. What improvements follow? Replicate order data every few minutes (log shipping or asynchronous replication), keep off-site and immutable backups daily, store plan copies off site and offline, perform parallel tests at the warm site, and consider DRaaS to cut recovery time.
  4. How should the return to a permanent site occur? Validate the repaired facility and security services, synchronize data, and use a rehearsed dependency-aware cutover plan. A low-impact HR pilot is reasonable only if dependencies and data flows permit it; verify each stage and retain rollback until business acceptance.
  5. What lessons feed the BC plan? Include facility risks (water detection, raised floors), supplier dependency checks, staff communications, and manual workarounds for orders while systems are down.

For the engineering behind site resilience and environmental protection, review physical security, facilities, and system lifecycle.

Key terms

  • MTD/MAO, RTO, RPO, WRT: maximum downtime; target restore time; tolerable data loss in time; work recovery time.
  • Hot, warm, cold site: fully ready; hardware but no data; empty space.
  • DRaaS: disaster recovery as a service.
  • 3-2-1 rule: three copies, two media, one off site.
  • Immutable backup: cannot be altered or deleted during retention.
  • Incremental / differential backup: changes since last backup / since last full.
  • RAID: redundant array of independent disks (not a backup).
  • Fault tolerance / HA: continue without interruption / minimize downtime.
  • Tabletop, walkthrough, simulation, parallel, full interruption: DR test types.
  • BCP / DRP / OEP: continuity, disaster recovery, and occupant emergency plans.
  • CPTED: crime prevention through environmental design.
  • Mantrap: controlled sequential-entry vestibule that reduces tailgating while preserving compliant emergency egress.
  • Fail-safe / fail-secure: unlock on failure / stay locked on failure.
  • Duress code: secret signal for coercion.

Summary checklist

  • I can derive RTO and RPO from MTD, WRT, and the BIA and pick strategies accordingly.
  • I can compare full, incremental, and differential backups and design ransomware-resistant backups.
  • I can choose between hot, warm, cold, mobile, cloud, and mutual aid sites.
  • I can distinguish HA, fault tolerance, resilience, and DR and explain why RAID is not a backup.
  • I can describe the DR process, restoration order, and the return to the primary site.
  • I can pick the right DR test and explain the difference between parallel and full interruption.
  • I can explain BCP, DRP, IRP, and OEP and the BC lifecycle.
  • I can select perimeter and interior physical controls, including fail-safe and fail-secure choices.
  • I can address travel safety, duress, emergency management, insider threats, and MFA fatigue.

Official sources