A.5.3 Documentation of AI system impact assessments: evidence

What A.5.3 asks you to write down and keep for AI impact assessments

When an auditor or a customer asks for proof that you assess the impact of your AI systems, the question is usually simple: show me the record. A.5.3 is the Annex A control that asks for that record. It is about documenting the results of AI system impact assessments and keeping them for a defined retention period. It is not about how the assessment is carried out, which belongs to A.5.2 (the impact assessment process), and it is not about the substance of the analysis, which A.5.4 covers for individuals or groups and A.5.5 covers for societal effects. A team can run a careful assessment and still fail A.5.3 if the outcome is not written down, approved and findable later.

The typical failure is not a missing assessment. It is an assessment whose results exist only in a meeting, in someone's memory, or in a slide deck that was replaced. Results that cannot be retrieved, or that were overwritten when a model changed, leave you unable to show what was known at the time of a decision. The problem is common because outcomes are scattered across tickets, shared drives, email threads and presentations, and because many organizations never set a retention period. Confirm with your own records policy and your legal team what retention period applies to your AI systems, since the standard requires a defined period but leaves its length to you.

Clause 7.5 of ISO/IEC 42001 sets the general rules for documented information: how records are created, how they are updated, and how they are controlled. Apply those rules to every impact assessment record. Decide who approves each record and who may change it, keep a version history so you can show what changed and when, and store records in a location with access controls and backups. A practical first step is to list every AI system in scope, check where its latest impact assessment result lives today, and confirm that a named owner can produce it within a short, agreed time.

Which AI systems, teams and records fall under A.5.3

A.5.3 only works if the organization decides up front which AI systems and life cycle stages get a documented impact record, who owns each record, and how that decision is justified in the statement of applicability. The cards below cover the scoping choices that change the workload and the teams that hold the evidence.

Systems and life cycle stages in scope

Start with an inventory of AI systems that the organization provides or uses, then decide which ones trigger an impact record and at which stages. Development, deployment, operation and retirement can each change the likely consequences, so a record created at design may need updating after deployment. Check that the inventory lists the intended purpose, the affected people and the stage each system is in, because an assessor will sample systems and ask where their records are.

Third-party AI systems

Decide whether systems bought from vendors are covered. Even when the vendor performed its own assessment, the organization that deploys the system still needs to understand its impacts in its own context, such as the population it serves. Ask suppliers for the documentation they hold, record what you received and what you still must assess yourself, and note any gaps in the record.

Statement of applicability entries

Clause 6.1.3 requires a statement of applicability that lists the Annex A controls the organization needs and justifies each inclusion or exclusion. Record A.5.3 as included, with a reference to the register or procedure that holds the records, or document a justification for exclusion. An exclusion needs a sound reason, so an assessor will test whether the organization really has no impact assessments to document.

Record owners and approvers

Name the role that owns each impact record, usually the product or system owner, and the role that approves it, such as a governance or risk committee. Separate the people who build the system from those who approve the assessment of its impacts where the organization can. Keep a list of owners with their responsibilities, since the assessor will ask who signed off on a given record and whether that person had authority to do so.

Legal and privacy teams

Legal, privacy and compliance teams hold context that shapes the record, including applicable regulations, data protection obligations and contract terms with customers. Involve them when deciding scope, because a system that processes personal data or serves regulated users may need records that a purely technical review would miss. Agree who provides which inputs and how often they review the record.

Where the records are held

Decide which system stores the records, how access is controlled and how changes are tracked. The records hold personal, commercial and sometimes sensitive operational information, so limit access by role and keep the storage inside the organization's own environment. Confirm with the platform owner that version history, retention settings and access rules can be shown to an assessor on request.

How an assessor tests A.5.3 and what they ask to see

This table walks through the steps an assessor usually takes when testing A.5.3, what each step checks, and the evidence they ask you to produce. Read it as a preparation checklist: most findings come from records that exist but cannot show who approved them, which version was in force, or whether they were kept for the period the organization defined.

