ISO 42001 Annex A.8.5: Determine AI Information Reporting Obligations
ISO 42001 control A.8.5 concerns determining and documenting obligations to report information about an AI system to interested parties. It focuses on what must be provided, to whom and under which conditions. A general willingness to be transparent does not establish that the organisation understands its actual reporting commitments.
What control A.8.5 requires in practice
Control A.8.5 asks the organisation to establish and write down what it is obliged to report about an AI system to interested parties. The control concerns obligations: what must be provided, to whom and when. It does not itself create a duty to publish anything. Annex B guidance notes that some jurisdictions require information to be shared with authorities, and that customers or regulators may need material within an appropriate timeframe. Examples include technical documentation such as data sets and verification records, descriptions of risk, impact assessment results, and logs or other system records. The organisation is expected to understand these obligations and make sure the right information reaches the right recipients. The outputs are a documented set of obligations with sources, owners and evidence, and records of how real requests were answered.
Identify the source of the obligation
Annex B.8.5 discusses information that relevant authorities or other parties may require, such as technical evidence, risks, impact results or system records. It emphasises appropriate recipients and timing. The guidance must be considered under clause 6.1.3(e), while implementation is tailored under B.1.
Different sources can create different obligations. A customer contract, a relevant authority's requirement and a voluntary public commitment should not be treated as interchangeable. Obtain appropriate specialist advice where interpretation is uncertain. The control itself does not create a universal duty to publish every technical record.
Why control A.8.5 matters to the business
Reporting promises are often scattered: a clause in a customer contract, a request from a regulator, a commitment in a tender. If nobody collects them, the business discovers them at the worst moment, when a deadline is already near and the evidence sits with a supplier. A documented obligations picture lets sales, legal and technical teams answer consistently and avoids promising material the company cannot produce. It also prevents over-sharing, because the recipient and the scope are agreed in advance. Auditors treat this control as a test of whether commitments made outside the AI team are visible inside it.
How to implement control A.8.5
Gather the commitments first, then make sure the evidence behind each one exists. A single, simple list that sales, legal and technical staff all consult is usually enough, and it works best when someone is responsible for adding new commitments the moment a contract or tender is signed.
- Search contracts, tenders, regulator correspondence and public statements for commitments about AI information.
- Record each obligation with its source, the information required, the recipient and any timing condition.
- Assign an internal owner for each and an approver for what is released.
- Match each obligation to existing evidence, such as technical documentation, impact assessments or logs, and note any gaps.
- Check that information held by suppliers can really be obtained before promising it to anyone.
- Agree how sensitive material is summarised or restricted for each audience.
- Trace one real request from receipt to response, and review the register whenever contracts or regulation change.
Illustrative software example: a customer requires evaluation evidence
A software provider agrees to supply an enterprise customer with evidence about an AI feature's evaluated use and limitations. At handover, the commercial team sends only a product brochure because it does not know which technical records are required.
The organisation documents the obligation, the relevant evidence and responsibility for preparing and authorising the response. It ensures the material relates to the delivered configuration and agreed use. A generic certification statement would not replace the promised evaluation information.
Illustrative manufacturing example: group reporting differs from local need
A manufacturer supplies AI-assisted inspection information to a customer under a defined agreement. A group-level report contains broad performance averages but omits the product variant relevant to that customer.
The organisation examines what the agreement actually requires and whether the evidence supports that scope. It identifies the correct recipient and any conditions on sharing. Providing more pages is not necessarily better if the information does not answer the obligation.
Connect obligations with available evidence
A practical obligations record can identify the source, required information, recipient, timing and internal owner. This is an optional format, not a prescribed ISO table. The purpose is to prevent a commitment from remaining isolated in a contract or specialist inbox.
Connect the obligation with technical documentation, impact-assessment records or other relevant evidence. Check whether the organisation can actually obtain information held by a supplier before promising to provide it.
Control disclosure appropriately
Information can be sensitive or subject to other obligations. Determine authorised access and suitable presentation while meeting legitimate reporting needs. A summary may be appropriate for one audience and insufficient for another.
Do not use confidentiality as an automatic reason to ignore a valid obligation, or transparency as a reason to disclose everything indiscriminately. The decision should consider the actual authority, purpose and information. Specialist review may be needed where requirements interact.
Evidence and common mistakes
The control calls for documented obligations. Evidence of implementation can show how a material request or scheduled report was handled, including the basis of the information provided. An auditor can trace a commitment into records and an authorised response.
Common failures include confusing inbound concern reporting with outward obligations, missing a relevant customer commitment and sending outdated technical evidence. Another is assuming that management-system certification establishes compliance with every reporting duty. Certification does not provide legal clearance or substitute for fulfilment of an actual obligation.
Frequently asked questions
Must all AI technical documentation be public?
No. Determine actual obligations and appropriate recipients. Public disclosure is not a universal outcome of this control.
Can contractual information commitments matter?
Yes. Relevant customer or other agreements can create obligations that need a clear owner and suitable evidence.
What if required evidence is held by a supplier?
Identify the dependency and obtain suitable arrangements. Do not promise information that the organisation cannot access or substantiate.
Turn an information commitment into a workable response
Discuss an AI information-reporting obligation with Sterling to scope governance, documentation and evidence coordination. Agreed support can include Effivity ISO & GRC automation software. Documented Information Management develops relevant control principles. Return to the information controls or the library.