Communicating incidents

The requirement, in our words

Work out and write down how incidents will be communicated to the people using the system, and analyse the notification obligations, including AI-specific cases such as personal data breaches in training data.

What it means for human oversight

The operator is often the first to see an incident. The plan should tell them what to report, to whom, how fast, and what to tell the affected person.

How to evidence it

Attach the artefacts above to the Communicating incidents row with the system name, the owner and the date. The first one is the anchor: An incident communication plan for users. The OH-28 file is complete when the named person can produce that artefact and explain the decision it records, without asking someone else where it is.

The reviewer will sample one live decision and ask for An analysis of notification obligations. If that artefact for OH-28 cannot be produced, the row is a gap, whatever the policy says.

OH-28 carries 3 evidence items and 2 common gaps. For communicating incidents, keep the version the operator actually received with its date, because the current intranet copy is not evidence of what was in force. The OH-28 statement above is ours, written from ISO/IEC 42001:2023, A.8.4, not a reproduction of the licensed text.

Common gaps

• Plan covers regulators but not users
• AI-specific notification requirements not analysed

Related units

• Documented information
• Information for users
• Context and the role you play