Test step	What the assessor checks	Evidence they ask to see
Select a sample of assessments	Picks several AI systems from the inventory, including recently changed or high-impact ones, and asks for the impact assessment records behind each	Current AI system inventory, list of assessments with dates and system names, and the scope statement for each sampled system
Check results are recorded	Confirms each record states the results of the assessment, including identified impacts, their likelihood and severity, and the conclusions reached	Completed assessment records, not drafts or blank templates, with results written out in the record itself
Check dates and version history	Looks for an assessment date, a revision history and a link between the record and the version of the AI system it describes	Dated records, change log or version history showing what changed, when and by whom, and the system version each assessment covers
Check approval	Confirms a named role or person approved the record before it was relied on, and that the approver had authority to do so	Approval records, sign-off forms or workflow logs with approver names, roles and dates, and the delegation or role definitions that give them authority
Check updates after change	Tests whether records were revisited when the AI system, its data, its use or its context changed	Trigger log linking system changes to reassessments, and re-approved records for the changed systems
Check retention settings	Compares the retention period the organization defined with the settings applied to the repository and any backups	Written retention schedule, system configuration showing retention or archive rules, and backup retention settings
Check disposal and gaps	Looks for records removed before the defined period ended, and whether deletions were authorized and logged	Deletion or disposal logs, access logs for the repository, and approval records for any early disposal
Common findings	Undated records, missing or unnamed approvers, records that do not match the deployed system version, and records deleted before the retention period ended	Ask your team to check the sampled records against these findings before the assessor does

How to set up the A.5.3 record step by step

The sequence below turns A.5.3 into a working record set: a template, a defined retention period, named approvers, controlled storage, a first run of real assessments and a review trigger. Each step ends with something you can hand to an auditor.

Define the record template
Write a single template that every AI system impact assessment must use. It should capture the system name and version, its intended purpose and scope, the assessment date, the people who carried it out, the impacts identified for individuals, groups and society, the risk treatment decisions, and any residual risks the organization accepted. Link each entry to the assessment it summarizes, so the record can be traced back to the underlying work. The output is an approved blank template with field definitions and a short instruction page for the teams that will complete it. Confirm the fields against the wording of A.5.2, A.5.4 and A.5.5 in your own copy of the standard, since those controls set what the assessments must cover.
Set the retention period and its basis
Decide how long each completed record is kept and write down why that period was chosen. A.5.3 requires retention for a defined period, so the figure must be stated, not implied. Base it on the obligations that apply to your organization, such as contractual terms, sector rules, the EU AI Act where it applies, and your own legal review. Record the period, the justification and the trigger that starts the clock, for example the date the AI system was retired. The output is a retention schedule entry for AI impact assessment records, signed off by legal or compliance. Ask your legal team to confirm the period against each jurisdiction and customer contract in scope.
Assign approvers and their authority
Name who reviews and approves each record before it is final. Approval usually sits with the accountable owner of the AI system and a second reader from risk, compliance or a privacy function, so one person does not both prepare and sign off the record. Document the roles in the A.3 responsibilities already assigned, and state what an approver checks: completeness, accurate scope and whether the risk treatment matches the findings. The output is an approval matrix that names roles, alternates and the evidence of each sign-off, such as a dated approval in the record itself.
Set up controlled storage and access
Choose one repository for AI impact assessment records and restrict who can read, edit and delete them. A wiki or document system with version history suits this need, because every change should show what changed, when and by whom. Set permissions by role, give auditors and approvers read access, and limit write access to the record owners. Confirm that the platform can keep prior versions and restore them, and that deletion is limited to the retention rules you set in the earlier step. The output is a configured repository with a documented access model and a test showing that an edit appears in the version history.
Run the first records through the process
Complete a small number of real impact assessments through the template, the approval matrix and the repository. Use the first cycle to find gaps: fields nobody can fill, approvals that stall, or assessments that do not link to their results. Adjust the template and instructions based on what the teams hit, and keep a short log of changes. The output is a set of completed, approved records and a change log that explains each adjustment. Keep this log, because an assessor will ask how the process was tested before it was used at scale.
Schedule reviews after material changes
Set a rule that a record is reopened when the AI system changes in a way that affects its impacts, such as a new model version, a new data source, a new user group or a changed intended purpose. Also set a periodic check that confirms each record still reflects the system in operation. Each update should go through the same approval steps and keep the earlier version. The output is a written review trigger list and a review calendar owned by a named role. Ask your internal audit or compliance function to confirm that the trigger list matches the change process used for AI systems.

