CompTIA SY0-701: Business Continuity & Disaster Recovery — Study Guide

By Laurynas Brazys · 20 July 2026 · #comptia #sy0-701 #certification #exam-prep #study-guide

Part of the CompTIA Security+ SY0-701 — Complete Study Guide. Practice with verified answers in the CompTIA exam hub, or take timed practice tests on ExamRoll.io.

Business continuity (BC) and disaster recovery (DR) form the operational backbone of organizational resilience. Where security controls attempt to prevent incidents, BC/DR planning acknowledges that some disruptions — ransomware detonations, hurricanes, fiber cuts, power grid failures, or cascading cloud outages — will occur regardless of preventive posture. The discipline focuses on quantifying tolerable disruption, engineering recovery pathways, and validating those pathways before they are needed.

Recovery Objectives: RTO, RPO, MTTR, and MTBF

Two metrics anchor every recovery conversation, and conflating them is one of the most persistent errors in planning documents. The Recovery Time Objective (RTO) expresses the maximum acceptable duration a system can remain unavailable after a disruption. It is measured on the wall clock, from the moment of failure to the moment services are restored to a usable state.

The Recovery Point Objective (RPO), by contrast, measures data loss tolerance — how far back in time the organization is willing to lose transactions. RPO is measured backward from the moment of failure to the last known-good recovery point. An RPO of fifteen minutes means the business can tolerate losing up to fifteen minutes of writes; consequently, backups, replication, or transaction log shipping must occur at least that frequently.

The clearest way to internalize the distinction is a timeline: RPO sits to the left of the outage (data), and RTO sits to the right (downtime). A synchronous database replica across two availability zones might deliver an RPO approaching zero and an RTO of seconds via automated failover. A nightly tape backup shipped offsite delivers, at best, a 24-hour RPO and an RTO measured in days.

Two supporting metrics round out the vocabulary. Mean Time To Repair (MTTR) is the observed average time to restore a failed component, while Mean Time Between Failures (MTBF) describes reliability. High MTBF and low MTTR are the engineering targets that make aggressive RTOs achievable.

Business Impact Analysis

RTO and RPO values are not chosen by IT — they emerge from a Business Impact Analysis (BIA). The BIA systematically identifies business processes, maps them to supporting technology assets, and quantifies the operational, financial, regulatory, and reputational damage that accrues as an outage lengthens. A payroll system may have a modest RTO of 48 hours because paychecks are cut biweekly, while a hospital’s electronic medication administration record may require an RTO of minutes because patient safety degrades immediately.

The BIA produces several downstream artifacts: a criticality tier for each system, the Maximum Tolerable Downtime (MTD) which is the absolute ceiling beyond which recovery is meaningless, and the RTO/RPO pairs that drive architecture choices. It also surfaces dependencies — recovering an order-management system without also recovering its authentication provider, database, and payment gateway yields nothing usable.

Recovery Site Strategies

When a primary facility is lost, workloads must move somewhere. The three canonical alternate site types trade cost against speed of recovery.

A hot site is a fully operational duplicate of production. Hardware is racked, software is licensed and patched, and data is continuously replicated. Failover can be measured in minutes or even seconds when combined with global load balancing. Hot sites deliver the lowest RTO and RPO but carry the highest cost — effectively doubling infrastructure spend.

A warm site occupies the middle ground. Hardware and connectivity are in place, and some baseline software is installed, but data is not continuously replicated — it must be restored from backup, and final configuration is completed during activation. Warm sites typically recover in hours to a day.

A cold site provides physical space, power, cooling, and internet connectivity, but little else. Servers must be shipped or procured, operating systems installed, applications deployed, and data restored from backups. A cold site is inexpensive to maintain but may require days or weeks to bring online. Treating a cold site as a rapid failover destination is a recurring planning failure; it is appropriate only for systems whose RTO is measured in days.

Modern architectures increasingly rely on cloud-based recovery — pilot light, warm standby, or multi-region active/active — which blurs these categories. A pilot-light design keeps minimal core services running (a replicated database, for example) while the rest of the stack is spun up from infrastructure-as-code templates on demand.

Failover, Failback, and High Availability

Failover is the act of shifting traffic from a failed primary to a standby. It may be automatic, driven by health checks and DNS or BGP changes, or manual, requiring human authorization. Failback — returning to the original primary once it is repaired — is often neglected in planning, yet it carries its own risk: data written to the failover site during the outage must be reconciled and replicated back before the switch, or writes will be lost.

Redundancy at the component level supports these strategies. Load balancers distribute traffic across active nodes. Clustered databases replicate synchronously within a region and asynchronously across regions. RAID protects against disk failure but is not a backup. Redundant network paths, dual power supplies fed from separate PDUs, and diverse ISP circuits eliminate single points of failure inside the datacenter.

Power Continuity: UPS, Generators, and Fail-Open Decisions

Electrical continuity underpins everything. An uninterruptible power supply (UPS) bridges the gap between utility failure and generator start — typically 5 to 15 minutes of battery runtime. Generators provide sustained backup power, usually diesel or natural gas, and must be load-tested regularly. Fuel contracts, transfer switch operation, and generator start sequences all fail silently until exercised. A quarterly test under actual load is far more revealing than an idle monthly start.

Security devices raise a separate question during power or software failure: should they fail open or fail closed? A fail-open firewall passes traffic when the device dies, preserving availability at the cost of security. A fail-closed firewall blocks all traffic, preserving security at the cost of availability. Physical access controls face the same dilemma — an electronic door lock that fails closed may trap occupants during a fire, so life-safety codes typically mandate fail-open (also called fail-safe) behavior for egress.

Testing: Tabletop, Walkthrough, Simulation, and Full Interruption

A plan that has never been tested is a hypothesis. Testing progresses along a spectrum of realism and risk.

A tabletop exercise gathers stakeholders around a conference table to talk through a scenario — “a ransomware event has encrypted the primary VMware cluster at 2 a.m. Sunday; walk me through the next six hours.” It surfaces gaps in documentation, contact lists, decision authority, and assumptions. It carries no operational risk and is the appropriate starting point.

A walkthrough or structured review examines the plan document itself for accuracy. A simulation introduces role-playing and injects. A parallel test brings the recovery site online alongside production without cutting over. The most rigorous form, a full interruption test, actually fails production over to the recovery site — expensive, disruptive, and the only test that proves the plan actually works.

Every test must include the backout plan: how to revert if the failover itself fails or corrupts data. Generator load tests, backup restoration drills, and communication tree activations belong on the same recurring calendar as software patching.

Practical Scenario: Untested Recovery Plan Fails During Real Incident

A regional bank’s DR plan specified a warm site with a four-hour RTO for its core banking system. The plan had been written three years prior and reviewed annually on paper but never tested through activation. When a fire suppression system discharge destroyed the primary data center’s cooling infrastructure, the bank attempted to activate the warm site. The team discovered that the backup server’s OS was two major versions behind the current production version and incompatible with the current application release. The database backup jobs had been silently failing for six weeks due to a certificate expiration on the backup agent. The actual recovery took 31 hours — nearly eight times the documented RTO — and the bank incurred regulatory scrutiny for the gap between its documented and actual recovery capabilities. The lesson: RTO and RPO are engineering commitments, not aspirational targets, and they must be validated through realistic testing at least annually.

← Data Security · All domains · Endpoint →

Practice these questions → · Timed practice on ExamRoll.io →