Information for interested parties: what Annex A.8 of ISO 42001 requires

An AI system never stands alone. There are users who work with it, customers who rely on it, individuals about whom it makes decisions and sometimes regulators who expect reports. Annex A.8 of ISO 42001 groups the requirements that deal with this: what information you provide to whom, how interested parties can raise concerns and how you communicate when things go wrong. In practice this is a domain where organizations drop points, because attention tends to go to building and managing the systems themselves. This article walks through the four controls of A.8, with the nonconformities we see most often as auditors and the documents a certification body will want to review.

What Annex A.8 covers

Annex A of ISO 42001 is organized into domains, from AI policy and internal organization to data and supplier relationships. The domain on information for interested parties contains four controls. A.8.2 asks for system documentation and information for users. A.8.3 asks for capabilities that allow external parties to report adverse impacts or concerns, and for a grip on your own external reporting obligations. A.8.4 asks for a documented plan for communicating incidents. A.8.5 asks you to determine and document your obligations to provide information about AI systems to interested parties.

As with the other Annex A domains, the risk assessment and the Statement of Applicability determine whether and how these controls apply. For A.8, the outcome is rarely that something falls out of scope. Every AI system has users, and almost every system affects people or organizations beyond the team that runs it.

A.8.2: documentation a user can actually work with

The first control is about the information users of an AI system need to work with it properly. Good user documentation describes, per system, the purpose and intended use, what the system can do and how well it performs, and just as importantly: what it is not good at. Known limitations belong in it, as do the situations in which the system performs less reliably and the risks attached to its use.

The element auditors check first is the human oversight instruction. When should a user review the system's output, how does he recognize borderline cases and how does he override an AI decision? Documentation that only describes functionality and stays silent on limitations and oversight is the most common nonconformity in this domain. The second: documentation that is technically fine but unreadable for the people who use the system daily. The audience determines the form. A developer needs different information than a customer service agent who leans on AI suggestions.

Documentation also ages. Whoever retrains a model or extends a system must update the user information along with it and inform users about the change. Version control on documentation sounds bureaucratic, but it is exactly what an auditor asks for: show that the documentation for this system is current and that users know the latest version.

A.8.3: reporting channels and reporting obligations

The second control has two sides. The first is inbound: interested parties must be able to report adverse impacts or concerns about your AI systems. That requires an accessible channel, internally and externally, and a process that takes reports seriously. A reporting mailbox nobody reads does not count.

The second side is outbound: your own reporting obligations. Which reports about your AI systems do you owe to whom? Think of obligations towards regulators, such as conformity documentation or incident reports, sector-specific arrangements and voluntary transparency reporting, for example an annual responsible AI report. The common nonconformity here is simple: the organization has never inventoried what it must report. A register of external reporting obligations with a calendar behind it solves that. Reports that leave the building should also pass through a review and approval step, so that no unverified figures go out.

A.8.4: a communication plan for incidents

Handling incidents involving AI systems is one thing. Communicating about them is another, and that is what A.8.4 covers. The control asks for a documented plan that defines how you communicate incidents to the users of the system and other affected parties.

A workable plan starts with classification: which severity levels do you distinguish, and which incident types belong to each? It is precisely the AI-specific categories that tend to be missing: detected bias, harmful output, a model that has quietly degraded. Per level you define who gets informed: internal escalation only, or also customers, affected individuals or a regulator. This comes with timelines that align with legal requirements, agreements on the content of the communication (what happened, what is the impact, what are you doing about it) and an approval route via management and, where needed, legal review.

The nonconformity we see most often: there is an incident process, but communication is not part of it. During an exercise or a real incident it then turns out nobody knows who drafts the customer communication and who is allowed to send it. A tabletop exercise around a fictitious AI incident exposes that mercilessly, and doubles as the evidence of operation an auditor likes to see.

A.8.5: knowing what you must tell whom

The last control of the domain asks you to determine and document your obligations to provide information about AI systems to interested parties. In practice this comes down to three layers.

The first layer is the individual who encounters an AI system. Anyone chatting with a bot or subject to an automated assessment should know it, at the moment itself and in plain language. This includes information about rights: can someone request human review, get an explanation of a decision, or contest it? The most common nonconformity here: individuals are simply not informed that AI plays a role in a decision that affects them.

The second layer is customers and partners. Whoever embeds AI in a product or service must inform buyers about it, so they can make their own assessments and meet their own obligations.

The third layer is the public. More and more organizations publish a page or report on how they handle AI: which principles they follow, which types of systems they use and how governance is organized. This is not mandatory in every case, but it is a strong signal to auditor and market that information provision is proactive rather than reactive, only upon request.

For organizations within reach of the EU AI Act, there is a natural connection here. The Act has its own transparency obligations, for example the duty to inform individuals that they are interacting with AI. Whoever has A.8.5 in order already has the foundation for those obligations in place.

What the auditor wants to see

For a certification audit or internal audit, the evidence per control looks like this. For A.8.2: user documentation or model cards per system, human oversight instructions and proof that documentation is maintained and communicated. For A.8.3: a register of reporting obligations, issued reports with approval trails and a working reporting channel. For A.8.4: the communication plan, classification criteria and, if incidents have occurred, the communications sent with their timelines. For A.8.5: the documented information obligations, disclosures towards users, rights information for affected individuals and any public information about your AI governance.

The common thread in this domain: the question is not whether you have documents, but whether the information reaches the right people in a form they understand. An auditor testing A.8 therefore talks not only to the AI governance function, but also to a user. If that user does not know what the system can and cannot do, even the finest documentation falls short.