What a complete impact assessment record contains

A complete record for an AI system impact assessment under A.5.3 has to let an assessor trace one assessment from the system it covers to the decisions taken about it. Start with the system identifier and version, the assessment date, and the application scope, including the intended purpose, the populations and contexts the assessment covers, and any uses explicitly excluded. Without a fixed system version, a record can describe a model that no longer runs in production, so tie each record to the version number your change management process actually uses. Then record the results: the potential impacts identified on individuals, groups and society (the subjects of A.5.4 and A.5.5), the likelihood and severity you assigned, and the risks that followed from them. Each risk should have an owner who can explain it in a review meeting.

Next, document residual risk and its acceptance. For every risk that remains after mitigation, the record should state the residual rating, the mitigations relied on, the person or body who accepted the residual risk, and the date of acceptance. Link each mitigation to the control or design change that implements it, so a reviewer can check it against the life cycle records in A.6. Also record external feedback received on the system's impacts, such as complaints, user research findings or input from affected groups, together with what was changed in response or why nothing was changed. Finally, keep a version and approval history showing who drafted, reviewed and approved each revision and what changed between versions. The NIST AI RMF to ISO/IEC FDIS 42001 crosswalk, published by NIST's AI Resource Center with Microsoft as contributor, maps several AI RMF subcategories, including MANAGE 1.4 on negative residual risks, to B.5.3. Treat that mapping as a checklist to compare against your own record, not as proof that your documentation meets the control. Confirm the mapping's status and wording with NIST and your certification body before you cite it.

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

An assessor testing A.5.3 looks for a documented record for each AI system, proof that the right people approved it, and a retention rule the organization actually follows. The cards below cover the artifacts that show this, and the review triggers that keep them accurate between audits.

Standard record template

A single template fixes the fields every impact assessment record must contain, such as the system name, purpose, application scope, affected groups, identified impacts, residual risks and the assessment date. Using one template lets an assessor compare records across systems and confirm none were skipped. Check that the template names its owner and that its version is recorded, since a changed template can make older records look incomplete.

Completed records per AI system

Each AI system in scope needs its own completed record, not a general statement covering the whole portfolio. The record should reflect the system as it currently operates, with its intended purpose and the impacts documented against that purpose. Confirm that every system listed in the AI inventory has a record and that none is marked complete when its assessment is still open.

Retention schedule

The retention schedule states how long assessment records are kept and where they sit in storage. A.5.3 asks for retention over a defined period, so the organization should set that period in writing and apply it to every record. Confirm the period with legal and any sector regulator, and check that backups and archived copies follow the same rule.

Approval records

Approval records show who reviewed each assessment, when they signed it off, and which decision they made. Named approvers with a defined role, such as the system owner plus a governance lead, give an assessor evidence of accountability. Check that approvals are dated after the final content, because an approval that predates the last change undermines the record.

Version history and change logs

Version history records each change to an assessment, including what changed, when, and by whom. Version control matters most when a model, training data source or deployment context changes, because the old record then describes a system that no longer exists. Set review triggers that force a new version after a model update, a material data change, a new user group or a new jurisdiction, and keep the previous versions available.

Disposal logs

