What an incident response plan actually needs
In my cyber security governance unit, I did a risk assessment and incident response plan for a real organisation, then defended it in an oral assessment. Here are the ideas that stuck.
Know your recovery targets first. A business impact analysis tells you what matters most and how fast it has to come back:
- RTO (Recovery Time Objective): how long a system can be down.
- RPO (Recovery Point Objective): how much data you can afford to lose, measured in time.
- MTD (Maximum Tolerable Downtime): the point where the outage does real damage.
Without these, you might restore the wrong system first.
Follow a lifecycle. NIST SP 800-61 breaks incident response into four stages:
- Preparation: roles, tools, contact lists and practice runs.
- Detection and analysis: spotting it, judging how bad it is, writing things down.
- Containment, eradication and recovery: stop the spread, remove the cause, restore from clean backups.
- Post-incident activity: a lessons-learned review, then update the plan.
Plans go stale. A plan last tested two years ago, before new cloud tools were added, isn’t really a plan. It needs regular review and testing.
“We have backups” isn’t a risk treatment on its own. Backups reduce impact, but only if they’re tested, isolated from the network and recoverable within your RTO. Otherwise the risk rating shouldn’t come down.
Know your legal obligations. In Australia, organisations covered by the Notifiable Data Breaches scheme have to notify the OAIC and affected people when a breach is likely to cause serious harm.
The biggest shift for me: incident response is mostly about decisions made before anything goes wrong.