Cyber Incident Response Plan

Document control

1. Purpose

This Plan sets out how [Organisation] prepares for, detects, analyses, contains, eradicates, recovers from and learns from cyber security incidents. It ensures that:

2. Scope

This Plan applies to:

3. Relationship to other documents

4. Key definitions

5. Principles

1. Report early. Anyone who suspects a cyber incident reports it straight away to the [Security Operations Centre / IT Service Desk] on [phone number]. A false alarm costs little; a late report can cost a great deal.
2. Safety and customers first. Protect people, customers and critical operations before systems and convenience.
3. Contain fast, but think first. Act quickly to stop harm, but do not destroy evidence or alert the attacker without need. Isolate rather than wipe or switch off.
4. Assume the attacker can see you. Use out-of-band communications for the response if email, chat or the network may be compromised.
5. Write it down. Record every action and every decision with the time, the person and the reason (Appendices J and K).
6. Meet the clock. Regulatory deadlines run from when [Organisation] becomes aware, not from when the investigation finishes. Some are as short as 12 hours.
7. One rating language. Cyber severity always maps to the common rating (Critical, High, Medium, Low) so that everyone, up to the Board, understands it.
8. Recover clean. Restore from known-good sources and verify before returning systems to service.
9. Learn and fix the cause. Every Critical and High incident has a post-incident review and its root cause is fixed.

6. Standards and response phases

This Plan follows recognised standards, so that internal teams, service providers, external responders and regulators share the same terms:

7. Incident response team and governance

The response is organised in three tiers. For Medium and Low incidents only the CIRT is usually needed. High incidents bring in the Incident Executive. Critical incidents also activate the Crisis Management Team under the RiskFA Crisis Management Plan.

7.1 Roles

7.2 Decision rights

The following people may make these decisions without waiting for further approval. Each decision is recorded in the decision log (Appendix K) with the reason.

8. Severity classification

The Incident Executive declares a cyber severity as soon as an incident is confirmed, using the realistic worst case. Cyber severity is the same as the common rating in the RiskFA Incident & Issues Management Standard, so a Critical cyber incident is a Critical incident for all purposes. If unsure, choose the higher severity. Re-assess at every status update and record the reason for any change.

9. Activation and escalation

1. Anyone who suspects a cyber incident reports it to [Security Operations Centre / IT Service Desk] on [phone] or [email / portal]. Out of hours, call the on-call Incident Manager on [phone].
2. The security operations team triages the report within [30 minutes] (Critical or High indicators) or [4 hours] (others).
3. If an incident is confirmed or likely, the Incident Manager opens an incident record, starts the incident log and calls the Incident Executive.
4. The Incident Executive declares the severity and activates the response tier (section 7).
5. The Risk Lead records the incident in the incident register the same day for Critical and High incidents, as the RiskFA Incident & Issues Management Standard requires.
6. The Compliance and Regulatory Lead and, where personal information may be involved, the Privacy Lead are brought in for every Critical and High incident, and for any incident that may trigger a notification.
7. Status calls are held every [2 hours] (Critical) or [twice daily] (High) until the incident is contained.

10. Out-of-band communications

Attackers who control a network often read email and chat. For Critical and High incidents, and whenever identity systems or email may be compromised:

11. Phase 1: Prepare

Preparation is what makes the response work. [Organisation] maintains:

12. Phase 2: Detect and analyse

The aim is to confirm whether an incident is occurring, understand its scope and severity, and make early decisions on containment and notification.

13. Phase 3: Contain

Containment stops the incident from spreading and buys time. The Technical Lead proposes a containment strategy and the Incident Executive approves it, taking account of:

14. Phases 4 and 5: Eradicate and recover

14.1 Eradicate

• Remove malware, persistence mechanisms, attacker accounts and unauthorised changes.
• Close the access route (for example the vulnerability, stolen credential or service provider connection).
• Confirm eradication across the whole environment, not only the systems first found. Assume the attacker had more access than first seen until proven otherwise.
• Do not start eradication until the scope is understood. Premature eradication often leaves the attacker inside.

14.2 Recover

• Restore in priority order: identity and security systems first, then critical operations in order of their tolerance levels, then other services.
• Restore from backups or images that have been checked as clean and taken before the earliest sign of compromise.
• Test restored systems and confirm they are clean before reconnecting them; apply heightened monitoring for at least [30 days].
• The business owner and the Technical Lead jointly approve the return to service.
• Track recovery against CPS 230 tolerance levels for each affected critical operation and keep the Board and APRA informed as required (section 19).

15. Phase 6: Post-incident review

• A post-incident review is held for every Critical and High cyber incident within [20 business days] of resolution, and for others at the CISO's discretion.
• The review is blameless in tone but honest about failures. It covers the timeline, root cause, extent of condition, how well this Plan and the playbooks worked, what was missed, and what will change (Appendix M).
• Every control gap found is raised as an issue with an owner and due date under the RiskFA Incident & Issues Management Standard.
• Material control weaknesses that cannot be remediated in a timely manner are notified to APRA within 10 business days (CPS 234 para 36) and escalated to the Board or senior management.
• The review is reported to the executive and the Board Risk Committee, and lessons are used to update this Plan, playbooks, training and the risk and control assessment.

