At 2:10 a.m., during a real storage failure, the on-call engineer opens the database failover runbook. Step 4 says to promote the replica on db-dr-02. That server was decommissioned eighteen months ago, and nobody had run the runbook since it was written. A plan that hasn't been tested describes what someone believed was true on the day they wrote it.
On the CompTIA Security+ SY0-801 exam, continuity testing, disaster recovery and capacity planning sit under objective 3.4, which expects you to explain why resilience and recovery matter in security architecture. This lesson separates business continuity from disaster recovery, walks through how a recovery is carried out, compares the main ways to test a plan, and covers capacity planning for people, technology and infrastructure.
Business continuity keeps the business working, while disaster recovery restores the technology
Business continuity (BC) is about keeping essential business functions running during and after any disruption: a building fire, a pandemic, a supplier going bankrupt or a cyberattack. It covers people, workplaces, processes, communications and manual workarounds, not just computers.
Disaster recovery (DR) is the part of that effort focused on technology: restoring systems, data and infrastructure after a disruptive event, usually by restoring from backups or failing over to a recovery site. DR is a subset of continuity, not a synonym for it.
A hospital hit by ransomware shows both at once. Nurses switch to paper charts and documented downtime procedures so patients are still admitted and treated. That's continuity. Meanwhile IT rebuilds the electronic records servers at the recovery site from clean backups. That's disaster recovery.
A third process runs alongside in a cyberattack: incident response, which contains the attacker and removes their access. The three have to be coordinated. Restoring servers before responders have closed the attacker's way in simply gives them fresh systems to encrypt.
On the exam, wording about keeping operations going, manual workarounds or alternate workspaces for staff points to business continuity. Wording about restoring servers, recovering data or failing over systems points to disaster recovery. The plans themselves, as governance documents, are covered in the governance section, and the business impact analysis that sets their priorities is covered in the risk management section.
Disaster recovery brings systems back in a planned order
A recovery starts with a declaration. A named person with the authority to do so declares a disaster, which activates the plan, the recovery site contract and the spending authority that comes with it. Hesitation here is a common reason organizations miss their recovery targets: teams spend hours trying to fix the primary site before anyone makes the call.
Systems then come back in dependency order, because applications can't start without the services beneath them. A typical sequence:
- Network connectivity, firewalls and remote access for the recovery team
- DNS, DHCP and time synchronization
- Identity: Active Directory or the identity provider
- Databases and storage
- Application servers
- Web front ends and user access
Recovery isn't finished when the servers boot. Business users validate that the application works and the data is correct before service is declared restored.
Recovering from a cyberattack adds steps that a fire doesn't need. Systems are restored into a clean, isolated environment; restored data is scanned; credentials are reset, including the Active Directory krbtgt account, which is reset twice to invalidate forged Kerberos tickets; and the original entry point is closed before anything reconnects.
Failback, the return to the primary site once it's repaired, is planned like a migration. Data changed while running at the recovery site has to be copied back, which often makes failback riskier than the original failover.