Which ISO 42001 mandatory documents and records does an auditor expect to see?
When a customer or regulator points you to ISO/IEC 42001, the first thing an assessor checks is documented information under clause 7.5. The standard requires you to create, update and control the records it calls for, and several Annex A controls name specific documents: the AI policy (A.2.2), the results of AI system impact assessments (A.5.3), design documentation for each AI system (A.6.2.3), technical documentation for interested parties (A.6.2.7), event logs (A.6.2.8), and the internal audit and management review records that clauses 9.2 and 9.3 require. The statement of applicability, required under clause 6.1.3, sits alongside them as the record of which Annex A controls you adopted and why you excluded the rest.
The exact set is not the same for every organization. It depends on the AI systems you develop, provide or use, on your role for each one, and on the scope you set under clause 4.3. A provider of a customer-facing model will hold far more design and technical documentation than a company that only uses a third-party AI tool. Before you answer a questionnaire or accept a certification timeline, list each AI system in scope and confirm which of these records it generates. Ask your certification body to state, in writing, the evidence it will sample during stage 1 and stage 2. Ownership matters here. Your organization owns the policy, the impact assessments, the logs and the audit records, and it must be able to produce them on request. An implementation partner can help structure templates, set up retention and build logging, but it cannot approve your policy or sign off your assessments. Only an independent certification body can issue the certificate, and it will judge whether the records you hold are current, controlled and consistent with what your AI systems actually do.
Which documents and records the standard calls out by name
ISO/IEC 42001 names a small set of documents and records by control ID, and each one answers a different question an assessor will ask. Clause 7.5 sets the general rules for creating and controlling them, but the content of each record is set by the Annex A control or clause that requires it. Treat each card below as a checklist for what the record must show and what an auditor will pull.
AI policy and its guidance
Control A.2.2 asks the organization to document a policy for developing or using AI systems, and Annex B gives implementation guidance under B.2.2. The policy should state management's direction for responsible AI and be specific enough that a reader can tell what it permits and forbids. Auditors check that it is approved, dated, communicated to the people it affects, and that the stated commitments match what teams actually do.
Statement of applicability
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. Exclusions need a reason tied to the organization's context and risk treatment, not just a checkbox. Auditors sample several exclusions and test whether the reason holds up against the actual AI systems in scope.
Impact assessment results
Control A.5.3 asks the organization to document the results of AI system impact assessments and retain them for a defined period. The record should show the system assessed, the affected groups, the identified impacts, the decisions taken and the review dates. Confirm the retention period with your own policy and write it down, because auditors check that records are kept for the period you set and that old assessments are not overwritten.
Design and development records
Control A.6.2.3 asks the organization to document how each AI system was designed and developed against its objectives, documented requirements and specification criteria. The useful record links each requirement to a design decision and to the verification that followed. Auditors pick one system and trace a requirement from the specification through to the design choice and the test evidence.
Technical documentation for interested parties
Control A.6.2.7 asks the organization to determine which technical documentation each category of interested party needs, such as users, partners and supervisory authorities, and to provide it in an appropriate form. The mapping of audience to document is itself a record. Auditors ask who receives what, whether the content matches the audience, and whether the version given to a customer matches the current system.
Event log phases
Control A.6.2.8 asks the organization to decide at which life cycle phases event log recording should be enabled, and at a minimum while the AI system is in use. The record should state those phases, the events captured, the retention approach and who can access the logs. Auditors check that logging was switched on in the phases the organization declared and that logs exist for a sampled period of operation.
How each mandatory record is produced and kept
The AI policy is the top-level statement of management direction, and it is the record auditors read first. Under A.2.2 the organization documents a policy for developing or using AI systems, and clause 6.1.3 requires a statement of applicability (SoA) that lists the Annex A controls the organization needs and justifies including or excluding each one. The policy is usually owned by senior management with the AI governance lead drafting it, while the SoA is owned by the team running the risk treatment. Both should be updated when the scope changes, when a new AI system enters the scope, or after a management review finds a gap.
- Owner: Senior management approves the AI policy. The AI governance lead or compliance lead maintains the SoA.
- Trigger: A new AI system, a change in scope or role, a risk treatment decision, or an outcome of internal audit or management review.
- Retention and review: Set the review interval and the retention period yourself and write both into the document control procedure.
- Evidence trail: Keep approved versions with dates, approver names, and a change log that links each SoA justification to the risk assessment that drove it.
- Consistency check: Confirm that every excluded control has a written reason and that the policy still matches the current scope.
Before certification, ask your certification body which versions and approval records it expects to sample, and confirm the review cycle with it.
A.5.3 asks the organization to document the results of AI system impact assessments and retain them for a defined period. The record must show what was assessed, who assessed it, what impacts on individuals, groups and society were identified, and what was done about them. The assessment is usually owned by the team that builds or operates the system, with privacy, legal and risk functions reviewing it. It must be refreshed when the system, its intended purpose, its data or its deployment context changes, not only once at launch.
- Owner: The system owner prepares the assessment. Privacy, legal and risk functions review and sign off.
- Trigger: Initial design, material change to the model, data, purpose or user population, and any reported adverse impact.
- Retention rule: The organization sets the retention period under A.5.3 and records it in the procedure, along with how long superseded versions are kept.
- Evidence trail: Versioned assessment reports, reviewer sign-offs, links to the risk register entries they inform, and records of the mitigations that were implemented.
- Link to other controls: Confirm that outputs feed the SoA and the AI risk treatment plan, since the two records must agree.
Ask your auditor how it will test that assessments were triggered by changes, because an assessment dated only at launch is a common finding.
Design records under A.6.2.3 document how the AI system was developed against its objectives, documented requirements and specification criteria. Technical documentation under A.6.2.7 goes further, because the organization must determine what each category of interested party needs, such as users, partners and supervisory authorities, and provide it in an appropriate form. Engineering teams usually own the design record, while product or compliance owners decide the audience and format of the technical documentation. Both should be versioned alongside the model or system release they describe.
- Owner: The development lead owns design records. Product or compliance owners define the audience for technical documentation.
- Trigger: Each design decision that changes requirements, each release, and each update to the interested-party register.
- Retention rule: Tie retention to the life of each released version, and set the period in your own document control procedure.
- Evidence trail: Requirement specifications, design reviews, a traceable link from requirements to test results, and a matrix showing which party received which document version.
- Tooling: Repositories, issue trackers and documentation sites with version history can hold this evidence if access and change logs are enabled.
Confirm with your team that the release tags in the repository match the versions listed in the technical documentation index.
A.6.2.8 asks the organization to decide at which life cycle phases event log recording should be enabled, and at a minimum when the AI system is in use. The record is therefore generated by the system itself, but the organization owns the logging decisions, the retention period and who may read the logs. Platform or operations teams usually run the logging pipeline, while security and the AI governance lead define what is captured and reviewed. ISO/IEC FDIS 24970, which addresses AI system logging, is a useful reference when designing the logging scheme, though it is not the source of your obligations.
- Owner: The platform team operates the logging pipeline. Security and governance define the event types and review cadence.
- Trigger: Enabling logging at each phase you have decided on, and any change to the logged fields or the model version.
- Retention rule: Document the retention period, storage location and access restrictions in the logging standard, and align it with privacy obligations for any personal data in the logs.
- Evidence trail: Log configuration as code, integrity controls on stored logs, access records for log review, and a record of how alerts were handled.
- Verification: Test that logging is actually on in each environment, including non-production environments where you decided it applies.
Document how your logs can be reconstructed for an auditor, and check that the chosen retention still meets your own contractual and regulatory duties.
Internal audit and management review records show that the AI management system is checked and steered after it is built. Clauses 9.2 and 9.3 require these activities, and the resulting records are the proof that the organization acts on its own findings. Internal audit is usually owned by an independent function or a trained internal auditor, while management review is chaired by senior management. Both produce records that feed back into the policy, the SoA and the objectives, so they must be dated, approved and traceable to the actions they generated.
- Owner: Internal audit owns the audit programme and reports. Senior management owns the management review minutes.
- Trigger: The planned audit schedule, a significant change, a nonconformity, or a scheduled management review meeting.
- Retention rule: Set the retention period for audit plans, reports and minutes in your document control procedure, and keep the period consistent across all records.
- Evidence trail: Audit plans, checklists, findings with root causes, corrective action records, and management review minutes that show decisions and resources.
- Closure: Track each action from finding to verified closure, with dates and owners.
Ask your certification body how many cycles of audit and review it expects to see before stage 2, since this shapes how far back your records must go.
Why event logs and technical documentation need a decision early
Technical documentation and event logs are the two records that cannot be reconstructed after an AI system is already in use. Both depend on decisions made during design: who receives which documentation, and at which life cycle phases logging is switched on. The cards below cover those decisions and the checks to make before an assessor asks for evidence.
Map interested party groups to documentation
Clause A.6.2.7 asks you to decide which categories of interested parties need AI system technical documentation and in what form. Users, business partners and supervisory authorities usually need different content, so list each group, its information need and the format you will provide. For example, an illustrative internal user group may need instructions and limitations, while a supervisory authority may need design rationale and test results. Record that mapping in your documented information so an assessor can trace each group to a delivered artifact.
Set logging phases during design
Clause A.6.2.8 asks you to determine the life cycle phases in which event log recording should be enabled, with use as the minimum. Decide this during design, not after deployment, because logs for development or testing phases that were never enabled cannot be recovered later. Document the phases, the reasoning and who approved them, and tie the decision to the AI system's risk and impact assessment records.
Define what each log captures
A phase decision is only useful if the logs contain the events you need to reconstruct behavior. Specify the event types, fields, timestamps, model or version identifiers and the retention period for each system. Confirm with the vendor or platform team which logging features the chosen software supports natively, which require configuration, and which need custom development. Do not assume a platform meets this need until the capability is demonstrated in your environment.
Check the logging standard before building
ISO/IEC FDIS 24970 covers AI system logging and is the guidance source to check when designing your logging approach. Read the published text directly and compare it with your logging design, rather than relying on secondary summaries. Note any terms or expectations that your design should address and record how you reviewed it, so the reasoning is available at certification audit.
Confirm vendor logging and documentation support
Before selecting or configuring open-source components, ask the vendor or maintainers how the platform records events, where logs are stored, how they are exported and whether tamper resistance is available. Ask for documentation of the logged fields and default retention. Also ask how release notes and model or configuration changes are recorded, since these affect the technical documentation you must keep current. Treat unanswered questions as open risks in the statement of applicability.
Keep documentation and logs under version control
Technical documentation and event logs must reflect the system that actually ran, so tie each document version to a system release and each log record to its configuration. Store design records, documentation and log retention settings in a controlled repository with access rules and change history. Clause 7.5.3 sets the general expectation for controlling documented information, and an assessor will ask how you know the documentation matches the deployed version.
How to set up document control in the first months
This sequence turns the records ISO 42001 expects into a controlled set of documents with named owners, version rules and a tested evidence pack that an independent certification body can review.
Inventory every required record
Start by listing each document and record the standard requires or that your chosen Annex A controls depend on. Cover the AI policy, the statement of applicability, impact assessment results, design and development records, technical documentation for each interested party category, event log settings, internal audit records and management review minutes. Mark which records apply to each AI system in scope. The step is done when the inventory lists every item, its clause or control reference, the AI systems it covers and the place where it currently lives, even if that place is an email thread or a shared folder.
Assign a named owner to each record
For every item in the inventory, name one accountable owner who creates and maintains it, plus a backup. Owners are usually the people who already run the work, such as the product lead for design records or the security lead for event log configuration. The organization owns these assignments, and an implementation partner can help draft them but should not own them. The step is done when every row in the inventory has an owner, a backup and an agreed review trigger, and leadership has approved the list.
Define the document register and version rules
Build a single document register that records each controlled document's identifier, title, owner, approver, status, current version, location and retention rule. Under clause 7.5.2, set the rules for creating and updating documented information, including identification, format, and review and approval before release. Under clause 7.5.3, define how documents are stored, protected, accessed, changed, retained and disposed of, and how obsolete versions are kept or removed. The step is done when a written procedure exists, the register is populated, and a test change to one document goes through the approval path and is logged.
Run a pilot record set for one AI system
Choose one AI system in scope and produce its full record set under the new rules. Create the impact assessment record, the design and technical documentation, the event log configuration and the related policy references, using the register identifiers and approval steps. Note where owners struggled, where templates were missing and where records existed in more than one place. The output is a pilot record set for that system and a short list of corrections to the procedure, the templates or the register.
Apply the corrections and extend to all systems in scope
Update the procedure, templates and register based on the pilot findings, then roll the same record set out to the remaining AI systems in the scope statement. Confirm that each system's records link back to the statement of applicability and the impact assessment. The step is done when every AI system in scope has a complete record set in the register, with no records held only in personal folders or chat tools, and each record shows an approved version.
Complete an internal audit sample of the records
Have an internal auditor, independent of the people who produced the records, select a sample across the register and test it against the documented procedure and the requirements. The auditor checks that each sampled record has an owner, an approved current version, a traceable link to its control or clause, and retention applied as defined. Findings go to the record owners with a corrective action and a closure check. The step is done when the audit sample report exists, every nonconformity has an owner and a recorded fix, and the fixes have been verified.
Freeze the evidence pack for the certification body
Once corrections are verified, freeze a dated evidence pack that contains the approved versions of the in-scope records, the register extract, the procedure, the internal audit report and the management review record. Store it in a read-only location with an index. Confirm with the certification body in writing which format and access method it expects, because it decides what it reviews. The step is done when the pack is indexed, its contents match the register, and the certification body has confirmed the submission format. Your organization keeps ownership of the pack, and only the certification body issues any certificate.
Questions buyers ask about ISO 42001 documentation
Is a single AI policy document enough for ISO 42001?
No. The AI policy under A.2.2 is one required document, but clause 7.5 and the other requirements in clauses 4 to 10 call for further documented information. Auditors look for an AI policy that is aligned with other organizational policies and reviewed periodically, plus records showing that the rest of the management system runs. The statement of applicability is the anchor for deciding which further documents are needed, because each Annex A control you include points to the evidence it depends on. Expect the document set to grow with the number and risk of your AI systems rather than stay fixed at one policy.
Does every Annex A control need its own separate record?
Not necessarily. ISO/IEC 42001 does not require one document per control. Clause 6.1.3 requires a statement of applicability that lists the controls you need and justifies including or excluding each Annex A control. Some controls share evidence, such as an impact assessment record that also supports a design review, while others need a dedicated record, such as the documented results of AI system impact assessments under A.5.3. Map each included control to the document or record that proves it, then merge where one artifact genuinely serves several controls. Confirm with your certification body how it expects that mapping to be presented.
How much effort does ISO 42001 documentation take, and what drives it?
The effort depends mainly on the number of AI systems in scope, how many of them are high-impact, how many Annex A controls you include, and how mature your existing management system is. A single internal chatbot with no personal data needs a much smaller record set than a provider platform used by regulated customers. Organizations that already run an ISO 27001 management system often reuse document control, review cycles and audit records, which reduces the work. Ask any consultant for a list of expected documents tied to your statement of applicability before agreeing a fixed scope, since that list is what the price should follow.
Can our own team write the ISO 42001 documents and records?
Yes. The standard does not require outside authors, and the organization owns its AI policy, risk decisions and management review. Internal teams usually write the records that describe their own systems, such as design records, event log configurations and technical documentation for users. The part that often needs experience is consistent document control under clause 7.5.3: versioning, approval, distribution, retention and withdrawal of obsolete copies. Staff who build the AI systems should write what they know, while a governance owner should check that each record matches the statement of applicability and that approvers have the authority to sign.
What does an implementation partner prepare, and what does the auditor review?
An implementation partner can prepare systems, controls and evidence for an assessment, including document templates, configured logging, impact assessment drafts and a mapped evidence set. The organization still owns its controls and must approve and be able to explain every record. The independent certification body reviews the documented information during its audit and issues any certificate, and DeployOpen does not issue audit reports or certificates. Keep the partner's preparation work separate from the auditor's testing so that your evidence can be assessed on its own merits. Ask the partner to name which documents it drafted and which were produced by your staff.
How should we decide retention periods for AI records?
Set retention periods from the statement of applicability and your own legal and contractual obligations, not from the standard itself. A.5.3 asks you to retain impact assessment results for a defined period, and the period you choose should be written down and approved. Event logs under A.6.2.8 need a retention rule that fits your operating model, your incident response needs and any sector rules that apply to you. Other obligations, such as data protection law or customer contracts, may require longer or shorter retention for particular records. Review retention periods during management review and record any change, so auditors can see the rule was applied consistently.
Where documentation projects stall or grow
Most ISO 42001 documentation problems are not gaps in the wording of a policy. They come from documents that drifted away from the AI systems they describe, from records nobody can find or trust, and from evidence that was never refreshed after something changed. The cards below cover the failure points an assessor is most likely to probe, with a practical step to avoid each one.
Template policies that ignore real systems
A downloaded AI policy that names generic principles but never mentions the models, data sources or use cases the organization actually runs will read as a formality. Clause 5.2 and control A.2.2 expect the policy to fit how AI is developed or used in practice. Check each policy statement against a list of your live AI systems, and ask the owner of each system to confirm the commitments that apply to it. Tie every policy clause to a named system, role or process so the policy can be shown to drive day-to-day decisions.
Statement of applicability disconnected from risk treatment
The statement of applicability under clause 6.1.3 must list the Annex A controls the organization needs and justify each inclusion or exclusion. When it is written once and then left alone, its exclusions cannot be traced to the risks in the treatment plan, and an assessor will find the gap quickly. Walk each risk in the treatment plan to the control that addresses it, and each excluded control to a stated reason. Every control in the statement should trace to a risk decision and a current owner.
Records held in personal drives
Impact assessments, design records and event log reviews stored on an individual's laptop or personal cloud folder disappear when that person changes role or leaves. Clause 7.5 expects documented information to be controlled, which means it must be identifiable, available where needed and protected. Move all AI governance records into a managed repository with defined owners and access rights, and confirm that the organization keeps retained copies after staff departures. Set a single system of record for each document type and tell staff where it lives.
Missing version history and approval trail
A document with no version number, revision date or approver cannot show what the organization knew at a given time, which matters when an auditor asks why a decision was made. Clause 7.5.3 covers control of documented information, including versioning and distribution of changes. Require a version identifier, a change summary and an approver on every controlled document, and keep superseded versions rather than overwriting them. Make the approval record part of the document itself so the audit trail survives file copies and exports.
Impact assessments not repeated after change
An impact assessment completed at launch becomes unreliable once the model is retrained, the data source changes or the use case expands. Control A.5.3 expects the results to be documented and retained for a defined period, and an assessment that no longer reflects the system weakens every related record. Define the triggers for re-assessment in your change process, such as a new model version, a new data category or a new user group, and record each re-assessment with its date. Link every assessment to the system version it covered so reviewers can see which change it addressed.
Who writes the records, who helps, and who certifies
The organization owns its ISO/IEC 42001 records. Its management approves the AI policy, the statement of applicability, impact assessment results, technical documentation, event log settings and the internal audit and management review records, and it is accountable for their accuracy whether a person, a team or a vendor drafted them. An implementation partner such as DeployOpen can prepare document templates, configure the systems that generate logs and store records, set up evidence collection routines and document how those systems run inside your own infrastructure. That preparation work does not transfer ownership of any control or record. Before work starts, confirm in writing which documents the partner drafts, which the internal owners must review and sign, and who approves changes to each one.
Only an independent certification body issues an ISO/IEC 42001 certificate. ISO itself does not certify organizations, and accreditation of certification bodies is voluntary, so the first check to make is whether the body you plan to use is accredited for this standard by a recognized accreditation body in its jurisdiction. ISO/IEC 42006:2025 sets additional requirements for bodies that certify AI management systems, and the certification body's auditors will test the records directly rather than accept a consultant's summary. Ask the certification body how it treats documents prepared by an outside party, and keep the partner's role and the auditor's role separate in your project plan so that no single party both designs the evidence and judges it.
Any engagement should be scoped against the records listed in the outline before the first template is drafted. Ask for a written list of each record, its owner, the approver, the storage location and the retention rule the organization will apply, and confirm with the certification body which of those items it expects to see at each audit stage. Nothing in this section guarantees that a given audit will be passed, that a certificate will be issued or that a specific timeline will be met. Those outcomes depend on the organization's own controls, its AI systems and the auditor's findings.
Which official sources to read before drafting
This sequence gets your team working from the right primary sources, so the document set you draft matches what the standard and the certification rules actually expect. Each step ends with a check you can confirm before moving on.
Confirm the edition you are working from
The compliance lead or a designated engineer checks the ISO page for ISO/IEC 42001:2023, the first edition published on 18 December 2023. Record the edition and publication date in the project file so every later document cites the same version. ISO lists no amendment or revision in progress as of October 2026, so confirm that status again on the day you start drafting. The output is a one-line source note naming the edition, the date and the date you checked it.
Read the ISO standard page for scope and purchase
Open the official ISO page for ISO/IEC 42001 at ISO standard page and read the summary, scope and availability information. Use it to confirm that the standard applies to any organization that provides or uses AI systems, regardless of size or type. Buy the full standard from ISO or your national member body, because the normative text of clauses 4 to 10, Annex A and Annex B is only available in that paid copy. The check is a purchased copy filed with the document control register.
Use the IEC preview PDF for clause structure
Open the IEC preview PDF to read the table of contents, introduction and scope. It shows where clause 7.5 sits, with its sub-clauses on general rules, creating and updating documented information and control of documented information. Use this preview to build your draft outline, then check every requirement wording against the full standard you bought. The output is a clause map for the documented information section, listing each sub-clause and the document types you expect to reference.
Map the documented information requirements to Annex A
Using the purchased standard, list every place where a control asks you to document something or keep a record, such as the AI policy under A.2.2, impact assessment results under A.5.3, design documentation under A.6.2.3, technical documentation under A.6.2.7 and event logs under A.6.2.8. Mark which items the statement of applicability will include. The output is a register table with one row per required record, its owning control, its owner and its retention note, reviewed by the AI governance lead.
Read ISO/IEC 42006 before scoping the certification body
Open the ISO/IEC 42006:2025 page to see what the standard adds for bodies that certify AI management systems, on top of ISO/IEC 17021-1. Read how certification bodies are expected to assess documented information, since this shapes what an auditor will ask to see. Note that ISO/IEC 42006 is a requirement for certification bodies, not for your organization. The output is a list of auditor expectations to cover in your records, which you verify with candidate certification bodies rather than assume.
Check the certification process on the ISO page
Read the ISO certification page to confirm that ISO does not certify organizations and that independent certification bodies issue certificates. Note that accreditation of those bodies is voluntary. This step separates what your team prepares from what an accredited, independent body decides. The output is a short role statement for your project plan that names your organization as the owner of records, any implementation partner as the preparer, and the certification body as the only party that issues a certificate.
Confirm the open items with the certification body
Before drafting final records, send your list of open questions to the certification bodies you are considering. Ask how they expect retention periods, document approvals and event log evidence to be shown, and whether they apply the ISO/IEC 42006 requirements in their audit plan. Ask for written answers. The check is a filed response from each body that you compare against the purchased standard, with any gap logged for your management review.
How DeployOpen prepares ISO 42001 records for audit
DeployOpen prepares the documents and records that ISO 42001 requires inside your own infrastructure, so the evidence your auditor samples comes from systems you control. We do not write your AI policy for you in isolation, and we do not issue or judge conformity, which stays with your organization and an independent certification body.
How we scope
- Engagements are fixed-scope, with the documents and records to be prepared agreed in writing before work starts.
- The written scope lists each record type, the AI systems it covers and the named owner inside your organization.
- We confirm where each record lives today, such as wikis, ticketing tools, repositories or logging platforms, before any build begins.
How we build
- We set up a controlled document register with version history, approval steps and review dates for the AI policy and related records.
- We configure logging and record retention in your environment for AI system event logs, matching the retention period your organization defines.
- We draft impact assessment and technical documentation templates for your team to complete, with review steps that leave decisions with your staff.
How we hand over
- You receive the document register, templates, configured tooling and a written index that maps each record to its clause or Annex A control.
- Handover includes a walkthrough with the people who maintain records, so they can explain how each record is created, approved and retired.
- We confirm with your auditor, before handover, which formats and retention periods they expect to sample during the certification audit.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover, if your team wants help keeping records current.
- Retainer support can cover updates to the register when AI systems change, new records are added or audit findings require corrections.
- Your organization remains responsible for its controls, its statement of applicability and its management review decisions throughout.
