Incident Response and Disaster Recovery: A Practical Australian Playbook

Incident response and disaster recovery are related, but they are not interchangeable. An organisation can contain an attacker and still be unable to operate. It can also restore a server quickly while restoring the same compromise, losing evidence or making an unapproved public statement.

A useful plan connects four disciplines:

• cyber incident response — detecting, analysing, containing, remediating and learning from a security incident;
• business continuity — maintaining the organisation's critical activities during disruption;
• disaster recovery — restoring technology and data to an acceptable state; and
• crisis communication and decision-making — coordinating leaders, workers, suppliers, customers, regulators and other stakeholders.

The previous version of this article asserted that breaches are inevitable, quoted an unverified average Australian breach cost and prescribed quarterly testing for every organisation. Those claims are removed. Risk, impact and exercise frequency depend on the organisation and its obligations; readiness should be demonstrated by evidence, not fear-based statistics.

Prepare before the alert arrives

ASD's current practitioner guidance says a cyber incident response plan should align with emergency, crisis, business continuity and disaster-recovery arrangements, be tailored to the environment, and be regularly tested and reviewed (ASD — Cyber security incident response planning).

Begin with decision rights and reliable contact paths. Record:

• the incident lead and deputy;
• technical, business, legal/privacy and communications decision-makers;
• critical service owners and recovery priorities;
• cyber insurer or broker contacts and relevant policy conditions;
• hosting, cloud, identity, banking and managed-service escalation paths;
• law-enforcement and government reporting routes where relevant;
• who can isolate systems, disable accounts, restore data and approve public statements; and
• an offline, protected copy of the plan and key contacts.

Create short playbooks for likely scenarios such as phishing/business email compromise, compromised administrator access, ransomware, lost devices, website compromise, cloud-key exposure and data breach. A playbook should support judgement; it should not force responders to follow a damaging action merely because it appears as step three.

Detect and triage with business context

Define how workers and suppliers report a concern at any time. Record the first observation, source, time, affected accounts or services and actions already taken. Establish an incident log early and preserve the original alert, relevant timestamps and decision rationale.

Triage should ask:

1. What is known and what is only suspected?
2. Which identities, data, systems and business processes may be affected?
3. Is the activity ongoing?
4. Could a containment action disrupt a critical service or destroy evidence?
5. Who has authority to make the next decision?
6. Is specialist incident-response, legal, privacy, insurer or law-enforcement help required now?

NIST SP 800-61 Rev.3, finalised in April 2025, integrates incident response across the Govern, Identify, Protect, Detect, Respond and Recover functions of the Cybersecurity Framework 2.0 rather than treating response as an isolated technical phase (NIST SP 800-61 Rev.3).

Contain without making the situation worse

“Isolate everything immediately” is not a universal rule. Isolation may be appropriate, but responders should consider operational impact, evidence preservation, attacker visibility and the time required for a safer alternative. ASD's guidance explicitly asks organisations to consider the additional effects, duration and effectiveness of containment options.

Possible authorised actions include disabling a compromised session, account, API key or forwarding rule; restricting network access; blocking a malicious indicator; preserving a system image or relevant logs; and moving a critical service to a known-clean path. The exact action depends on the incident and must stay within legal authority and the agreed response role.

Do not delete logs, wipe a system or “hack back”. Protect collected evidence from unnecessary access and record who collected it, when, from where and how its integrity was maintained. Engage a qualified forensic specialist where evidence may support litigation, insurance, employment or regulatory decisions.

Define recovery through business impact

Recovery objectives should be based on the business processes a system supports. NIST's contingency-planning guide distinguishes:

• maximum tolerable downtime (MTD): the total outage or disruption the process can tolerate;
• recovery time objective (RTO): the maximum time a system resource can remain unavailable before unacceptable impact; and
• recovery point objective (RPO): the point in time to which data must be recoverable, which expresses tolerable data loss (NIST SP 800-34 Rev.1).

Do not copy a supplier's advertised recovery figure into the plan without validating dependencies. A website may depend on DNS, identity, secrets, database, storage, mail, payment, third-party APIs and staff access. Recovery should specify the order, prerequisites, owners and acceptance tests.

A safe recovery sequence normally includes:

1. approve a remediation and recovery plan;
2. establish a known-clean identity and administration path;
3. remediate the entry point and affected trust relationships;
4. restore systems and data from an appropriate source;
5. rotate exposed credentials and keys according to impact;
6. validate integrity, security configuration and business function;
7. monitor for recurrence or missed persistence; and
8. obtain accountable approval before returning to normal operation.

A backup is not recovery evidence. Run restoration exercises, record duration and missing dependencies, and protect recovery administration from the identities used for everyday work.

Handle notification as a scoped decision

Not every security event is a notifiable data breach, and not every Australian organisation has the same obligations. The OAIC's current quick-reference guide applies to entities covered by the Notifiable Data Breaches scheme and uses a contain–assess–notify if required–review sequence (OAIC — Responding to data breaches).

Assess coverage, the information involved, likely serious harm, remedial action and statutory timeframes with appropriate advice. Preserve the basis for the decision. Sector-specific obligations can also apply. For example, APRA's CPS 230 and CPS 234 apply to APRA-regulated entities, not to every Australian business (APRA — CPS 230). Contractual, insurer, customer and platform notification requirements may be separate again.

Report active cybercrime or incidents through the appropriate official channel when relevant. Do not delay urgent containment solely to perfect a report, but do not make unsupported public attribution or promise an outcome before facts are established.

Exercise the decisions, not just the document

Choose exercise frequency from risk, change, obligations and prior findings rather than a universal quarterly rule. Useful exercise types include:

• a contact-tree and escalation test;
• a tabletop decision exercise;
• a technical restore test;
• a failover or alternate-workflow exercise; and
• a combined incident, recovery and communications simulation.

Define observable acceptance criteria: contacts reached within the expected window, correct authority identified, evidence preserved, backup restored, critical transaction completed, notification question escalated and unresolved actions assigned.

After an incident or exercise, run a blameless review that still assigns ownership. Update the plan, architecture, controls, supplier agreements and funded work backlog. An incident is not “closed” merely because production is available again.

For a scoped review of response roles, backups, restoration evidence and website/cloud dependencies, see Ozlin Info's cybersecurity services or contact Ozlin Info.

Related reading: Phishing response playbook for Australian businesses.

---

General-information disclaimer

This article provides general information only. It is not incident-response, forensic, legal, privacy, regulatory, insurance or business-continuity advice. Actions and notification obligations depend on the facts, authority, systems, information, contracts, sector and jurisdiction. Seek urgent qualified help when an incident may be active.

AI-assistance disclosure

AI tools assisted with source discovery, outlining and copyediting. A human reviewer must verify every factual statement, link, scope decision and publication choice before release. No recovery time or incident outcome is promised.

Primary sources checked

• ASD — Cyber security incident response planning: practitioner guidance
• NIST SP 800-61 Rev.3 — Incident Response Recommendations and Considerations
• NIST SP 800-34 Rev.1 — Contingency Planning Guide
• OAIC — Quick reference guide for responding to data breaches
• APRA — CPS 230 Operational Risk Management

Source access date: 29 August 2026.