An incident response plan is the document that decides what happens in the first hour after a cyber attack — before anyone has time to think clearly. It names who calls whom, who decides whether to pull servers offline, how evidence is preserved, and how the breach is contained while the business keeps running. Without one, the first hour of a breach is spent improvising; with one, it is spent executing.
TL;DR
- An incident response plan pre-decides roles, steps and decisions for the first hours and days of a cyber incident.
- It has six phases: prepare, detect, contain, eradicate, recover, and learn.
- The first hour matters most: contain first, preserve evidence, and escalate on a pre-agreed call tree.
- Australian businesses carry a legal duty: notifiable data breaches must be reported to the OAIC and affected people.
- A plan nobody has drilled fails under pressure — run a tabletop exercise twice a year.
What an incident response plan means in plain terms
A fire drill works because the decisions were made when nobody was panicking. An incident response plan applies that logic to cyber attacks. It is written calmly, in advance, and it answers the questions that are almost impossible to answer calmly mid-crisis: who is in charge? Who has authority to disconnect systems? Which data is legally reportable and to whom? Who speaks to customers, staff, and the media?
The value shows in the numbers. Dwell time — how long attackers sit inside a network before anyone notices — is still measured in weeks for most organisations. Every hour between compromise and containment is an hour of data leaving the building. A drilled plan compresses that gap.
The six phases of incident response
| Phase | What happens | The question it answers |
|---|---|---|
| 1. Prepare | Write the plan, build the contact tree, agree thresholds, run drills | Are we ready before anything happens? |
| 2. Detect | Triage alerts, confirm it is a real incident, classify its severity | Is this real, and how bad? |
| 3. Contain | Isolate affected systems, block attacker access, stop the bleeding | How do we stop it getting worse right now? |
| 4. Eradicate | Remove the attacker, close the entry point, patch the exploited flaw | How do we get them out for good? |
| 5. Recover | Restore from backups, verify integrity, monitor for re-infection | How do we get back to business? |
| 6. Learn | Post-incident review, update the plan, close the gaps it exposed | What do we change so it cannot recur? |
A plan that stops at containment is a half-plan. Phases 4 through 6 are where most organisations lose discipline — but the learn phase is the one that decides whether the same breach happens again next quarter.
The first hour: what the plan actually does
The opening 60 minutes decide the size of the incident. The plan exists to make these moves automatic:
- Confirm and classify. The on-call person follows the plan's triage criteria: is this real, what systems are involved, what severity?
- Contain before you investigate. Isolate affected machines from the network (unplug, disable Wi-Fi, do not power off — memory holds evidence), revoke exposed credentials, block the attacker's access path.
- Preserve evidence. Logs, memory and images of affected systems feed both the investigation and, potentially, insurance or legal processes.
- Escalate on the call tree. The plan names the decision-maker who authorises disconnecting systems, and the first phone calls happen in minutes, not hours.
- Start the legal clock. Check whether personal information is involved. In Australia, the Notifiable Data Breaches scheme sets out when a breach must be reported to the OAIC and affected individuals.
Containment always precedes investigation. A team that spends hour one doing forensic analysis while the attacker is still active has produced documentation of a larger breach.
What goes in the plan document
A usable plan fits the people who will use it. The minimum contents:
- Roles and the call tree. Named people with phone numbers, and named deputies for when the first choice is unreachable.
- Severity classification. What counts as minor, major and critical, with the response that each level triggers.
- Containment checklists. Step-by-step isolation steps per system type, written for a stressed reader.
- Backup and recovery positions. Where backups live, how restore is tested, and the Recovery Time Objective for each critical system.
- Communication templates. Pre-drafted notifications for staff, customers, the OAIC and (if insured) the insurer — written once, calmly.
- External contact list. IT provider or MSP, cyber insurance hotline, and ReportCyber for reporting cybercrime.
- Legal obligations. When and how to notify the OAIC, and who makes that call.
Common failure modes
- The plan is written and shelved. Nobody has read it since it was signed. An untested plan fails at exactly the moment it is needed.
- No authority to act. Nobody is pre-authorised to disconnect systems, so containment waits for a meeting. Meanwhile, the attack runs.
- Backups that were never restore-tested. Recovery stalls on backups that do not actually restore.
- The plan lives on the compromised network. Print it, or store it offline. A ransomware event that encrypts the file server also encrypts the plan.
- No learn phase. The same entry point is used again because nobody closed it.
How to make it stick
- Run a tabletop exercise twice a year. Two hours, the real people in their real roles, a plausible scenario. Every gap the exercise exposes is a gap an attacker would have found.
- Brief every employee on their one job in an incident: report fast. Dwell time shrinks with every minute saved in detection, and most detections start with a person. Cyber Aware's security awareness training builds that reflex, and the reporting culture it creates is the cheapest detection system a business can buy. Human risk reporting shows whether the reflex is real.
- Tie the plan to the frameworks you are already working toward. Essential Eight and ISO 27001 both expect documented, tested incident response. If a gap assessment is already on your calendar, fold the plan review into it.
- Review the plan after every real incident and every drill. A plan's version history should show it changing; a plan that never changes is a plan nobody used.
FAQ
What is an incident response plan? A pre-agreed document that sets out who does what when a cyber incident happens: how incidents are detected and classified, who contains them and how, when regulators and customers are notified, and how the organisation learns from each event.
What are the six phases of incident response? Prepare, detect, contain, eradicate, recover and learn. The first three decide the size of the incident; the last three decide whether it can happen again the same way.
What should happen in the first hour of a cyber attack? Confirm the incident, contain it (isolate systems, revoke credentials, block access — without destroying evidence), preserve logs, escalate on the call tree, and check whether personal information is involved so notification duties are assessed early.
Does Australia require an incident response plan? Several frameworks expect one — Essential Eight, ISO 27001 and the Notifiable Data Breaches regime all reward documented, tested response. Some industries and insurance policies require one explicitly. Practically: a business holding personal information should treat the plan as required.
How often should an incident response plan be tested? At least twice a year with a tabletop exercise, plus a review after every real incident. A plan that has never been exercised will fail on first use.
One last thing
Two checks today: is your incident response plan printed or stored somewhere an attacker cannot encrypt, and do the three people most likely to lead a response each know they are on the call tree? If the answer to either is no, that is tonight's fix — and it costs nothing but a conversation.