What Belongs in an Incident Response Plan

Four roles cover most incidents. An incident commander owns the decisions and briefs upward. A technical lead runs containment and investigation. A communications owner controls every word that leaves the response team, whether it goes to staff, customers or a regulator. A scribe keeps the record. In a fifty-person company these are hats worn by the same few heads, and that is fine. What matters is that the plan says whose head, by name, with a deputy for each role, because incidents arrive with great reliability while the primary is on leave or unreachable.

Under the names sits the contact tree, and it needs after-hours numbers rather than office extensions. Internally that means the incident commander and deputies. Externally it means the cyber insurer's incident hotline with the policy number printed beside it, legal counsel, the managed IT provider or key platform vendors, and the ACSC's ReportCyber service. Print the tree and keep a copy in a drawer as well as a drive. A contact list that exists only inside the compromised environment is a document the attacker can read and you possibly cannot.

The costliest delays in real incidents are permission delays. Engineers who are ready to disconnect a spreading infection wait while somebody senior is woken, briefed from a standing start, and asked to make an irreversible call. The plan removes that wait by settling the big decisions in advance. Who can take a revenue system offline, and against what threshold of evidence? Who can commit money to external responders overnight, without a purchase order? Who approves the first external statement? Each answer is a name, and each threshold is written while nobody is under pressure.

Write the delegation chain as well. If the named authority cannot be reached within a defined window, authority passes to the deputy, and the plan says so plainly. The alternative is a responder at 2am choosing between exceeding their authority and watching ransomware spread while the phone rings out. Pre-agreed thresholds and a clear chain turn the worst judgement calls into procedure, which is what people can still execute when they are frightened and tired.

Communication drafted mid-incident is reliably poor, so the plan carries templates written in daylight. A holding statement for staff, one for customers, and one for a regulator or media enquiry, each with blanks for the facts. Early statements should say what is known, what is being done and when the next update will come. Speculation about cause or scale in the first hours can be quoted back at the organisation by a regulator or a plaintiff months later. Name a single spokesperson and route every enquiry to them.

The plan also names where the response team talks. Assume the attacker reads the corporate mailbox and chat until proven otherwise; coordinating containment inside a compromised tenant hands the intruder your plan in real time. Decide the out-of-band channel in advance, whether that is phones, a messaging group on personal devices, or a separate clean tenant kept for the purpose, and put the joining details in the printed pack.

Everything the response team does may later be examined by an insurer, a regulator or a court, and the plan should be written with that reader in mind. It starts with the incident log: a contemporaneous record kept outside the affected environment, in UTC, noting who did what, when, and what they observed. It continues with handling rules the technical lead can follow without a forensics background. Isolate machines from the network but keep them running, preserve memory and disk images before any rebuild, and record who handled which asset so the chain of custody survives.

The plan lists the log sources that matter, their retention windows, and an export destination the attacker cannot reach, because sign-in logs and firewall records age out on schedules that ignore your incident. It also records a decision made in advance with counsel: how forensic investigators will be engaged. The structure of that engagement affects any later claim of privilege over the findings, and Australian courts have declined privilege over breach reports commissioned for mixed business purposes.

The cyber insurer belongs earlier in the sequence than most teams expect. Many policies require the insurer to be notified before external responders are engaged, and many insurers operate panels of approved forensic and legal firms. Engaging your own responder first can complicate or jeopardise cover. The plan therefore carries the policy number, the hotline, the broker's details and a one-line reminder of any notification conditions.

The regulatory clocks belong in the plan as trigger points with named owners, with the detail of the law left to counsel. Under the Notifiable Data Breaches scheme in the Privacy Act 1988, an organisation that suspects an eligible data breach has up to thirty days to assess it, and once it forms the view that serious harm is likely, notification to the OAIC and affected individuals must follow as soon as practicable. The Cyber Security Act 2024 requires businesses above the small business turnover threshold to report a ransomware payment within seventy-two hours. Organisations covered by the SOCI Act carry their own incident reporting obligations on tighter timelines. For each trigger, the plan names who starts the clock and who makes the call, usually with counsel on the phone.

The full plan can run to a dozen pages of supporting detail. The front page is the part that gets used, and it is worth distilling until it holds:

A plan starts going out of date the day it is signed. Contact numbers go stale, staff move on and the architecture changes underneath it. The corrective is the tabletop exercise: one to two hours, twice a year, walking a plausible scenario against the actual document with the actual named people in the room. Rotate the scenario each time: ransomware on a file server, a business email compromise in the finance team, a breach at a software vendor, or a lost laptop holding client records. The point of the exercise is to make the plan fail in the meeting room, where failure costs nothing. Every stale number, unowned decision and unfindable template becomes a fix with an owner and a date, and the plan is reissued.

Real incidents and near misses feed the same loop, and so do penetration test reports. Writing, pressure-testing and rehearsing plans of exactly this shape is standing work inside Black Shard's vCISO engagements, because the tabletop is the mechanism that turns a written plan into an executable one. The measure of success does not change: a junior on-call person, alone at 2am, can run the first page without waking anyone to ask for a permission the plan should already have granted. This note is general information; take legal advice on your organisation's specific obligations.