ASD ISM 1881 Timely reporting of cyber incidents without data breach
What it says
Cyber security incidents that do not involve customer data are reported to customers and the public in a timely manner after they occur or are discovered.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishInform customers about cyber incidents quickly if no customer data is involved.
This control is about making sure you tell your customers quickly if something goes wrong with your computer systems, even if their data isn't at risk. This is important because being transparent can maintain trust and prevent any misunderstandings or rumours about your business.
Free. Save your status, tasks and notes.
Why it matters
Delays in reporting cyber incidents (without customer data involved) can fuel rumours, harm public trust and drive customer attrition.
How to implement
The IT manager should ensure that there is a clear process in place for identifying cyber incidents that do not involve customer data.
This can be done by creating a checklist for the IT team to follow whenever they suspect an incident has occurred.
Communication managers should prepare a template for notifying customers about non-data-breaching incidents.
This template should be straightforward and focus on what happened, how it's being fixed, and reassure them about their data.
The IT team should conduct regular training for all staff on recognising potential cyber incidents.
They can hold monthly workshops to ensure everyone knows what to look for and how to report it.
The office manager should establish a protocol for the timeline of communicating with customers.
This could involve setting a maximum of 48 hours from discovering an incident to notifying clients.
The system owner should designate a specific point of contact within the organisation for cyber incident reporting.
This person should be clearly identified so customers know who to speak with if they have concerns or questions.
Keep it running
Define triggers and timeframes to notify customers and the public of non-data cyber incidents; maintain comms templates, contacts and an approval workflow.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Incident communication policies: Request the documents that detail how and when to notify customers of incidents.
Look at
The timelines and responsible parties outlined.
Good evidence
Includes clear procedures and specific timeframes for reporting.
- Check 2 of 5What an auditor asks for
Ask for
Recent incident reports where no customer data was involved.
Look at
How quickly these reports were communicated to customers.
Good evidence
Will show prompt communication, ideally within 48 hours.
- Check 3 of 5What an auditor asks for
Ask for
Staff training records.
Look at
Records showing participation in workshops or training sessions on incident recognition.
Good evidence
Includes frequent, well-documented training sessions.
- Check 4 of 5What an auditor asks for
Ask for
To see the incident notification templates: Verify the templates for clarity and completeness.
Good evidence
Will include easy-to-understand language, with sections for the incident summary, response actions, and customer reassurance.
- Check 5 of 5What an auditor asks for
Ask for
To speak with the designated incident contact person: Check they are aware of their responsibilities and are knowledgeable about the communication process.
Good evidence
Includes confidence in their role and understanding of protocol.
Mappings
Closest match in ISO/IEC 42001: A.8.4, Document a plan for communicating incidents to AI system users, which partially overlaps with this control.
ISO/IEC 27001: 1 mapping
This control depends on A.5.24.
ISM-1881 requires timely reporting to customers and the public about cyber incidents that do not involve customer data. Annex A 5.24 requires planning and preparation for incident management, including defining and communicating processes, roles and responsibilities, which is a prerequisite to executing timely external communications. The ISO control is broader incident-management governance and does not explicitly require customer/public reporting.
ISO/IEC 42001: 1 mapping
This control partially overlaps A.8.4.
Annex A 8.4 requires the organisation to determine and document a plan for communicating AI system incidents to users of the AI system. This overlaps with ISM-1881, which requires timely reporting of cybersecurity incidents to customers and the public. The overlap is in having a plan for outward communication after incidents. However, ISM-1881 is focused on public-facing cyber incidents, while Annex A 8.4 is specific to AI incidents affecting users.
ASD Essential Eight: 1 mapping
This control depends on E8-AH-ML2.16.
ISM-1881 requires timely reporting of cyber incidents (without customer data involvement) to customers and the public. E8-AH-ML2.16 requires immediate reporting of incidents to the CISO, which is typically required to validate the incident, approve messaging, and coordinate external communications. E8-AH-ML2.16 does not cover communications to external parties, only internal escalation.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.




