Incident response vs business continuity vs disaster recovery: choose the correct plan.

Start with the outcome the organization needs now

The plans coordinate but are not interchangeable. Security may isolate a compromised network to contain an attacker while continuity leaders move customer support to an alternate process and the recovery team prepares clean infrastructure. The shared incident commander must balance safety, evidence, business priorities and recovery objectives.

The Security+ incident response process

Phases can overlap. Analysts may discover another compromised account during recovery and return to analysis and containment. On the exam, choose the best next action from the evidence given. If the incident is only suspected, validate and scope it. If malicious activity is confirmed and spreading, containment usually takes priority over routine restoration.

Containment is not eradication

Disconnecting an infected endpoint or disabling a compromised identity limits harm; it does not remove malware, persistence, stolen credentials or the exploited vulnerability. Eradication addresses those causes. Recovery then restores the service from a trusted state and monitors for recurrence.

Root-cause analysis and threat hunting

Root-cause analysis asks why the incident could occur and why controls failed, not only which alert fired. Threat hunting proactively searches for related or hidden adversary activity based on hypotheses and available telemetry. Both can send the team back to broaden scope before declaring recovery complete.

Business continuity and disaster recovery solve different scopes

A business continuity plan (BCP) addresses the organization's ability to continue critical functions through disruption. It includes people, facilities, communications, suppliers, legal obligations, customer processes and alternate working methods. A manual order-taking procedure or alternate call center can be a continuity control even when the primary application remains offline.

A disaster recovery plan (DRP) focuses on restoring information systems, infrastructure and data. It documents recovery order, dependencies, backups, alternate processing capability, network and identity configuration, validation, failback and technical contacts. DR supports business continuity but does not replace the broader business plan.

A business impact analysis (BIA) identifies essential functions, dependencies, impacts and recovery priorities. It provides the business justification for recovery targets. The most technically interesting system is not always the first system to restore; recovery order should follow approved business impact and dependency analysis.

RTO, RPO, MTTR and MTBF answer different questions

MTBF, mean time between failures, describes the average operating time between repairable failures. A design can have a long MTBF but an unacceptable MTTR when it does fail. RTO and RPO are objectives selected from business needs; MTTR and MTBF are measurements derived from operational history.

Targets must be feasible together. A very short RTO with a very small RPO typically requires preconfigured infrastructure, automated failover, frequent replication, tested runbooks and sufficient staff and network capacity. Stating a target does not create the capability to meet it.

Choose the exercise that provides the required assurance

Every exercise needs objectives, scope, participants, safety constraints, success criteria and an after-action process. A tabletop that finds an outdated escalation list is successful if the organization fixes it. A failover exercise that only proves VMs can start is incomplete if DNS, identity, data consistency and application validation were not included.

Training teaches participants how to perform their roles. Testing measures whether the plan, people and technology work under defined conditions. Both belong in preparation, and lessons from each should update plans before the next incident.

Worked scenario: ransomware disrupts the order platform

Situation: EDR reports encryption behavior on an application server. Several user accounts show suspicious sign-ins, and customer orders have stopped. The organization has replicated systems and backups, but the attack scope is unknown.

The team should not immediately fail over a continuously replicated environment if it may contain the same malware or encrypted data. First determine whether the secondary environment and recovery point are trustworthy. Containment prevents additional spread; eradication removes persistence and compromised access; recovery restores validated service.

1. Preserve evidence before destructive action. Collect required volatile data, timestamps, alerts and system evidence according to procedures and legal needs.
2. Scope identities and dependencies. The encrypted server may be an effect, while the initial access and persistence exist elsewhere.
3. Choose a clean recovery point. RPO does not mean “use the newest copy” when the newest copy is compromised.
4. Restore in dependency order. Identity, network, databases, applications and external integrations must be validated as a system.
5. Monitor the recovery. Heightened logging and threat hunting look for recurrence before full reconnection.
6. Run lessons learned. Update segmentation, backups, detection, access controls, playbooks and training based on evidence.

Illustrative learning scenario—not a customer incident or claim about a production environment.

Production-style failure: the recovery site starts but the service does not work

• Check dependency order: identity, DNS, certificates, secrets, databases, messaging and third-party services may be missing or restored in the wrong sequence.
• Check recovery data: confirm integrity, consistency and that the selected point predates corruption or compromise.
• Check network controls: routes, firewall rules, load balancers, remote access and allowlists often differ at the alternate site.
• Check capacity: a recovery platform can start successfully but lack compute, storage, licensing or bandwidth for production demand.
• Check application validation: process running, port open and health probe passing do not prove transactions complete correctly.
• Check security state: rotate exposed credentials, close the exploited path and validate endpoint controls before reconnecting.
• Check runbook evidence: record actual restore duration and data loss, then compare them with RTO and RPO instead of assuming success.

Production-style failure: containment destroyed useful evidence

Preparation should define evidence priorities and authority before responders act. If immediate isolation is required, prefer the least destructive action that stops spread while preserving collection options. Document who performed each action, when, why and on which asset. Maintain chain-of-custody records when evidence may support legal, regulatory or disciplinary processes. Recovery urgency does not remove evidence obligations.

Common Security+ exam mistakes

• Choosing disaster recovery when the immediate need is to contain active malicious behavior.
• Treating business continuity as only an IT backup plan.
• Restoring systems before eradicating malware, persistence or stolen credentials.
• Calling isolation eradication.
• Choosing the newest backup without checking whether it contains the compromise.
• Confusing RTO, a time-to-restore target, with RPO, an acceptable data-loss window.
• Confusing MTTR and MTBF measurements with RTO and RPO objectives.
• Assuming a tabletop exercise proves technical failover works.
• Performing destructive containment before preserving required evidence.
• Skipping lessons learned after service returns.
• Failing to update plans after a test exposes gaps.
• Restoring applications without their identity, DNS, data and network dependencies.

Frequently asked questions

Official references

Confirm the active exam and objectives on the official CompTIA Security+ page. For current incident-response risk-management guidance, use NIST SP 800-61 Rev. 3. For contingency planning, BIA and recovery-plan relationships, use NIST SP 800-34 Rev. 1. ITCertPath provides original learning content and does not reproduce confidential exam questions.