A.8.4 Communication of incidents: requirements and evidence

What ISO 42001 A.8.4 asks an AI-using organization to plan

An auditor or a customer questionnaire asks a simple question: when an AI system goes wrong, how are the people who use it told? Control A.8.4, Communication of incidents, in ISO/IEC 42001:2023 expects the organization to have determined and documented a plan for telling users about incidents involving an AI system. The plan answers four questions: what counts as an incident, who is told, how quickly they are told, and through which channel. Each answer has to be written down before anything happens, so that the organization can show an assessor how it would act and what users would receive.

The reason to plan this separately is that incident communication to users is a different job from internal incident response. Internal response covers containment, root cause analysis and fixes. A.8.4 concerns the information flow outward to the people relying on the system, so that they can stop acting on harmful or faulty outputs, switch to a manual process or check results they have already used. It also differs from A.8.3, which covers intake of reports about adverse impacts from outside parties. A.8.4 is about what the organization sends to users when it knows, or has good reason to believe, that an incident has happened.

The hard part is agreeing definitions before an incident occurs. Engineering, product, legal, support and the business owner often read the word incident differently: a model drift that degrades accuracy for one customer segment may or may not qualify. Write severity levels with concrete triggers, such as a confirmed erroneous output in a decision affecting a person, a safety or security event, or a material change to the system's behavior. Then map each level to a notification time, an audience and a channel, and record who can declare an incident and who approves the message. Confirm the notification windows with your legal and contractual obligations, since the standard does not supply them.

Which AI incidents, users and teams A.8.4 covers

A.8.4 only works if the organization first settles what sits inside the AI management system, who must be told, and who acts. The cards below set out the decisions that change the scope of the communication plan, and they close with how the statement of applicability records the choice to include or exclude the control.

AI systems inside the AIMS scope

Start by listing which AI systems fall within the scope of the AI management system. An incident plan that covers only the flagship model misses the internal copilot, the scoring tool bought from a vendor, or the feature shipped last quarter. For each system, record its owner, its user groups and whether it is customer-facing. Ask whether the scope statement under clause 4.3 matches the inventory the incident team actually uses, because a mismatch leaves some systems with no notice path at all.

User groups who receive notices

Internal staff, paying customers, end users of a product, and API consumers each need different information and arrive through different channels. Internal staff may be reached through the ticketing system, while API consumers may need a status feed or a changelog entry they can subscribe to. Decide for each group what counts as material enough to notify, and who approves the message. Document these groups in the plan so that a notice does not depend on whoever happens to be on call.

Third-party models and suppliers

Many incidents begin upstream. A foundation model provider may change behavior, a data supplier may withdraw a dataset, or a hosted inference service may suffer an outage that alters outputs. Identify which third-party models or suppliers can cause an incident your organization must relay to its own users, and confirm in the supplier contract that the provider will notify you within a timeframe your plan can meet. Where a supplier cannot commit, record that gap as a risk so the reviewer sees it.

Teams that detect, decide and notify

Separate three roles: the team that detects an event, the owner who decides whether it is an incident, and the communicator who writes and sends the notice. Engineering, product, legal, privacy and customer support often each hold part of this chain. Name a primary and a backup for each role, and state the hours they cover. A plan that assigns the decision to a group nobody can reach overnight will not meet its own timing commitments.

Statement of applicability entry

Clause 6.1.3 requires a statement of applicability that lists the Annex A controls the organization needs and justifies including or excluding each one. The entry for A.8.4 should state whether the control applies, point to the incident communication plan as its evidence, and give a reason if it is excluded. An exclusion is hard to defend when the organization operates AI systems that users rely on, so reviewers will ask for the justification in writing.

How an assessor tests the A.8.4 incident communication plan

This table compares what an assessor examines in the A.8.4 plan document, the records that show it was followed, and the gaps that most often produce findings. Read each row as a test the assessor runs, then check whether your own plan and records would pass it. The main takeaway is that a written plan alone rarely passes; the assessor wants to see defined thresholds, a notice trail for a real or simulated incident, and a review cycle.