Disposal logs record when an assessment reached the end of its retention period and how it was destroyed or archived. Without them, an assessor cannot tell whether a missing record was deleted on schedule or lost. Log the record identifier, the date, the approver of the disposal and the method used, and confirm that no record is disposed of while an incident, complaint or regulator request is still open.

What meeting A.5.3 costs in money and effort

This table breaks down the cost and effort components of keeping A.5.3 impact assessment records, who is paid for each, whether it is one-time or recurring, and what drives it up. Use it to build a quote request and to see where self-hosted open-source tooling removes license spend, though staff time and review effort remain.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it
Tooling or licenses	Software vendor or internal platform team	Recurring if commercial per-seat or per-module licensing applies	Number of users, modules and integrations. Self-hosted open-source wiki and governance tools can remove the license line, but hosting and administration remain
Setup of the record structure	Implementation partner or internal governance lead	One-time	Number of templates needed, number of AI systems in scope, and whether existing impact assessment records are migrated
Internal time to write and approve records	Product owners, system owners, legal, privacy and risk staff	Recurring with each assessment cycle	Number of AI systems, depth of each assessment and number of approvers named in the record
Evidence upkeep and version history	Records owner and platform administrator	Recurring	Change frequency of AI systems, retention period set by the organization and how many versions must be kept
Periodic review and updates	Accountable owner and approvers	Recurring	How often the organization reviews records and how many triggers, such as model changes or new data sources, require an update
External review or advisory input	Independent consultant or specialist reviewer, if engaged	Usually one-time per readiness exercise, sometimes recurring	Scope of records reviewed, whether the review covers all systems or a sample, and the consultant's written scope
Auditor sampling and testing	Independent auditor or certification body	Recurring at each audit cycle	Number of AI systems selected for sampling, number of records per system and how many updates occurred during the period
Remediation after audit findings	Internal staff and any engaged partner	One-time per finding	Gaps in approval, retention or update records found during the audit

Who owns the A.5.3 record, who can prepare it, and who assesses it

Your organization owns the A.5.3 record. The people accountable for the AI system decide what the impact assessment concludes, which risks are accepted, and when the record is approved or re-approved. Those decisions and their approvals must come from named staff inside your organization, because an assessor will ask who made each judgment and whether that person had the authority to make it. Your team also writes the substance of the record, since only people who understand the system's purpose, users and data can describe its real effects.

Decision ownership: Name an accountable owner for each AI system's impact assessment, usually the business or product owner, with the security, legal or privacy lead as a required reviewer.
Approval authority: Define who signs off the initial record and who may approve material updates, and write those rules into your AI governance procedure.
Content authorship: Staff who operate or build the system should write the description of intended use, affected groups and known limitations.
Retention decisions: Set the retention period for records and assign someone to enforce it, including what happens when a system is retired.
Change triggers: Decide which events, such as a model change or new use case, force a review and who is responsible for starting it.

Check that every approval in the record traces to a named person with a role description that supports the decision.

Common A.5.3 gaps and how to close them

Most A.5.3 findings come from records that exist but cannot be relied on: no retention rule, no named approver, no link to what changed later, or results stored where nobody can find them. The cards below cover five gaps an assessor is likely to test, each with a closing action your team can take before the audit.

No defined retention period

A.5.3 asks the organization to keep impact assessment results for a defined period. Many teams keep records indefinitely by default, or delete them when someone remembers. Set a retention period per assessment type, state it in the procedure, and record the date each record becomes eligible for disposal. Check that the period is tied to the life of the AI system, including after decommissioning, so that an assessor can see the rule applied to a retired system.

Records without named approvers

An impact assessment record without an approver shows who wrote it but not who accepted the impact conclusions. Add a sign-off block to every record that names the role accountable for the assessment, the person who holds that role, the date of approval and the version approved. Confirm that the approver has authority over the system's deployment decision, since an approval by someone without that authority will not carry weight in review.

Results not linked to later changes

