7.3 Control Objective A.8: Information for Interested Parties

Annex A.8: information for interested parties

A.8 helps relevant interested parties obtain information needed to understand and assess AI-system risks and positive or negative impacts. It contains four controls. It does not automatically mandate public model cards, explanations for every decision, public registries, or carbon reports.

A.8.2 System documentation and information for users

The organization determines and provides necessary information to AI-system users.

“Necessary” depends on who the user is, what the system does, and what risks and obligations apply. Information can include:

• intended purpose and permitted uses;
• input requirements and operating conditions;
• capabilities and limitations;
• instructions, competence needs, and human interaction;
• output interpretation and uncertainty;
• monitoring, maintenance, or support;
• known failure modes; and
• reporting or escalation routes.

A clinician, software integrator, customer-support agent, and consumer need different forms and depth. Plain language, accessible formats, technical manuals, interface notices, or training can all be appropriate.

A.8.2 does not state that every person must always be told they are interacting with AI or receive a local explanation. Such duties can arise from intended use, impact treatment, contract, or law. The control requires the organization to determine necessary information rather than assuming one universal disclosure.

A.8.3 External reporting

Despite its title, this control is often misread. It requires the organization to provide capabilities for interested parties to report adverse impacts of the AI system.

This is an inbound reporting capability. It might be a customer-support path, safety-reporting form, accessibility route, appeal or complaint process, partner channel, or regulator contact mechanism. The design should let relevant parties communicate adverse effects and should connect to triage, investigation, risk, and corrective-action processes.

It is not the control that mandates the organization to file every regulatory report or publish sustainability data. Reporting obligations from the organization to others are addressed by A.8.5 and applicable requirements.

A.8.4 Communication of incidents

The organization determines and documents a plan for communicating incidents to users of the AI system.

A useful plan identifies incident types, users, triggers, content, channels, timing, responsibilities, approvals, accessibility, and feedback. Legal deadlines may govern some incidents, but the control itself does not impose a universal 72-hour deadline or require disclosure to every regulator and member of the public.

Incident communication should provide enough information for users to respond appropriately while considering security, privacy, legal privilege, investigation integrity, and uncertainty. An initial notice may be updated as facts become clearer.

Clause 10.2, not Clause 10.1, addresses nonconformity and corrective action. An incident may trigger that process when a requirement was not fulfilled.

A.8.5 Information for interested parties

The organization determines and documents its obligations to report information about the AI system to interested parties.

Obligations can come from law, regulation, contracts, sector rules, customer commitments, certification arrangements, or the organization’s own policy. The organization identifies who needs what information, when, and in what form.

Possible information includes system purpose, limitations, performance, incidents, changes, impacts, assurance evidence, or conformity statements. Public registry filing and environmental reporting can be obligations in a particular context; A.8.5 does not make them universal.

A.6.2.7 and A.8.2 compared

A.6.2.7 requires the organization to determine technical documentation needed for relevant categories of interested parties and provide it appropriately. A.8.2 focuses on necessary information for users. They can overlap.

It is inaccurate to describe A.6.2.7 as purely internal and A.8 as purely external. A.6.2.7 explicitly contemplates users, partners, supervisory authorities, and other relevant categories.

Transparency and confidentiality

Appropriate transparency does not mean disclosing everything. For example, publishing exact guardrail rules can enable attacks, while withholding known safety limitations can expose users to harm. The organization balances information needs with confidentiality, privacy, security, intellectual property, and applicable reporting duties.

Example

A company provides an AI document classifier to enterprise customers:

• A.8.2 information tells customer users the intended document types, supported languages, confidence interpretation, limitations, and reporting route.
• A.8.3 provides a channel to report adverse impacts such as recurring misclassification of accessibility requests.
• A.8.4 documents how the company will notify users about an incident affecting classification integrity.
• A.8.5 identifies contractual, legal, and regulator-reporting obligations and records how they are met.

A public annual carbon report might be valuable or legally required for that company, but it cannot be attributed automatically to A.8.3.

Connection to Clause 7.4

Clause 7.4 establishes the broad communication process: what, when, with whom, and how. A.8 applies that logic to AI-system users, adverse-impact reporting, incident communication, and interested-party obligations.

Accurate control map

• A.8.2: system documentation and information for users
• A.8.3: external reporting capability for adverse impacts
• A.8.4: incident communication plan for users
• A.8.5: information-reporting obligations to interested parties