Test area	What the assessor samples or asks for	Common nonconformity
Plan definitions	A documented definition of what counts as an AI incident, with severity levels and the criteria that trigger user notice	Incident threshold left undefined, so staff cannot tell whether an event requires notice
Recipients and audience	A list of which user groups are told, by system and by incident type, consistent with the user population in the A.8.2 information	Plan names no recipients, or notices reach only internal teams and not the affected users
Timing	Stated deadlines or triggers for notice, such as from detection or from confirmation, with the owner accountable for each step	Timing is described as 'prompt' or 'as soon as practical' with no owner or trigger point
Channels and content	Approved channels (in-product, email, status page, contract notice) and the minimum content each notice must carry	Channels named in the plan do not exist in practice, or notices omit what users need to act
Approvals and roles	Who drafts, approves and sends notices, plus an escalation path when the usual approver is unavailable	No approval step recorded, or the same person both decides and sends without a second check
Evidence of a real or simulated incident	Incident records, tabletop or simulation reports, timestamps of detection and notice, and copies of the notices sent	No record of a past notice or exercise, so the plan is untested on paper only
Consistency with A.8.2 and A.8.5	Cross-reference showing the user information in A.8.2 matches the notice content, and that obligations under A.8.5 to other interested parties are reflected in the plan	Incident plan contradicts the user documentation or ignores reporting duties to regulators or customers
Review and improvement	Dated plan revisions, review records, and lessons learned from exercises or incidents fed back into the plan	Plan never reviewed since drafting, or lessons from an incident are not reflected in a revised version

Building the incident communication plan step by step

This sequence turns the A.8.4 requirement into a documented plan that defines incidents, names who is told and how, and proves the plan works before an event forces it into use.

Define what counts as an AI incident
Start by writing a definition of an AI incident that fits your systems, such as a harmful or unexpected output reaching users, a model behaving outside its documented limits, a data exposure linked to the system, or a safety control failing. Have the AI owner, security lead and product owner agree the list, and record the severity levels that decide when users must be told. The output is an approved incident definition and severity scale that every later step refers back to, so the plan can be checked against it during an assessment.
Map affected user groups and channels
For each AI system in scope, list the user groups that could be affected by an incident, including internal staff, paying customers, end users of embedded features and any operators who deploy the system themselves. Then document the channel each group normally uses, such as in-product notices, email, a status page or account manager contact, and confirm a backup route exists if the primary channel is the system that failed. The output is a mapping table of system, user group, channel and owner that shows who can be reached and how.
Set notification timing and approval roles
Decide, per severity level, how quickly users must be told once an incident is confirmed, and who has authority to approve the message before it is sent. Assign a named approver for each channel, a deputy for absences, and a rule for when legal, privacy or communications staff must review. Where a contract, regulator or customer agreement sets a notification obligation, record that obligation next to the internal timing so the stricter requirement governs. Ask your auditor and counsel to confirm the timing against those external duties. The output is a signed timing matrix and approval chain.
Draft notice templates in advance
Write reusable notice templates for the common incident types, covering what happened in plain language, which users are affected, what they should do or stop doing, what the organization is doing, and where to get updates. Keep the wording factual and avoid speculation about cause until it is confirmed. Store the templates with version numbers and the approval record so the reviewer can see which template was current and who signed it off. The output is a controlled set of templates tied to each severity level and channel.
Link the plan to incident response and records
Connect the communication plan to your incident response process so that detection, triage and classification trigger the notice workflow at defined points. Specify which incident record holds the decision log, the approved message, the send time, the recipients and any follow-up notices. Where your team uses a case management tool, such as the open-source DFIR-IRIS platform for case records, timelines and evidence handling, confirm it can hold these communication entries with an audit trail. The output is a documented workflow diagram and a record structure that proves who was told, when and what they received.
Rehearse the plan with a tabletop exercise
Run a tabletop exercise based on a realistic but illustrative AI incident, such as an AI feature producing incorrect guidance to customers. Include the incident owner, approvers, communications staff and the people who would send notices, and time each decision against your documented timing matrix. Record gaps, such as unclear approvers, missing contact details or templates that do not fit the scenario, and assign owners and due dates for fixes. The output is a dated exercise report with findings and corrective actions, which becomes evidence that the plan has been tested and improved.

Evidence that passes A.8.4 and how to keep it current

