Document a Plan for Communicating Incidents to AI System Users
Your organisation must create and write down a plan for how it will tell users of the AI (artificial intelligence) system when an incident happens.
Plain language
When something goes wrong with your AI (artificial intelligence) system, the people who rely on it deserve to be told. This control asks your organisation to work out, in advance, how you will let users know when an incident occurs, and to write that plan down so it is not invented in a panic on the day. An incident might be the AI giving wrong or harmful answers, an outage, a security breach, biased decisions, or any failure that affects the people using it. A good communication plan answers simple questions: who do we tell, what do we say, how soon, and through which channel (email, in-app message, phone, public notice). Having this written down means everyone knows their role, users are treated honestly, and your organisation keeps the trust of the people it serves. It is part of your AIMS (AI management system) and shows you take responsibility when things do not go to plan.
Framework
ISO/IEC 42001:2023
Control effect
Responsive
Classifications
N/A
Official last update
01 Dec 2023
Control Stack last updated
18 June 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
Without a written plan, users may be left uninformed when the AI fails, damaging trust and slowing the organisation's response to incidents.
Operational notes
Keep the plan current as the AI system and user base change, and review it whenever a new type of incident or user group appears.
Implementation tips
- The AI system owner writes a documented incident communication plan that names who must be told, what message they receive, how quickly, and through which channel such as email, an in-app notice, or a phone call.
- The compliance manager defines clear triggers that decide when users must be notified, for example wrong outputs affecting decisions, an outage beyond a set time, a data breach, or biased results, so staff are not left guessing.
- The operations team prepares ready-to-use message templates and a contact list of affected user groups in advance, so notifications can go out quickly and consistently when an incident happens.
- The AI system owner assigns named roles and a backup for each step of the plan, covering who approves the message, who sends it, and who answers follow-up questions from users.
- Senior management reviews and approves the plan, then schedules a rehearsal or walkthrough at least once a year so the plan is tested before a real incident occurs.
Audit / evidence tips
- Askthe written plan that describes how the organisation communicates AI incidents to users, and confirm it exists as an approved document rather than informal practice
- Look atwhether the plan clearly states who is notified, what they are told, how soon, and through which channel, and whether it defines what counts as an incident worth reporting
- Askwho is responsible for sending notifications and for approving the message, and check that named roles with a backup are recorded so the plan does not depend on one person
- Look atany past AI incidents and check whether users were actually notified in line with the plan, including dates, message content, and the channel used
- Goodan approved, current plan with defined triggers, named owners, prepared message templates, and evidence that it has been rehearsed or used correctly during a real event
Cross-framework mappings
How Annex A 8.4 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
| layers Partially meets (1) expand_less | ||
| Annex A 5.24 | Annex A 8.4 requires documenting a plan for communicating incidents to AI system users | |
| handshake Supports (1) expand_less | ||
| Annex A 5.5 | Annex A 8.4 requires the organisation to determine and document a plan for communicating AI incidents to AI system users | |
ASD ISM
| Control | Notes | Details |
|---|---|---|
| layers Partially meets (1) expand_less | ||
| ISM-1880 | Annex A 8.4 requires a documented plan for communicating AI incidents to AI system users | |
| sync_alt Partially overlaps (2) expand_less | ||
| ISM-0043 | Annex A 8.4 requires the organisation to determine and document a plan for communicating incidents to users of the AI system | |
| 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 | |
| handshake Supports (1) expand_less | ||
| ISM-1819 | Annex A 8.4 requires the organisation to determine and document a plan for communicating incidents to AI system users | |
| extension Depends on (1) expand_less | ||
| ISM-0576 | Annex A 8.4 requires the organisation to determine and document a plan for communicating AI system incidents to AI system users | |
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.