16. Evidence preservation and chain of custody

Evidence supports the investigation, insurance claims, regulator inquiries and any legal action. From the moment an incident is suspected:

17. Legal professional privilege

Legal professional privilege may protect some communications and documents created for the dominant purpose of giving legal advice or for actual or anticipated litigation. It can help protect sensitive investigation findings, but it is never certain and must not delay the response or a required notification.

18. Communications

All external communications are accurate, timely, consistent and approved. Never speculate about the cause, the attacker or the data affected until facts are confirmed, and never give technical details that could help an attacker.

19. Regulatory and external notifications

The Compliance and Regulatory Lead assesses every possible notification and records each decision, including decisions not to notify, with reasons. Clocks run from awareness, so the time [Organisation] became aware is recorded at triage. Lodge an initial notification on time with the facts known, and update it as facts develop. The table summarises common obligations as at October 2026; delete those that do not apply and confirm current requirements.

20. Engaging ASD, the National Cyber Security Coordinator and law enforcement

• Report cyber security incidents to ASD's Australian Cyber Security Centre as soon as they are identified, through ReportCyber at cyber.gov.au (Submit a report), or call the 24/7 Australian Cyber Security Hotline on 1300 CYBER1 (1300 292 371). ASD can provide technical advice and assistance.
• Report cybercrime to police through ReportCyber, and in an emergency or where there is a threat to life call 000.
• ASD limited use obligation (Intelligence Services Act 2001 Part 6 Division 1A): information voluntarily provided to ASD, or acquired or prepared by ASD with the entity's consent, about a cyber security incident cannot be used for regulatory purposes, and current and former ASD staff cannot be compelled to give it in court. The protection extends to information provided by lawyers and incident response providers acting for the entity. It does not apply to information the entity later makes public.
• National Cyber Security Coordinator (Cyber Security Act 2024 Part 4): an entity may voluntarily give information about a significant cyber security incident (s34: a material risk of serious prejudice to Australia's social or economic stability, defence or national security, or of serious concern to the Australian people) or about other incidents (ss 36, 39). The Coordinator and other bodies may use it only for permitted purposes, such as helping the entity respond, and not to investigate or enforce the entity's contravention of other laws, except criminal offences (ss 38 to 40). It is generally not admissible against the entity (s42).
• Ransomware payment reports (Cyber Security Act 2024 Part 3) are similarly limited: they may be used only for permitted purposes (s29), not to investigate or enforce the entity's contravention of other laws, except Part 3 itself or criminal offences (ss 29, 30), and are generally not admissible against the entity (s32).
• Limited use does not acquit mandatory reporting. Notifications to APRA, the OAIC, ASIC, AUSTRAC and others must still be made, and regulators and law enforcement keep their own information-gathering powers. With consent, ASD can share mandatory SOCI reports with other agencies through cyber.gov.au.

21. Material service providers and third parties

• Contracts with material service providers, and other providers that hold [Organisation]'s data or connect to its systems, must require notification of security incidents affecting [Organisation] within [24 hours] (or sooner where [Organisation]'s own deadlines require), and cooperation with the investigation, including access to logs and evidence.
• An incident at a service provider is recorded and rated in [Organisation]'s register as [Organisation]'s own incident. [Organisation] remains responsible for its own notifications, even where the provider also notifies.
• Where [Organisation] relies on a provider's incident response, the provider's plan and test results are reviewed at least [annually].
• Appendix F sets out the response to a compromised service provider.

22. Testing and exercising this Plan

CPS 234 para 26 requires APRA-regulated entities to review and test their information security response plans at least annually to ensure they remain effective and fit for purpose. [Organisation] tests this Plan as follows:

23. Key risk indicators and reporting

The CISO reports to the executive [monthly] and to the Board Risk Committee [quarterly] on cyber incidents and on the readiness of this Plan.

24. Training, roles and review

• CIRT members and deputies complete incident response training at appointment and at least [annually].
• Executives and Board members are briefed on this Plan and their decision rights at least [annually].
• All staff are trained to recognise and report suspected cyber incidents at induction and [annually].
• This Plan is reviewed at least [annually] and after any Critical or High incident or significant exercise finding. Internal Audit reviews incident response as part of its information security control assurance (CPS 234 para 32).

25. Related documents

• The RiskFA Incident & Issues Management Standard
• The RiskFA Data Breach Response Plan; the RiskFA Cyber Security Policy, the RiskFA Business Continuity Policy, the RiskFA Crisis Management Plan
• [Third Party / Material Service Provider Management Policy], [Continuous Disclosure Policy], [Fraud Policy], the RiskFA Whistleblower Policy
• APRA: CPS 234 Information Security and CPG 234; CPS 230 Operational Risk Management and CPG 230
• Cyber Security Act 2024 Parts 3 and 4; Cyber Security (Ransomware Payment Reporting) Rules 2025; Security of Critical Infrastructure Act 2018 Part 2B; Privacy Act 1988 Part IIIC; Intelligence Services Act 2001 Part 6 Division 1A
• ASD: Ransomware Playbook, Essential Eight, Information Security Manual, ReportCyber; OAIC: Data breach preparation and response
• Standards: NIST SP 800-61 Rev. 3; NIST Cybersecurity Framework 2.0; ISO/IEC 27035-1:2023, 27035-2:2023, 27035-3 and 27035-4:2024; ISO/IEC 27001 and 27002; ISO/IEC 27037 Guidelines for identification, collection, acquisition and preservation of digital evidence