An auditor testing A.8.4 Communication of incidents looks for a documented plan and proof that it works in practice. The cards below cover the artifacts that show the plan exists, has been approved, has been used and has been reviewed, along with the routine that keeps each one current between audits.

Approved incident communication plan

This is the core document: it states who is told about an AI incident, how quickly, through which channel and who approves the message. Keep it under version control with a dated approval record for each version, so the auditor can see which version was in force on any given date. Check that the plan names owners by role rather than by individual, so it stays valid when staff change. Tie each revision to a documented change trigger, such as a new AI system going live or a change in customer contracts.

Incident definition and severity criteria

A.8.4 depends on a shared meaning of "incident" for an AI system. This artifact sets the definition, the severity levels and the threshold at which user notice becomes mandatory, including incidents caused by a supplier's model. Test the criteria against past events to confirm that borderline cases land at a consistent level. Review the thresholds whenever the risk assessment under A.5 changes, since a new impact on individuals or groups may justify a lower threshold for notice.

Notice templates and approval trail

Pre-approved templates for each severity level and channel let staff issue accurate notices under time pressure. Each template should state what happened, which users are affected, what they should do and where to get updates. Store each template with its version, owner and last legal or communications review date. After every exercise or real notice, record which template fields were slow to complete and update the template, so the next version reflects what actually happened.

Records of past notices

For each notice sent, keep a record that shows when the incident was detected, when the decision to notify was made, when the notice went out, the channel used and the recipients reached. Timestamps are the evidence auditors check most closely against the plan's stated timeframes. Where a case management tool is used, DFIR-IRIS (LGPL-3.0-or-later) can keep incident records with a full audit trail, build a consolidated timeline and generate reports from case data. The organization must confirm that its fields and retention meet its own needs for user-notice records before relying on it.

Exercise reports and corrective actions

A tabletop or simulated notice exercise shows whether the plan works with real people in real roles. Each report should record the scenario, the timing achieved against the plan, the gaps found and an owner and due date for each corrective action. Schedule exercises at a fixed interval set in the plan, and close corrective actions with evidence of completion. An auditor is more likely to accept an exercise that found weaknesses and fixed them than a clean report with no follow-up.

Review log tied to management review

A review log records each periodic check of the plan, the templates and the severity criteria, with the reviewer, date, outcome and any changes made. Schedule these reviews as an input to the management review meeting required by the management system, so the outcomes reach senior leadership and are minuted. Include a trigger for unscheduled reviews after any notable incident, supplier change or regulatory update. Confirm the review interval with your certification body and the internal audit program, since the appropriate frequency depends on how often your AI systems change.

What meeting A.8.4 costs in money and effort

This table breaks down the cost and effort components of meeting A.8.4 Communication of incidents, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. No supplied source gives figures for these components, so use the table to structure your quote requests and internal budgeting rather than as a price estimate.

Cost component	One-time or recurring	What drives it up or down
Drafting and approving the incident communication plan (internal time)	One-time, then reviewed periodically	Number of AI systems in scope, number of user groups, and how many legal, product and security owners must sign off
Incident record tooling and licenses	Recurring license cost if commercial; one-time setup for self-hosted open source	Whether a commercial case management product is already licensed; self-hosted open-source tools remove license spend but add hosting and administration effort
Notification channel setup (email, status page, in-app alerts)	One-time build, recurring operation	Number of channels, whether templates exist, and whether a third-party status or messaging service is contracted
Exercise time (tabletop or simulated notification drills)	Recurring, at the interval the organization sets	Number of AI systems exercised, complexity of user groups, and whether an external facilitator is used
Evidence upkeep (incident logs, notification records, plan revisions)	Recurring	Incident volume, retention rules, and how much evidence is captured automatically by the tooling
External review of the plan (legal, privacy or independent advisor)	One-time, plus recurring on material change	Regulatory exposure of the AI system, such as sector rules, and whether in-house counsel can review
Implementation partner support (preparing the plan, tooling and evidence)	One-time, optionally retained	Fixed scope agreed in writing, number of systems, and whether the partner also builds the tooling
Auditor sampling time for A.8.4 evidence	Recurring at each audit cycle	Number of incidents or exercises sampled, and how quickly evidence can be produced in the form the auditor requests

