ISO 42001 Annex A 8.4 Document a plan for communicating incidents to AI system users
What it says
The organization shall determine and document a plan for communicating incidents to users of the AI system.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishYour organisation must create and write down a plan for how it will tell users of the AI (artificial intelligence) system when an incident happens.
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.
Free. Save your status, tasks and notes.
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.
How to implement
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.
Keep it running
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.
Evidence and audit
- Check 1 of 2What an auditor asks for
Ask for
the 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 at
whether 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.
- Check 2 of 2What an auditor asks for
Ask for
who 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 at
any past AI incidents and check whether users were actually notified in line with the plan, including dates, message content, and the channel used.
Good evidence
an 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.
Mappings
Closest match in ISO/IEC 27001: A.5.24, Information security incident management planning and preparation, which this control partially meets.
ISO/IEC 27001: 1 mapping
This control partially meets A.5.24.
Annex A 8.4 requires the organisation to determine and document a plan for communicating incidents to users of the AI system. Annex A 5.24 requires planning and preparation for managing information security incidents by defining and communicating incident management processes, roles and responsibilities, which typically includes communication and notification procedures. Annex A 5.24 is broader because it covers the full incident management lifecycle and governance, while Annex A 8.4 focuses specifically on user communications for AI system incidents.
ASD Information Security Manual: 4 mappings
This control partially meets 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-0043 requires a cyber security incident response plan to specify how to report incidents internally and externally and identify other parties that need to be informed, which can include system users where relevant. ISM-0043 is broader because it covers incident definitions, response governance, evidence integrity and contingency measures, while Annex A 8.4 is specifically about user-facing incident communications for an AI system.
This control partially meets ISM-0576.
Annex A 8.4 requires the organisation to determine and document a plan for communicating incidents to users of the AI system. ISM-0576 requires an organisation-wide cyber security incident management policy and associated incident response plan to be developed, implemented and maintained, within which communication to impacted parties can be defined. ISM-0576 is broader and less specific about user communications, while Annex A 8.4 is a targeted requirement for documented incident communications to AI system users.
This control partially overlaps ISM-1880.
Annex A 8.4 requires a documented plan for communicating incidents to users of the AI system. ISM-1880 requires timely reporting of cyber security incidents involving customer data to customers and the public, which overlaps with notifying AI system users when they are customers or affected data subjects. ISM-1880 is conditional on incidents involving customer data and emphasises timeliness and public communication, whereas Annex A 8.4 is AI-system-user specific and requires an upfront documented plan regardless of whether customer data is involved.
This control partially overlaps 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. This overlaps with ISM-1881, which requires timely reporting of cyber security 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.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.
Get help with this control
ISO 42001 training
Mindset Cyber runs PECB-accredited ISO/IEC 42001 training that maps directly to the AI controls in this library.
Turn this control into your AI policy
PolicyMint writes customised ISO 42001 policy documents for your business, audit-ready and exported in your branding (Word, PDF, Excel). Skip the blank page and the boilerplate that does not fit. First document free.
Draft your ISO 42001 documents