An assessment done at design time can go stale after a model retraining, a new data source or a change of use. Without a link between the record and later changes, the organization cannot show that the assessment still describes the system in operation. Add a change trigger to the assessment procedure that reopens the record when the model, data, intended purpose or user population changes, and record each update as a new version with a reference to the change that caused it.

Records stored where they cannot be retrieved

Assessment results kept in individual inboxes, personal drives or unindexed folders fail when an auditor asks for the record of a specific system. Store every record in one controlled repository with consistent titles, owners and system identifiers, and set access so that the reviewers who need the record can find it without help. Test retrieval by picking one system at random and timing how long it takes to produce its current and prior assessments.

Assessments done but not documented

Teams often run impact discussions in meetings, chats or design reviews and never write down the outcome. A.5.3 requires the results to be documented, so an assessment that happened but left no record cannot be evidenced. Make the template the place where the discussion is captured, require it to be completed before the system is approved for deployment, and sample recent deployments to confirm that each one has a completed record.

Questions buyers ask about A.5.3 documentation

How much effort does A.5.3 documentation take?

The effort depends on how many AI systems are in scope and how many impact assessments already exist. A.5.3 asks for the results of each AI system impact assessment to be documented and kept for a defined retention period, so the work is mostly collecting, structuring and approving records that the assessment process already produces. Teams with one or two systems and a working assessment template usually face a modest documentation load. Organizations with many systems, several business units or assessments that live in email threads and slide decks face much more, because each record must be reconstructed before it can be controlled. Ask any provider to estimate effort per system and per assessment, and to state which assumptions the estimate depends on.

How long does it take to set up A.5.3 documentation?

No researched timeline for this control is available, so treat any duration as something to confirm in a written scope. Setup generally covers agreeing a record template, defining the retention period, creating a register of assessments, and moving existing results into that structure. Duration depends on the number of systems, the state of existing records, and whether approvals and version control tools already exist. Clause 7.5 of ISO/IEC 42001 sets the general rules for creating, updating and controlling the records the standard requires, so the template should reflect those rules from the start. Ask for a milestone plan that separates template design, back-filling of historical records and first approval cycle.

What does the work need from the team?

The work needs input from the people who run AI systems, the people who ran the impact assessments, and the approvers who accept the results. Engineers supply technical facts about the system and its data. Risk, legal or privacy staff confirm the impact findings and the residual risks. Management or a designated owner signs off on the final record. Someone also has to own the document store, decide how versions are controlled and make sure retention rules are applied. Expect the most time to go into resolving unclear ownership and missing sign-offs, not into formatting. Confirm these roles before work starts so that approval does not stall at the end.

Can our own team do A.5.3 documentation in-house?

Yes, many organizations maintain their own AI impact assessment records, and the organization always owns its controls and its evidence. An in-house team can define the template, run the register and apply the approval workflow without outside help. Outside help is useful when the team lacks time, when records are scattered across tools, or when a platform must be configured to hold versioned, access-controlled records. An implementation partner such as DeployOpen can prepare systems and evidence in the client's own infrastructure, but it does not approve impact assessments or issue any report. That judgment and sign-off stay with the organization, and any independent assessment is performed by an external auditor or certification body.

What drives the cost of A.5.3 documentation up?

Cost is driven mainly by volume, condition of existing records and the number of approvals. Costs fall into one-time work, such as designing templates, migrating historical assessments and configuring a document platform, and recurring work, such as reviewing records, updating them when systems change and keeping the retention schedule. More AI systems, more assessments per system and more reviewers each add effort. Records held in unstructured formats cost more to bring under control than records already in a register. Ask any quote to separate one-time and recurring items, to list which systems and assessments are included, and to state who is responsible for each approval step.

How does A.5.3 documentation differ from the impact assessment itself?

