Simple explanation
The phases that bookend every incident: getting ready before anything happens, and learning/improving after it's over. Both are easy to shortchange under time pressure — and both are where an organization's response actually gets better over time.
Technical explanation
Preparation (before any incident):
- Training — ensuring responders actually know the plan, not just that a document exists.
- Testing incident response plans — via tabletop exercises (discussion-based) and more realistic simulations.
- Communication plans — pre-defined, so no one is figuring out who to notify and how mid-crisis.
- Disaster recovery plan (DRP) and business continuity plan (BCP) — related but distinct: DRP focuses on restoring IT systems; BCP focuses on keeping the broader business functioning during disruption.
Post-incident activity (after containment/eradication/recovery):
- Root cause analysis — going beyond "what happened" to genuinely understand "why did our defenses not catch or prevent this."
- Lessons learned — a formal review, ideally involving everyone who touched the incident, capturing what worked and what didn't.
- Change control process — any fix or improvement identified still has to go through proper change management before being implemented, even under the pressure of "we need to fix this now."
- Updating incident response plans — the playbook itself should be revised based on what was actually learned, not left static.
- MITRE ATT&CK / IOC generation — documenting the specific techniques observed (mapped to ATT&CK) and generating indicators of compromise from this incident, feeding both into future detection capability.
Synonyms / related terms
| Term | Means | |---|---| | DRP | Disaster Recovery Plan | | BCP | Business Continuity Plan | | Post-mortem | Common informal term for the lessons-learned review |
Concept Check
"After a phishing-based incident is fully resolved, the team closes the ticket and moves to the next alert without further review." This skips post-incident activity entirely — without root cause analysis and lessons learned, the specific gap that allowed the phishing email through (a filter misconfiguration, a training gap) remains unaddressed, and the same class of incident is likely to recur.
Interview-style Q&A
Q: Why distinguish between a DRP and a BCP instead of treating them as the same document? A: "They solve different problems. A DRP is narrowly about getting IT systems back online — servers, applications, data. A BCP is broader: how does the BUSINESS keep functioning, including processes that might not even be IT-dependent, like manually processing orders if the system is down. An organization can have a perfect DRP and still fail if it never planned for the human/process side that BCP covers."
Memory trick
"Prepare before, Learn after" — the two IR bookends this lesson covers, and the reminder that both deserve as much rigor as the active response phases in between.