ISO 42001 Annex A.8.4: Plan Communication About AI Incidents

What control A.8.4 requires in practice

Control A.8.4 asks the organisation to decide and write down a plan for communicating incidents to the users of an AI system. The key word is plan: the thinking happens before an incident, not during one. Annex B guidance says incidents can concern the AI itself, information security or privacy, and that notification duties depend on context, for example a safety-related product may face different expectations from other systems. Contracts and regulation can set which incidents must be communicated, the time allowed, which authorities to inform and what detail to give. The guidance also says AI incident handling may be folded into the organisation's wider incident management, while staying alert to AI-specific features. The outputs are a documented plan, clear authority to decide on communication, and records of messages sent.

Understand which obligations and audiences matter

Annex B.8.4 recognises that incidents can involve AI behaviour, information security, privacy or other effects. Relevant obligations can determine incident types, timing, recipients and required details. The guidance must be considered under clause 6.1.3(e), with tailored implementation permitted by B.1.

Obtain suitable advice where legal or contractual interpretation is needed. ISO 42001 does not establish a blanket notification deadline for every jurisdiction and system. A plan should identify how the organisation determines the applicable requirement and who can make the communication decision.

Why control A.8.4 matters to the business

In an incident, confusion over who decides, who is affected and what to say turns a technical problem into a trust problem. Customers judge a business by how clearly it tells them what happened and what to do, often more than by the fault itself. A prepared plan avoids contradictory messages from different teams and prevents the opposite failure, silence while waiting for certainty. It also helps where several parties share a service, since each knows who informs whom. Auditors look for scenario-tested plans that connect to existing incident processes and to the organisation's real legal and contractual duties.

How to implement control A.8.4

Prepare the decision path now, and test it with a realistic scenario. Keep the plan short enough to be used under pressure, and remember that the same event may touch security, privacy and service teams at once, so the plan should say who coordinates them when facts are still emerging.

1. List the AI systems and the user groups each affects, including clients who pass the service on.
2. Identify the legal, contractual and regulatory duties that apply, and get specialist advice where interpretation is unclear.
3. Name who classifies an incident, who identifies the affected users and who authorises the message, with a stand-in for each.
4. Define how facts are verified and how uncertainty will be stated, and how updates will follow.
5. Agree how suppliers and clients exchange information so that no party assumes another has communicated.
6. Connect the plan to the existing security, privacy and service incident processes, checking the interfaces.
7. Run a tabletop exercise with incomplete evidence and record what the team changed afterwards.

Illustrative IT example: a supplier incident affects local use

Illustrative BPO example: several parties need coordinated information

A BPO provider discovers that an AI summarisation change omitted a consequential category of customer instruction. The BPO operates the process, the client controls customer communication and the technology supplier controls part of the service.

The plan should explain how these responsibilities connect and how necessary information is exchanged. A contract label alone may not settle the practical hand-off. The organisation should avoid assuming that another party has communicated simply because that party was informed.

Plan for evolving information

During an incident, the full cause may be unknown. A useful plan explains how information is verified, how uncertainty is stated and how updates are managed. The organisation should not manufacture certainty, but neither should it adopt a universal rule to say nothing until every technical detail is resolved.

Timing and content follow the actual obligations and needs. Users may need clear operating instructions even while investigation continues. Coordinate messages so that different teams do not provide conflicting statements about scope or required action.

Integrate with existing incident arrangements

Existing security, privacy or service incident processes can provide useful foundations. Examine AI-specific consequences and interfaces rather than create a separate process for every possible event. A system-output issue can be consequential without being a data breach.

Connect the plan with external reports, interested-party obligations and operational investigation. Preserve clear ownership when an incident crosses several processes.

Evidence and practical tests

Common nonconformities with control A.8.4

Common findings are usually about preparation rather than technology. The following turn up repeatedly.

• A plan copied from a security or privacy procedure, with no consideration of incidents caused by AI outputs rather than data loss.
• A fixed notification deadline stated in the plan that cannot be traced to any contract or law the organisation is actually subject to.
• No named decision-maker or substitute, so approval of a message depends on whoever happens to be available.
• Messages that describe the technical event but omit what affected users should do next.
• A supplier or client relationship where each side assumes the other will communicate, and nothing is agreed.