Appendix A. Playbook: ransomware and cyber extortion

Triggers: files encrypted, ransom note, extortion message threatening to publish stolen data, or attacker contact by email, phone or leak site. Default severity: Critical.

A.1 Immediate actions

1. Network-isolate affected devices; do not power them off or delete anything. Photograph ransom notes.
2. Protect backups: disconnect or lock backup systems and confirm whether they are affected.
3. Disable compromised accounts; plan a reset of privileged credentials (coordinate timing so the attacker is not tipped off before containment is ready).
4. Activate the Crisis Management Team, the external IR provider (through Legal) and the insurer.
5. Move to out-of-band communications.
6. Assume data has been stolen until proven otherwise: start the RiskFA Data Breach Response Plan.
7. Report to ASD (ReportCyber or 1300 CYBER1) and to police.
8. Start the notification checklist (Appendix L): CPS 234 72 hours, CPS 230 24 or 72 hours, SOCI 12 or 72 hours, NDB assessment.

A.2 Extortion and payment decisions

• Government position: the Australian Government strongly discourages paying a ransom (ASD's ACSC Ransomware Playbook, cyber.gov.au). Paying does not guarantee that access will be restored or that stolen data will not be sold or published, and it may lead to further attacks.
• [Organisation]'s position is that it [will not pay a ransom / will not pay except as a last resort to protect life or prevent severe customer harm], and only with Board approval (section 7.2).
• No one may communicate with the attacker except a person authorised by the Crisis Management Team, with legal and specialist advice.
• Before any payment decision, Legal must advise on sanctions, anti-money laundering, terrorism financing and other laws, insurance terms, and whether paying would be consistent with directors' duties and the risk appetite.
• Record the decision, reasons and advice in the decision log.

A.3 If a payment is made

• Lodge a ransomware payment report (form on cyber.gov.au) within 72 hours of making the payment or becoming aware that it was made (Cyber Security Act 2024 s27), if [Organisation] is a reporting business entity (turnover above $3 million, or a SOCI Part 2B responsible entity).
• The report must cover, as far as known: contact and business details of the entity that paid; the incident and its impact; the demand; the payment; and communications with the extorting entity (s27(2)).
• Payment does not end the response: eradication, recovery and data breach obligations continue.

A.4 Recovery

• Rebuild from clean images; restore from backups taken before the earliest sign of compromise; reset all credentials; monitor for re-entry.
• Monitor leak sites and dark web sources for stolen data, through the IR provider.

Appendix B. Playbook: business email compromise and payment fraud

Triggers: a fraudulent payment instruction, changed supplier or customer bank details, mailbox rules forwarding or deleting email, or reports of emails sent from a staff account without the staff member's knowledge. Default severity: High if money has been or may be paid; Critical above [$X] or where customer funds are affected.

Appendix C. Playbook: data exfiltration

Triggers: evidence of data leaving the network, an extortion threat, data appearing online, unusual large transfers, or notice from a third party, ASD or the media. Default severity: High; Critical where large volumes of customer or sensitive data are involved.

Appendix D. Playbook: distributed denial of service (DDoS)

Triggers: customer-facing websites, apps, APIs or networks slowed or unavailable through traffic floods. Default severity: Medium; High or Critical where a critical operation is disrupted or tolerance is at risk.

Appendix E. Playbook: insider threat

Triggers: a staff member, contractor or service provider employee misusing access, for example taking data, sabotaging systems, committing fraud or helping an outside attacker. Default severity: set on impact.

Appendix F. Playbook: compromised service provider or material service provider

Triggers: a service provider notifies a security incident, or [Organisation] detects suspicious activity coming from a provider's connection, software or update. Default severity: High where the provider holds [Organisation]'s data or connects to its systems; Critical where a material service provider or critical operation is affected.

Appendix G. Playbook: customer account takeover

Triggers: customers report unauthorised logins, changed contact details or unauthorised transactions; monitoring detects credential stuffing or unusual login patterns. Default severity: Medium; High or Critical where many customers or large losses are involved, or where [Organisation]'s own systems are the source of the stolen credentials.

Appendix H. First-hour checklist

Appendix I. Contact list template

Keep this list current (checked [quarterly]) and available offline. Include after-hours numbers.

Appendix J. Incident log template

The Scribe records every significant fact, action and item of evidence in time order. Times are in [AEST/AEDT] with the date.

Appendix K. Decision log template

Appendix L. Regulator notification checklist

Complete for every Critical and High incident and any incident that may be notifiable. Record the time of awareness for each obligation, the deadline, and the decision with reasons.

Appendix M. Post-incident review template