BC, DR & Incident Response
Three plans answer three different questions about one disruption
When something knocks an organization down, three separate plans go to work, and the whole exam value of this domain is telling them apart. Business continuity (BC) keeps the critical work going during the disruption, often through manual workarounds or a backup location, so payroll still runs and orders still ship. Disaster recovery (DR) is the technical job of restoring the IT systems and data after the hit, so the business has working technology again. Incident response (IR) is the organized handling of the security event itself, detecting it, containing it, and learning from it. The trap the exam loves is blurring BC and DR: BC keeps the business running, DR restores the technology, and DR is the IT subset that supports the BC plan rather than standing on its own.
The domain unfolds in three steps along the disruption's timeline
Read the subtopics in order and they trace a single event from start to finish. Business Continuity comes first because it owns the planning that decides what to protect: the business impact analysis (BIA) finds the critical processes and sets each one's maximum tolerable downtime (MTD), the longest it can be down before the harm is unacceptable. Disaster Recovery then turns those targets into technology choices, driven by the recovery time objective (RTO, how long you can be down) and recovery point objective (RPO, how much data you can lose), backed by tested offsite backups and a recovery site sized to the RTO. Incident Response handles the security event on its own clock: the four-phase NIST lifecycle of Preparation, Detection and Analysis, Containment/Eradication/Recovery, and Post-Incident Activity, run by a standing team that exists before anything goes wrong.
Whatever the plan, prepare and test before the crisis, never during it
The instinct the exam rewards across all three plans is that the work happens beforehand. The BIA is done first so the continuity plan is built on real recovery targets; backups are proven by actual test restores rather than assumed to work; the incident response team and plan are staffed and written before the first alert. A plan that is filed away untested is treated as no plan at all, because the moment of disruption is the worst time to discover that the backup never restored, no one knows their role, or normal email and phones are down with no other way to reach people. When two answers both seem to work, prefer the one that reflects readiness established in advance over improvisation in the moment.
Three responses to one disruption: during, after, and the event itself
| Response | Answers the question | Where on the timeline | Key targets / terms | Drill into |
|---|---|---|---|---|
| Business continuity | How do we keep critical work going? | During the disruption | BIA, maximum tolerable downtime (MTD), critical processes | Business Continuity |
| Disaster recovery | How do we get the IT systems back? | After the disruption | RTO, RPO, tested offsite backups, cold/warm/hot site | Disaster Recovery |
| Incident response | How do we handle the security event? | When the event occurs | Event/alert/incident/breach, four NIST phases, CSIRT | Incident Response |