Doing A.8.4 in-house or with an implementation partner

Your organization owns the communication plan. A.8.4 asks for a documented plan for telling users about incidents involving an AI system, and the decisions inside that plan carry legal, customer and reputational weight that cannot be delegated. Those decisions belong to people who understand the product, the affected users and the contracts that apply.

Incident definition: Decide which events count as an AI incident, such as harmful or unexpected outputs, material model failures, data exposure or misuse, and who can declare one.
Notice approval: Name the roles that approve user notices, with a deputy for out-of-hours events.
Legal review: Have counsel check notice wording against contracts, consumer rules and any sector obligations that apply to your organization.
User-facing wording: Own the language users receive, written so that it states what happened, what users should do and when more information will follow.
Timing and channels: Set how quickly each class of incident is communicated and through which channel, such as in-product banners, email or account portals.

Before relying on this tab, confirm that each decision has a named owner and a written record of who approved it.

Where incident communication plans fall short and how to close the gap

Most A.8.4 plans fail in predictable places: the trigger for an incident is never defined, nobody owns the notify decision, and the plan has never been run. Each gap below is closed by a specific decision or record that an assessor can ask to see.

Incident definition too vague

A plan that says any "significant problem" is an incident cannot be applied at 2 a.m. Define AI incidents by observable conditions, such as harmful or incorrect outputs reaching users, unintended behavior after a model or prompt change, or a suspected data exposure through the system. Include near misses that the organization chooses to communicate. Check that an on-call engineer can classify a sample event from the written definition alone. Evidence: the approved definition, severity criteria and a classified sample log.

No named notification owner

When nobody holds the decision to notify users, notices are delayed while people wait for approval from each other. Name one accountable role for the notify decision, a deputy for absence, and the people who must be consulted, such as legal, privacy and the product owner. Record who may approve wording and who may stop a notice. Evidence: a RACI or role table in the plan, signed by the accountable executive, that matches the roles recorded under A.3.2.

Notices that live in ad hoc email

If user notices are drafted in personal inboxes and sent from whoever is available, the organization cannot show what was said, to whom or when. Define approved channels, such as in-product banners, status pages or account-level notices, and keep templates for common incident types. Log every notice with its timestamp, audience and approver. Evidence: template library, sent-notice register and the status page or in-product message history.

No timing criteria

A plan that says notify users "promptly" gives no basis for a decision and no test an assessor can run. Set timing rules tied to severity, such as the maximum time from classification to first notice for each severity level, and state what happens when facts are still unknown. Confirm the timings with legal and contract owners, since customer agreements and regulators may set their own deadlines. Evidence: a severity-to-timing table and the timestamps from real or exercised incidents.

Plan never exercised

A written plan that no one has run tends to fail on its first real use, usually at the classification or approval step. Run tabletop exercises that use a realistic AI scenario, such as a model returning harmful advice to a customer, and time each decision. Record what slowed the team and update the plan. Evidence: exercise scenario, attendee list, timeline of decisions and a dated list of corrective actions closed afterward.

A.8.4 not linked to A.8.2

Incident notices often contradict the user documentation that A.8.2 requires, for example by describing a limitation that the incident revealed as an unknown. Map each incident type to the user information it affects, and state in the plan when the user guide, intended-purpose statement or oversight instructions must be updated alongside a notice. Evidence: a cross-reference table between incident types and A.8.2 documents, with revision dates showing updates made after incidents.

Questions buyers ask about A.8.4 cost, effort and outside help

How much effort does A.8.4 usually take and what drives it?

The effort depends less on the control text than on how many AI systems are in scope and how many parties depend on each one. A single internal model used by one team needs a short plan. A customer-facing system with several user groups, contractual notice duties and a mix of hosted and self-hosted components needs more work. The main drivers are the number of AI systems, the number of user populations, how many existing incident processes can be reused, and how much the organization must reconcile with other notice duties such as security incident reporting or breach notification. Ask any provider to break its quote into definition of incident categories, notification matrix, channel setup, testing and sign-off, and to state which items assume your existing incident response process is already documented.

How long does an A.8.4 communication plan take before an audit?

