What ISO 42001 A.8.5 asks you to determine and document
A.8.5 asks the organization to determine which obligations it has to report information about its AI systems to interested parties, and to document them. Interested parties can include regulators, customers, business partners, users and the public. The control does not ask you to publish anything by itself. It asks you to know, in writing, which reports you owe, to whom, and what each one must contain, so that an assessor can trace each obligation to its source and to the process that meets it. A.8.5 is one of four controls under objective A.8, alongside A.8.2 on documentation for users, A.8.3 on external reporting and A.8.4 on communicating incidents. Those controls describe how information is produced. A.8.5 is the register that says which information flows are required in the first place.
The starting point is clause 4.2 of ISO/IEC 42001, which requires the organization to understand the needs and expectations of interested parties. A.8.5 builds on that work. A compliance lead should be able to list each interested party, the AI systems that matter to it, the rule or commitment that creates the reporting duty, the content and frequency expected, and the owner who delivers it. Typical sources include regulator notification rules, contract clauses with customers, public transparency commitments and sector guidance. Each entry should name the document it came from, so a later change can be traced back to its source.
This is harder than it looks because the obligations are spread across contracts, regulators and public commitments, and they change. A customer contract signed two years ago may promise quarterly model change notices that nobody still tracks. A regulator may add a reporting form, or an AI system may move into a new risk category that brings new duties. Before an assessor visits, confirm with legal and account owners that the register is complete, record the date of the last review, and assign someone to re-check it when contracts renew or regulations change. Ask any implementation partner to show how the register is kept current, and confirm that the organization, not the partner, owns the final list of obligations.
Which AI systems, interested parties and obligations fall under A.8.5
A.8.5 only has work to do once the organization knows which AI systems it has put in scope and who is owed information about them. The cards below cover the decisions that set that boundary, and the statement of applicability under clause 6.1.3 is where the outcome must be recorded and justified.
AI systems inside the AIMS scope
Start with an inventory of every AI system the organization provides, deploys or relies on, then decide which ones sit inside the AI management system boundary. A system excluded from scope generally creates no A.8.5 obligation for that system, so the exclusion needs a written reason. Check whether systems built by suppliers, embedded in purchased software, or used only internally are captured. Ask which teams can add AI features without passing through a review gate.
Regulators as reporting recipients
Regulators are the interested party most likely to require reporting that the organization cannot choose. Map every regulator whose rules touch the AI systems in scope, including sector supervisors and data protection authorities, and record the report type, trigger and deadline each one sets. Where a regulator requires information that the organization has not yet produced, that gap belongs in the A.8.5 analysis. Confirm each requirement against the regulation text rather than relying on a summary.
Customers and contractual reporting duties
Customer contracts, data processing terms and service level commitments often require disclosure about AI use, model changes, or performance issues. List each contract clause that asks for information about an AI system, and note the notice period and content it requires. Contract duties are easy to miss because they sit in procurement files rather than governance documents. Check whether account managers have promised disclosures that no document records.
Users, the public and voluntary commitments
Users, the public and affected groups may be owed information through published AI principles, transparency statements or marketing claims. A voluntary commitment can still create exposure if the organization publishes it and then does not meet it. Review public statements against actual system behavior, and identify which commitments the organization has chosen to make. These items should be recorded as voluntary so the reader can tell them apart from legal duties.
Supplier-originated information flows
When an AI system depends on a model, dataset or service from a supplier, some information the organization must pass on may originate with that supplier. Identify which supplier notices, model change announcements or vulnerability disclosures feed into reporting you owe downstream. Confirm in each supplier agreement who is responsible for passing that information and how quickly. Gaps often appear where the organization assumes the supplier will report and the supplier assumes the customer will.
Statement of applicability entries for A.8.5
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. An A.8.5 entry should name the obligations identified, the source of each (law, contract or voluntary), and the owner who maintains the list. Excluding A.8.5 is hard to defend when any reporting obligation exists for an in-scope system. Ask your certification body how it expects exclusions to be justified before finalizing the document.
How an assessor tests A.8.5
This table sets out each step an assessor takes to test A.8.5, the evidence requested for it, and the findings that most often appear. Read it as a checklist for your own readiness review, since each row shows what the assessor will ask to see and where organizations usually fall short.
| Test step | What the assessor checks | Common finding |
|---|---|---|
| Confirm the register exists | A documented register of interested parties and the reporting obligations owed to each, with an owner and a version history | Register is undated or has no named owner, so the assessor cannot tell whether it reflects current obligations |
| Trace obligations to clause 4.2 | Each obligation links to a documented need or expectation of an interested party, such as a regulator, customer or the public, identified under clause 4.2 | Obligations are listed with no recorded input from clause 4.2, so their origin cannot be shown |
| Check coverage across products | Every AI system in the inventory is mapped to the obligations that apply to it, including systems built on third-party models | Obligations are missing for one product line or for an AI feature added after the register was last reviewed |
| Sample AI systems | For selected systems, the assessor follows the obligation to the reporting artifact, such as a notice, disclosure, or customer update, and confirms it was applied | Sampled system has a documented obligation but no record that the report was prepared or sent |
| Test timeliness of reports | Reports were issued within the period the obligation sets, and the organization can show the dates of issue and recipient | Reports go out late or without a dated record, so timeliness cannot be verified |
| Verify documented triggers | Each external report traces to a written trigger, such as a defined event, threshold or request, and an approver | Reports sent without a documented trigger or approver, so the organization cannot explain why they were issued |
| Review change control | Changes to the register, such as new regulators or contract terms, pass through a documented review and are recorded | Register is updated informally by email, with no record of who changed what or when |
Steps to determine, document and meet AI reporting obligations
This sequence turns A.8.5 from a general intent into a documented register of who must receive information about each AI system, why, in what form and on what trigger. The output is a set of owned, reviewed obligations that the organization can show an assessor and act on when a reporting event occurs.
Inventory interested parties from clause 4.2
Start from the needs and expectations of interested parties that clause 4.2 requires the organization to understand. List every party that may need information about your AI systems, such as regulators, customers, deployers, data subjects, suppliers, insurers and the public, and record how each one came to be on the list. Legal, product, customer success and privacy staff should review the list together. The step is complete when the inventory is approved by the AI governance owner and each entry names the function that maintains the relationship with that party.
Identify obligations for each party and system
For each interested party, determine which AI systems are in scope and what information the party is entitled to or required to receive, such as performance limits, incident notices, impact findings or change notices. Work through each combination of party and AI system in a matrix so that gaps are visible. Confirm the scope of each AI system against the inventory and the impact assessments under A.5. The output is an obligation matrix that shows which party receives what, for which system, and where no obligation was found.
Record the source of each obligation
Every obligation needs a traceable origin. Record whether it comes from a law or regulation, a contract or customer commitment, a supplier term, a published policy, or an internal decision. For external sources, note the document, the provision and the version you reviewed, and ask legal counsel to confirm the reading. Obligations without a source should be marked as voluntary so that they are not mistaken for mandatory duties. The check is that an assessor can pick any obligation and find its origin within a few minutes.
Assign owners and reporting triggers
Name one accountable owner and one backup for each obligation, drawing on the roles defined under A.3. For each obligation, define the trigger that starts the reporting duty, such as a material change to the model, a new deployment context, a complaint pattern, a regulator request or a contractual threshold. Write the trigger as a condition a person can test, not as a general expectation. The step is complete when every obligation in the matrix has an owner, a backup and a trigger that is documented and accepted by the owner.
Build the report templates
Create a template for each recurring or trigger-based report, covering the AI system identifier, the recipient, the information provided, the date, the approver and the evidence reference. Store templates in a controlled document repository with version history so changes can be traced. Align the content with the system documentation prepared under A.8.2 and the incident communication plan under A.8.4 so that the organization does not give different facts to different parties. The output is an approved template set with a named approver for each template.
Run a first reporting cycle
Test the register by running one full cycle end to end. Choose a real or clearly labeled illustrative trigger, follow the obligation through the assigned owner, the template and the approval, and send or file the report as the process directs. Record every step, including delays and questions, because these show where the process fails in practice. Retain the sent report, the approval and the timestamps as evidence. The cycle is complete when the owner signs off the record and the gaps found are logged as corrective actions.
Set a review cadence and retain evidence
Agree a review cadence for the register with the people who own the obligations, and add an out-of-cycle review when an AI system changes scope, a new party is identified or a regulation is updated. At each review, confirm that parties, obligations, owners, triggers and templates are still correct, and record the decision. Keep the review minutes, the revised register and the evidence of reports sent so that the internal audit and management review under clause 9 can test the process. The output is a dated, approved register with a recorded review history.
How A.8.5 connects to A.8.2, A.8.3 and A.8.4
A.8.5 is the register that decides what must be told to whom. It sits in the A.8 family beside A.8.2 System documentation and information for users, A.8.3 External reporting and A.8.4 Communication of incidents. Those three controls describe what is communicated: the information users need, a way for outside parties to report adverse impacts, and a plan for telling users about incidents. A.8.5 asks the organization to determine and document its obligations to report information about the AI system to interested parties such as regulators, customers or the public. In practice, the A.8.5 record is the list that the other three controls draw from. Before the organization can write a user guide, open an external reporting channel or draft an incident notice, it needs a documented answer to who is owed what, in which form and on what timing, and that answer depends on the needs and expectations of interested parties that clause 4.2 asks the organization to understand.
The working test for the A.8.5 record is whether each obligation names an owner, a trigger, a recipient, a channel and a retained record. An obligation to a regulator usually has a fixed deadline and format, while an obligation to a customer may come from a contract clause that sits with the sales or legal team. Ask the legal, product and security owners to list every contract, regulation and public commitment that requires information about an AI system, then check each entry against the A.8.2 user documentation, the A.8.3 intake process and the A.8.4 incident plan. Any obligation with no matching procedure is a gap to close before an assessor finds it.
The NIST AI RMF to ISO/IEC FDIS 42001 crosswalk, contributed by Microsoft and hosted by the NIST AI Resource Center, maps AI RMF GOVERN 4.2 (teams document and communicate impacts) and GOVERN 4.3 and MANAGE 4.3 (incidents and errors communicated to relevant AI actors) to B.8.5, the implementation guidance for A.8.5. NIST notes that posting the crosswalk is not an endorsement, so treat the mapping as a starting point. Open the crosswalk yourself, confirm each row against the current wording of the AI RMF subcategories and of ISO/IEC 42001, and record in your own statement of applicability and evidence index which entries you accept. Do not rely on a summary, including this one, for the final mapping.
Evidence that satisfies A.8.5 and how to keep it current
The obligations register is the core artifact for A.8.5. It is the documented list of every obligation to report information about an AI system, with the party owed the information, the trigger, the content required, the deadline or frequency, the channel and the accountable owner. An assessor will usually start here and then sample entries against the sources that created them, so each row should cite its origin.
- Entry per obligation: Record one row for each reporting duty, including duties that come from regulation, customer contracts, public commitments and internal policy.
- Trigger and content: State what event or schedule causes the report and what information must appear in it.
- Named owner: Assign one accountable role to each row, not a team alias, so the owner can be asked to confirm it.
- Source reference: Link each row to the clause, contract section or policy paragraph that created it.
- Review date: Record when the row was last confirmed against its source.
Keep the register in a controlled wiki or document system where each change is versioned and owners can edit only their own rows. Confirm with your certification body how often it expects the register to be reviewed.
The interested-party analysis shows how the organization identified who is owed information about its AI systems. Clause 4.2 requires the organization to understand the needs and expectations of interested parties, and A.8.5 depends on that understanding because it decides which reporting obligations apply. Regulators, customers, affected individuals, suppliers, the public and internal governance bodies may all appear, each with different information needs.
- Party list: Name each interested party or group and the AI systems that affect it.
- Stated needs: Record what each party has asked for or is entitled to receive, with the source.
- Gap notes: Identify parties whose needs are unclear and the action to confirm them.
- Decision record: Show why a party was included or excluded and who approved that decision.
- Refresh trigger: Define events that require a new analysis, such as a new AI system, a new market or a new regulatory notice.
The analysis changes as systems and customers change. Keep prior versions so an assessor can see how the list evolved between audits.
Contract and regulatory clause extracts prove that an obligation exists and where it came from. An assessor testing A.8.5 will often ask for the exact wording that creates a reporting duty, not a summary written by the team. Extracts should be short, accurate and tied to the document version they came from.
- Verbatim extracts: Copy the relevant clause text, with the document name, version and date.
- Obligation mapping: Connect each extract to its row in the obligations register.
- Amendment tracking: Record when a contract was amended or a regulation changed, and which rows were updated as a result.
- Legal review: Note who reviewed the interpretation and when, if counsel confirmed it.
- Access control: Restrict editing of the extract library to the compliance or legal owners, and allow read access to auditors.
To keep extracts current, schedule a check whenever a customer contract is renewed or a regulatory text is updated. Confirm with counsel which sources are authoritative in your jurisdiction.
Report templates show what the organization will say when a reporting obligation is triggered. Issued report records prove that reports were actually sent, when, to whom and with what content. Auditors usually test both: a well-written template with no issued records suggests the process has never run, and issued records without templates suggest reports are ad hoc.
- Template library: Maintain one template per obligation type, with fields that match the register entry.
- Issue log: Record each report with its date, recipient, approver, channel and the version of the template used.
- Evidence of delivery: Keep the transmission record, such as a sent message, portal receipt or signed letter.
- Follow-up tracking: Log questions or corrections received from the recipient and how they were answered.
- Negative assurance: Where a scheduled report was not required in a period, record that decision so the gap is explained.
If no reports have yet been issued, say so in the record and describe the dry run or tabletop exercise used to test the template. Confirm the retention period for issued records with your legal team.
Change history proves that the other four artifacts are maintained, not just created once for the audit. Version control records what changed, when and by whom, and role-based access shows who was permitted to change each artifact. Together they let an organization demonstrate that named owners reviewed and updated the evidence between audits.
- Version history: Use a wiki or document system that keeps every revision and allows comparison and rollback. XWiki, for example, records each change to a page with its author and time.
- Role-based permissions: Limit editing to the owner of each register row or template. BookStack, for example, derives user abilities from assigned roles and allows overrides at shelf, book, chapter or page level.
- Review log: Record periodic confirmations by owners, even when nothing changed.
- Change ticket link: Connect material changes to the business or regulatory event that prompted them.
- Owner handover: Document reassignment of ownership when people leave a role.
Check that your chosen tooling can export history for an auditor and that the role model matches your actual approval chain before you rely on it.
How open-source wiki and compliance tools hold the register
The obligations register for A.8.5 needs three things from its tooling: a record of who changed each entry and when, a way to stop unauthorized edits, and a link from each obligation to the framework it comes from. Open-source tools can cover each of these, but none of them decides what the organization must report. That decision stays with legal, compliance and the AI system owners. Start by choosing where the register lives, then confirm that the tool keeps the history an assessor will ask for. XWiki is a practical home for the narrative register because it keeps every change to a page under version control, recording what changed, when and by whom. Users can compare any two versions and roll back to an earlier one. Ask the assessor which version history they will accept as evidence, and confirm with your team that XWiki's history meets your retention rules. Check the license before you deploy: XWiki is licensed under LGPL-2.1-or-later, and your legal team should confirm that this fits how you plan to distribute or modify it.
BookStack (MIT) can control who edits the register. Its user abilities come from the roles assigned to each user, and permissions can be overridden per role at the shelf, book, chapter or page level. A workable pattern is to let AI system owners edit their own entries, let compliance reviewers approve changes, and make the register read-only for everyone else. This is an illustrative setup that you should test against your own role model. Confirm that BookStack's role and permission model matches your separation of duties before you rely on it for evidence of controlled access. CISO Assistant (AGPL-3.0-only) takes a different approach. It ships more than 200 frameworks, including ISO 27001, NIST CSF, SOC 2, PCI DSS, NIS2, DORA and GDPR, and runs assessments with automatic mapping between frameworks. Confirm whether it includes ISO/IEC 42001 in your installed version, since the framework list may not match what you need, and check that any mapping is one your compliance lead has reviewed. The AGPL-3.0-only license requires careful review if you modify the software and make it available to users over a network, so get legal sign-off before you use it in a customer-facing environment.
What meeting A.8.5 costs in money and effort
This table breaks down the cost components of meeting A.8.5 by who does the work, whether it is one-time or recurring, and what pushes it up or down. Use it to scope internal effort, compare quotes on equal terms, and decide which parts an outside partner should prepare. No price figures are given because none are supplied for this control.
| Cost component | Who is paid or who does the work | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Building the obligations register | Internal compliance and engineering staff, with optional outside support | One-time, then updated on change | Number of AI systems in scope and number of distinct reporting audiences |
| Legal review of reporting obligations | Internal or external counsel | One-time per jurisdiction, then on change | Number of jurisdictions, sector rules and whether regulators are named |
| Template and workflow build | Engineering, compliance and documentation staff | One-time, with periodic revision | How many report types exist and whether reports are generated from system records |
| Customer-specific reporting terms | Account, legal and compliance teams | Recurring per contract | Number of customers with bespoke terms and how often those terms change |
| Recurring report preparation | Operations and compliance staff | Recurring, on each reporting cycle or trigger | Reporting frequency and how much evidence is collected automatically |
| Evidence upkeep | Compliance owner and system administrators | Recurring | Version history, access records and how consistently reports are archived |
| Auditor sampling and review | Independent certification body (fee set by the auditor) | Recurring at each audit cycle | Number of reports sampled and completeness of the register and records behind them |
Where organizations fall short on A.8.5
Most gaps under A.8.5 come from obligations that exist in practice but are never written down as part of the AI management system. Each card below describes one gap an assessor is likely to probe, what it looks like in the records, and the check that closes it. Treat the list as a starting point for your own register rather than a complete inventory.
Obligations held only in contracts
Reporting duties often appear in customer agreements, data processing terms or supplier contracts, but never reach the AIMS. An assessor reviewing the obligations record will find nothing to test against, and the contract terms drift from the operating process. Compare each contractual reporting clause against the documented obligations list and record it with its source, owner and trigger.
No owner for regulator reporting
Regulator-facing reports about an AI system frequently have no named accountable role. Legal assumes engineering will send the notice, engineering assumes compliance will, and the deadline passes without action. Assign a single accountable owner and a deputy for each external recipient, and confirm that role appears in the responsibilities defined under A.3.2.
Reports issued without a trigger record
Information is sometimes shared with a customer or the public without a record of what prompted it or what was decided. When an assessor asks why a report was sent, or why one was not, the organization cannot show the reasoning. Keep a short trigger record for every outgoing report that states the event, the decision, the approver and the date.
Interested parties not reviewed after changes
The list of interested parties and their expectations is set once and rarely revisited, even after new markets, new customers or new regulations change who depends on the AI system. Clause 4.2 expects the organization to keep its understanding of these needs current, and that understanding determines which reporting obligations apply. Schedule a review of the interested parties list and trigger it on any material change to the system or its markets.
No link to the statement of applicability
A.8.5 may be implemented in practice but excluded or unexplained in the statement of applicability required by clause 6.1.3. That leaves the control's status ambiguous to an auditor. Confirm that the statement of applicability states whether A.8.5 applies, gives the justification, and points to the obligations record that supports it.
Who owns A.8.5, what a partner prepares, and what the auditor tests
Your organization owns A.8.5 in full. Only your team can decide which interested parties are owed information about each AI system, which obligations sit under contracts, regulation or public commitments, and what must be reported to each of them. Legal and compliance staff interpret those obligations, and the accountable owner signs off on the register. Whoever sends a report, to a regulator, customer or the public, is the one answerable for its accuracy.
- Obligation decisions: Confirm which parties are interested parties for each AI system, informed by the needs and expectations work under clause 4.2.
- Register approval: Approve the documented list of obligations, including who is told, what, how often and through which channel.
- Report content and sign-off: Review and authorize every outgoing report before it leaves the organization.
- Regulatory interpretation: Ask counsel to confirm how rules such as the EU AI Act apply to each system and jurisdiction.
- Ongoing upkeep: Update the register when systems, markets, contracts or rules change.
Before you start, confirm with your legal and compliance leads which named owner signs each obligation.
An implementation partner helps you build the machinery that makes A.8.5 work. Typical outputs include a draft obligations register, report templates, a routing workflow, records of who was told and when, and an evidence pack that shows the process runs. The partner prepares these materials for your review. It does not decide which obligations apply, does not give legal advice on your duties, and does not send reports on your behalf unless your written scope says so.
- Draft register: Structure a documented list of AI systems, interested parties and reporting duties for your owners to complete and approve.
- Templates and workflow: Build report templates and a routing path in your own tools, such as a wiki with version history.
- Evidence preparation: Collect records that show the process operated, such as approvals, dates and distribution logs.
- Testing support: Walk your staff through the process and help them answer assessor questions.
- Scope limits: Put the partner's role, deliverables and exclusions in writing before work starts, because most engagements are fixed-scope.
Ask any partner to name the outputs it will hand over and to confirm in writing that legal interpretation stays with your organization.
An independent certification body tests whether your management system meets ISO/IEC 42001, including A.8.5, and issues any certificate. ISO does not certify organizations, so the body is external to both you and any consultant who helped you prepare. Its auditors examine the register, the decisions behind it, and records that reports were made as the register requires. ISO/IEC 42006:2025 adds requirements for bodies certifying AI management systems on top of ISO/IEC 17021-1.
- Independence: The body cannot design the controls it audits, and a partner that helped build your register should not perform the audit.
- Evidence sampling: Auditors pick reports and check that they match the register and were approved by the named owner.
- Consistency checks: They compare the register with the needs and expectations you documented under clause 4.2.
- Accreditation: Confirm the body holds recognized accreditation, since accreditation of certification bodies is voluntary.
- Findings: Expect nonconformities to be raised and closed by your team, not by the consultant.
Before you engage a body, ask how it handles conflicts of interest and what it will sample for A.8.5.
Questions buyers ask about A.8.5 before hiring help
Can we build the A.8.5 reporting obligations register ourselves?
Yes, in most organizations the register is an internal task, because only the organization knows which regulators, customers, contract counterparties and public disclosure duties apply to its AI systems. Nothing in ISO/IEC 42001 requires an outside firm for this work. The organization owns the control, so it must decide the obligations, record who is responsible for each one and show that the list is kept current. Outside help is usually considered when the team lacks people who know the legal duties, when many AI systems are in scope, or when the register must be connected to the rest of the management system. Ask any partner to state which parts they prepare and which parts remain with your staff.
How long does it take to build the A.8.5 obligations register?
The duration depends on how many AI systems are in scope, how many interested parties have reporting expectations, and how much of the information already exists in contracts, policies and risk records. No standard duration applies, so treat any single figure you hear with caution. The work usually moves faster when an inventory of AI systems already exists and slower when obligations must be traced through contracts and legal advice. Ask for a written plan that lists the systems, the sources reviewed, the people who must approve each obligation and the points where legal review is needed.
What do legal and product teams need to contribute to A.8.5?
Legal teams must confirm which statutory, regulatory and contractual reporting duties apply, and product teams must explain what each AI system does, who uses it and what information those users or the public would need. Compliance or governance staff usually combine both views into a register that names the interested party, the obligation, the content to be reported, the trigger, the owner and the channel. Engineering may need to supply logs or metrics that support those reports. Plan these reviews early, because a register drafted without legal input often needs rework once contract terms and regulator expectations are checked.
Can an implementation partner issue the A.8.5 report or certificate?
No. A partner can help prepare the register, the supporting records and the evidence an assessor will review, but it cannot issue audit reports, attestations or certificates. Under ISO/IEC 42001, ISO does not certify organizations, and certification is performed by external certification bodies. Reports and certificates come only from an independent auditor or certification body. DeployOpen prepares systems, controls and evidence for compliance assessments and does not issue audit reports, attestations or certifications. Keep the implementer and the assessor separate so that the assessor can test the work independently.
How does A.8.5 relate to EU AI Act reporting duties?
A.8.5 is a management system control that asks the organization to identify and document the obligations it has to report information about its AI systems, so it can cover EU AI Act reporting duties where those apply to your organization. It does not replace the Act. Which duties apply depends on whether you are a provider, deployer or other operator, the risk category of each system and the information the Act requires. The European Commission has said that ISO/IEC 42001 helps set up an AI management system but does not match the AI Act's quality management system. Confirm the exact duties, deadlines and recipients with counsel before you write them into the register.
What drives the cost of A.8.5 work?
Cost depends mainly on the number of AI systems and interested parties in scope, the number of reporting obligations, the quality of existing records, and how much legal review is required. Your organization pays its own staff time for legal, product and compliance input, and it may pay an outside firm for scoping, drafting and evidence preparation. Costs recur when obligations change, when new AI systems are added or when the register is reviewed. Because DeployOpen does not publish a price list, ask for a written, fixed scope that names the systems, deliverables, roles and assumptions before work begins, and compare quotes against that same scope.
What evidence will an assessor ask to see for A.8.5?
An assessor will usually look for a documented list of reporting obligations, the interested parties behind each one, the process used to identify them, the owner of each obligation and records showing that reports were prepared and sent when required. Expect questions about how the register is reviewed and how changes in law or contracts are picked up. Ask your auditor which records they expect before you finalize the format, because assessors differ in how much detail they request. Keep the register in a version-controlled location so that the history of changes can be shown.
How DeployOpen prepares A.8.5 evidence
DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, and prepares the systems and records that show how AI reporting obligations are determined and met. The organization owns its obligations and its control statement, while an independent auditor or certification body issues any report or certificate.
How we scope
- Written scope lists which interested parties and reporting obligations the A.8.5 work covers, agreed before any work starts.
- Scope names the systems, document stores and owners that hold the obligation register and reporting records.
- Engagements are fixed-scope, and ongoing support is available as a retainer once the written scope is in place.
How we build
- We configure a self-hosted wiki with version history so each obligation register entry records changes, dates and authors.
- We set role-based permissions so owners of reporting duties can edit entries while assessors get read-only access.
- We map the obligation register to the A.8.2 to A.8.4 information controls and to any NIST AI RMF crosswalk mapping the client agrees to use.
How we hand over
- Deliverables include a documented procedure for determining reporting obligations and a register of the obligations identified.
- Handover covers the evidence set an assessor would ask for, such as dated approvals, version history and proof of submitted reports.
- Clients receive administrator instructions so their own staff can maintain the register after the engagement ends.
How we support
- Retainers can cover periodic review of the obligation register as regulators, customers or the public change expectations.
- Upgrades and backups of the self-hosted platforms can be included so records remain available for the assessment period.
- Clients should confirm with their auditor which evidence format and retention period they expect before handover.
