D7 — Incident Response Lifecycle & DR/BCP

You've been paged for an incident, made a containment call under pressure, and coordinated recovery. This lesson gives that experience its formal CISSP structure — and the vocabulary the exam uses to test whether you understand why the phases happen in that specific order, not just that you can execute them.

The NIST incident-response lifecycle

Four phases, always in this order:

1. Preparation — before any incident: playbooks, tooling, trained responders, defined escalation paths. This phase never "finishes"; it's continuously maintained.
2. Detection & Analysis — identifying that an incident is occurring and understanding its scope, severity, and nature.
3. Containment, Eradication & Recovery — a single combined phase with three sequential steps: containment (stop the spread — isolate affected systems), eradication (remove the root cause — the malware, the backdoor, the misconfiguration), then recovery (restore affected systems to normal operation, verified clean).
4. Post-Incident Activity (Lessons Learned) — after resolution: what happened, what worked, what didn't, and what changes feed back into Preparation for next time.

The one sequencing rule tested most often: containment always precedes eradication. You cannot safely remove a root cause from a system that's still actively being exploited or still spreading — you stop the bleeding first, then treat the wound. A question describing "recovery" happening before the threat is contained is describing recovering into a system that will simply be re-compromised.

Containment, eradication, recovery — precisely distinguished

• Containment — isolate, don't yet fix. Segmenting an infected host off the network, disabling a compromised account, blocking a malicious IP at the edge.
• Eradication — remove what caused it. Deleting malware, closing the vulnerability that was exploited, rotating compromised credentials.
• Recovery — bring systems back into normal, trusted operation, with verification (not just "it's back online," but confirmation the root cause is actually gone).

DR/BCP: RTO, RPO, MTD, and matching the site strategy

Three metrics drive every disaster-recovery decision:

• RTO (Recovery Time Objective) — the maximum tolerable downtime before the business impact becomes unacceptable. "How long can we be down?"
• RPO (Recovery Point Objective) — the maximum tolerable data loss, measured in time. "How much data can we afford to lose, going backward from the failure?"
• MTD (Maximum Tolerable Downtime) — the absolute outer limit before the organization suffers unrecoverable harm; RTO should always be set comfortably below MTD, not equal to it.

These metrics determine which DR site strategy is actually justified — spending more than the RTO/RPO targets require wastes money (the same cost-benefit logic as Lesson 2's ALE reasoning); spending less fails the business:

Worked example: a media-streaming platform must survive total loss of its primary datacenter with near-zero data loss and near-immediate failover. Only a hot site with synchronous replication meets RTO≈0 and RPO≈0 — a cold site's days-to-weeks RTO and a warm site's up-to-24-hour RPO both fail the requirement outright, regardless of cost, because the targets themselves rule them out before cost is even considered.

The CISSP mindset: manager vs technician

During an active incident, the technical team successfully contains and eradicates the threat within two hours.

The technician answer: the incident is resolved — systems are clean, containment worked, move on to the next ticket.

The manager (CISSP) answer: two hours of technical resolution is necessary but not the full incident-response cycle. Was the scope fully understood during Detection & Analysis, or could this be one symptom of a broader compromise? Are affected stakeholders (customers, leadership, possibly regulators depending on data involved) informed appropriately and on time? And critically — does Post-Incident Activity happen at all, capturing what allowed this incident and feeding a concrete change back into Preparation, or does the organization simply move on until the same root cause produces the next incident? A fast technical resolution that skips the lifecycle's bookends (accurate scoping, and the lessons-learned feedback loop) resolves the symptom while leaving the process gap that will keep producing similar incidents — the same manager-vs-technician distinction from Lesson 1's SQL injection scenario, applied here to incident response specifically.