Communication of Incidents
Organisations must have a documented plan to inform users about AI system incidents.
Plain language
Think of the worst case: your AI recommends a wrong product or says something incorrect to a customer, and they are upset. You need a plan to let people know about these mess-ups quickly and clearly. This helps fix trust issues and prevents bigger problems.
Framework
ISO/IEC 42001:2023
Control effect
Responsive
Classifications
N/A
Official last update
01 Dec 2023
Control Stack last updated
19 May 2026
Maturity levels
N/A
Official control statement
The organisation shall determine and document a plan for communicating incidents to users of the AI system.
Why it matters
If you don't quickly tell users about AI mistakes, they might lose trust in your company, leading to angry customers and potential losses.
Operational notes
Keep a template ready to quickly communicate to users when the AI makes serious errors, to maintain transparency and trust.
Implementation tips
- The AI lead should create a simple plan to notify users when your AI makes a big mistake. This could be as straightforward as an email template that explains what happened and what you're doing to fix it.
- Product owners need to track AI incidents and ensure they inform customers immediately. A dedicated incident log stored in shared company software will help keep everyone up to date.
- The head of risk should assess which incidents are serious enough to warrant communication to the users. Use a basic checklist that outlines criteria for incident severity.
- The board needs to agree on who should be notified outside of the company when a serious incident occurs. Having a list of key contacts with their communication preferences can save time.
- The data steward must ensure any information about incidents is kept private and compliant with laws, like the Privacy Act 1988. Regular updates to privacy policies are crucial to this end.
Audit / evidence tips
- AskRequest the AI incident response plan document. GoodThe plan is documented and includes clear steps for external communication when incidents occur.
- AskAsk to see the last AI incident log entry. GoodThe incident log includes details of notification steps taken for major incidents.
- AskSpeak with product owners about incident notification processes. GoodProduct owners can clearly explain the notification process and know who to contact for each step.
- AskReview past emails sent to users regarding AI incidents. GoodEmails are consistent with the documented incident communication plan.
- AskReview the privacy policy for incident information handling. GoodThe privacy policy is current, specifically referencing incident handling and is compliant with applicable laws.
Cross-framework mappings
How Annex A 8.4 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ASD ISM
| Control | Notes | Details |
|---|---|---|
| layers Partially meets (2) expand_less | ||
| ISM-0043 | Annex A 8.4 requires the organisation to document a plan for communicating AI incidents to users | |
| ISM-0576 | Annex A 8.4 requires the organisation to plan for communicating AI incidents to AI system users | |
| sync_alt Partially overlaps (2) expand_less | ||
| ISM-1880 | Annex A 8.4 requires the organisation to determine and document a plan for communicating AI system incidents to AI users | |
| ISM-1881 | Annex A 8.4 requires the organisation to determine and document a plan for communicating AI system incidents to users of the AI system | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
Want to implement this AI control?
Mindset Cyber runs PECB-accredited ISO/IEC 42001 training that maps directly to the AI controls in this library.