The duration depends on how far the organization already is with incident management and AI system inventories. Where an inventory and an incident response procedure exist, drafting the communication plan is usually the smaller task, and the longer work is agreeing thresholds and approvals across legal, product and security. Where they do not exist, those prerequisites come first. Ask for a schedule with dated milestones and for the assumptions behind it. Note that the plan also needs to be used: an assessor will usually look for evidence that it was exercised or that a real or simulated incident followed it, so leave time for at least one walkthrough before the audit date.

What does A.8.4 need from the compliance lead and incident responders?

The compliance lead owns the control record: the scope of AI systems, the statement of applicability entry, the approved plan and the evidence that it is maintained. Incident responders own the operational side: defining what they can detect and classify, confirming who on-call can trigger a notice, and running the notice steps during an event. Legal and product owners usually decide notice content and deadlines for users. Plan for a few working sessions with each group, a review cycle when the plan changes, and time during an exercise. Responders should not be asked to write the policy language alone, and compliance should not be asked to judge technical severity without their input.

Can an organization write its A.8.4 plan without outside help?

Yes. ISO/IEC 42001 does not require an external author, and an organization that already runs incident response and maintains an AI inventory can write the plan internally. Outside help tends to add value where the team lacks experience with AI-specific incident categories, such as model failures, harmful outputs or unexpected data exposure, or where the plan must map cleanly to other frameworks the organization follows. The plan is only credible if the people named in it recognize their role, so internal ownership remains essential whoever drafts the text. Decide early who signs off, because the approver's identity matters more to an assessor than the drafting history.

What can an implementation partner take on under a fixed scope?

DeployOpen works on a fixed-scope basis, with scope, deliverables and timelines agreed in writing before work starts. For A.8.4, an engagement can cover preparing the systems and evidence the plan depends on, such as configuring the incident intake and case records in self-hosted tooling, building the notification workflow and its audit trail, and documenting the procedure for the organization to approve. The organization keeps ownership of the control itself, the decisions on what counts as an incident and who must be told, and the sign-off. DeployOpen does not issue audit reports or certificates. Ask any partner to list what is excluded from its scope so the boundary is clear before signing.

Can the same firm that implements A.8.4 also be the auditor?

No, not for a certification that the organization wants to rely on. An implementation partner prepares systems, controls and evidence, while only an independent auditor or an accredited certification body can assess conformity and issue a report or certificate. Using the same firm for both roles creates a conflict of interest that assessors and certification bodies will examine, and it weakens the independence that buyers and regulators expect. ISO does not certify organizations itself; external certification bodies do, and accreditation of those bodies is voluntary. Confirm the certification body's independence rules and accreditation status before engaging anyone to prepare the evidence.

How DeployOpen scopes and prepares A.8.4 evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, so the incident communication plan and its records sit where the organization operates its AI systems. The organization owns the plan and its decisions, and an independent certification body issues any certificate.

How we scope

The written scope lists which AI systems, user groups and channels the A.8.4 plan covers before work starts.
Scope agreements define which incident categories, notification roles and records are in or out of the engagement.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work begins.
Scoping also confirms which parts the organization will decide itself, such as legal review of notification wording.

How we build

We configure incident intake and case tracking on the client's self-hosted platforms so each AI incident has one record.
Notification workflows are set up to log who was told, when, and through which channel, as the plan requires.
Test scenarios are run against the plan to check that the defined channels and roles work in practice.
Platform hardening and access controls protect incident records, which may contain sensitive user or system data.

How we hand over

Deliverables include the documented communication plan, role assignments, channel definitions and notification templates.
Evidence packs list the incident records, timelines, test results and configuration settings an assessor will ask to see.
Handover covers how to run the plan, including who approves outbound notices and where records are retained.
Written statements are provided that describe what was built, and do not state that any control is certified or attested.

How we support

Ongoing support, upgrades and continuous testing of the incident workflows are available as a retainer.
Retainers can cover periodic review of the plan when AI systems, user groups or reporting obligations change.
Confirm with your certification body or auditor which evidence formats and sampling periods they will accept for A.8.4.
Ask any prospective partner to confirm in writing which tasks stay with your AI governance owner and legal team.