The impact assessment is the analysis: it examines how an AI system could affect people, groups and society. A.5.3 is about the record of that analysis. It requires the results to be documented and retained for a defined period, so the assessment can be reviewed, updated and shown to others later. Related controls cover the process (A.5.2), impacts on individuals or groups (A.5.4) and societal impacts (A.5.5). A complete assessment with no retained record, or a retained record with no traceable assessment behind it, will not satisfy the control. Clause 7.5 governs how the record is created, updated and controlled. Documentation tooling can hold the record, but it cannot perform the analysis.

Which tools can hold A.5.3 records under version control?

Tools that keep version history and access controls are the usual starting point for impact assessment records. XWiki is licensed under LGPL-2.1-or-later and keeps every change to a page under version control, recording what changed, when and by whom, with the ability to compare versions and roll back. BookStack is licensed under MIT and assigns user abilities through roles, with permissions that can be overridden per role at the shelf, book, chapter or page level. Confirm that the chosen tool meets your retention and approval requirements, since neither tool is configured for ISO/IEC 42001 out of the box. Ask the implementation partner to show how approvals, retention and access are set up in your environment.

Open-source tools that keep A.5.3 records

A wiki or document repository can hold each AI system impact assessment record, and the version history it keeps is what shows an assessor how the record changed over time. In XWiki, every change to a page is kept under version control, recording what changed, when and by whom, and any two versions can be compared or rolled back. That history matters for A.5.3 because an assessment result that was revised after deployment should show the earlier wording, the reason for the change and the person who made it. Confirm with your own configuration that page history is enabled for the space that holds these records and that no one can purge it.

Access control decides who can write a record and who can sign off on it. In BookStack, 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 practical design gives impact assessment authors edit rights on draft pages, restricts approval to a named governance role, and locks approved pages against further edits except by that role. Check that the people who approve assessments are not the same people who wrote them where your AI policy requires separation. The approval step itself, including the approver's name and date, still needs to be captured in the record.

CISO Assistant (AGPL-3.0-only) is an option when you need to track A.5.3 alongside other frameworks. It ships more than 200 frameworks, including ISO 27001, NIST CSF, SOC 2, PCI DSS, NIS2, DORA and GDPR, and it runs audits and compliance assessments with automatic mapping between frameworks. Use it to link each impact assessment record to the Annex A control, the evidence location and the review date, so one record can answer several questions. Confirm whether ISO/IEC 42001 is available as a framework in the version you deploy, and if it is not, decide whether to model the control manually. Tools hold the record, but they do not satisfy A.5.3 on their own: the organization must still define what the assessment contains, who approves it, how long it is retained and who decides when it is updated.

How DeployOpen prepares A.5.3 records in your environment

DeployOpen scopes, implements and prepares the A.5.3 record set, its workflow and the supporting evidence inside your own infrastructure, whether that is your cloud accounts, data center or air-gapped network. The work runs under a fixed written scope that names the AI systems covered, the impact assessments in scope, the templates to be built, the approval roles to be configured and the deliverables and dates agreed before work starts. Your organization keeps ownership of the controls themselves. Deciding which AI systems need an assessment, who signs off on residual impacts and how long records are kept are governance decisions that stay with your management, and the scope document should say so explicitly.

In practice, the engagement typically covers a record template that captures the assessment scope, the AI system version it describes, the methods used, the identified impacts and their treatment, the approver and approval date, and the review trigger. It also covers the wiki or document platform that holds those records, with version history enabled so that every change is attributable, and a retention configuration that matches the period your organization defines. Where a platform such as XWiki or BookStack is used, DeployOpen can configure it, but you should confirm with your own administrators how roles, permissions and backups are set in your environment before the scope is signed.

DeployOpen does not issue audit reports, attestations or certifications. Those are issued only by an independent auditor or, for ISO/IEC 42001, an accredited certification body, and ISO itself does not certify organizations. When you request a quote, ask for the deliverables to be listed as prepared records, configured tools and evidence packs, and ask the certification body you intend to use to confirm in advance what evidence format it will sample. Keeping the implementer and the assessor separate protects the credibility of the result and avoids a conflict in the audit.