Develop Cyber Security Incident Response Plans
Systems must have a plan for handling and reporting cyber security incidents to ensure quick and effective responses.
Plain language
A cyber security incident response plan means having a clear plan for what to do if something goes wrong with your computers or data. This is important because without one, you might not know how to quickly fix issues like data breaches or hacking, leading to more damage, loss of trust, and potential legal issues.
Framework
ASD Information Security Manual (ISM)
Control effect
Responsive
Classifications
NC, OS, P, S, TS
ISM last updated
Aug 2023
Control Stack last updated
19 Mar 2026
E8 maturity levels
N/A
Official control statement
Systems have a cyber security incident response plan that covers the following: - guidelines on what constitutes a cyber security incident - the types of cyber security incidents likely to be encountered and the expected response to each type - how to report cyber security incidents, internally to an organisation and externally to relevant authorities - other parties which need to be informed in the event of a cyber security incident - the authority, or authorities, responsible for investigating and responding to cyber security incidents - the criteria by which an investigation of a cyber security incident would be requested from a law enforcement agency, the Australian Signals Directorate or other relevant authority - the steps necessary to ensure the integrity of evidence relating to a cyber security incident - system contingency measures or a reference to such details if they are located in a separate document.
Why it matters
Without a documented incident response plan, incident detection, reporting and evidence handling are delayed, increasing business impact and risking missed external reporting obligations.
Operational notes
Review and exercise the incident response plan; confirm roles/authorities, internal/external reporting paths, incident types and responses, and steps to preserve evidence integrity.
Implementation tips
- The IT manager should define what counts as a cyber security incident by listing possible threats like virus attacks or hacking attempts. Write these down clearly so everyone knows what to look out for.
- The office manager should ensure everyone knows how to report suspected incidents, both within the organisation and to external authorities such as the Australian Signals Directorate (ASD). Have an easy-to-follow guide or flowchart displayed in common areas.
- Your IT team should outline a response procedure for common incidents. For example, what steps to take if there’s a data breach, such as who to call first and what systems to check. Keep these steps handy and easy to find.
- Assign responsibility to a specific person or team to investigate incidents. Make sure this person knows their role and has access to the necessary tools and support. Document this responsibility in formal job descriptions or team roles.
- Develop a checklist to ensure evidence like logs or emails are preserved in case of an incident. Train all staff on this checklist so everyone understands the importance of evidence in an investigation.
Audit / evidence tips
-
Askthe incident response plan document
Goodplan will clearly include responsible persons and contact points
-
Askthem how updates are communicated and what improvements are made based on past incidents
Goodinvolves regular updates and process reviews after incidents
-
Goodoutcome is a quick and organised response with team members knowing their roles
-
Askcommunications to external authorities: Check for formal reports sent to organisations like the ASD in relevant scenarios
Goodrecord includes timely and accurate information filed with the correct entity
Cross-framework mappings
How ISM-0043 relates to controls across ISO/IEC 27001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
| layers Partially meets (1) expand_less | ||
| Annex A 5.26 | Annex A 5.26 requires responding to incidents according to documented procedures | |
| sync_alt Partially overlaps (6) expand_less | ||
| Annex A 5.1 | Annex A 5.1 requires topic-specific policies to be defined, approved, communicated and reviewed, including for areas like incident manage... | |
| Annex A 5.2 | Annex A 5.2 requires information security roles and responsibilities to be defined and allocated according to organisational needs | |
| Annex A 5.5 | Annex A 5.5 requires the organisation to establish and maintain contact with relevant authorities to enable engagement when needed | |
| Annex A 5.24 | ISM-0043 requires systems to have a cyber security incident response plan covering definitions, incident types and responses, reporting (... | |
| Annex A 5.28 | ISM-0043 requires incident response plans to include steps necessary to ensure the integrity of evidence relating to a cyber security inc... | |
| Annex A 5.29 | Annex A 5.29 requires planning to maintain information security at an appropriate level during disruption | |
| handshake Supports (3) expand_less | ||
| Annex A 5.23 | Annex A 5.23 requires the organisation to learn from security incidents and use those lessons to improve security controls and prevent re... | |
| Annex A 5.25 | Annex A 5.25 requires the organisation to assess information security events and decide whether they are incidents | |
| Annex A 6.8 | Annex A 6.8 requires a mechanism and defined channels for prompt reporting of information security events and suspected weaknesses | |
| extension Depends on (1) expand_less | ||
| Annex A 5.27 | Annex A 5.27 requires that knowledge gained from information security incidents is used to strengthen and improve information security co... | |
E8
| Control | Notes | Details |
|---|---|---|
| layers Partially meets (2) expand_less | ||
| handshake Supports (2) expand_less | ||
| extension Depends on (5) expand_less | ||
| link Related (2) expand_less | ||
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.