ISO 42001 requirements. What to build and evidence before your stage 1 audit.
A stage 1 auditor reads your documents: scope, policy, risk and impact assessment methods, the Statement of Applicability, and evidence of internal audit and management review. This page sets out what to build for clauses 4 to 10 of ISO/IEC 42001:2023, in the order a practitioner builds it. You finish with a document set an auditor can sample and a clause map to check it against.
ISO 42001 uses the Annex SL structure shared by ISO 27001 and ISO 9001. If you hold either, clauses 4, 5, 7, 9 and 10 will feel familiar and much of the procedure carries over. Steps 3, 4 and 5 below hold the AI-specific work: a risk assessment built for AI, an impact assessment on the people a system affects, and a Statement of Applicability that justifies every Annex A control in or out.
The standard's text is copyright. Clause and control titles appear as written, and everything else on this page is our paraphrase.
Step 01 路 Clauses 4.1 to 4.4
Build the inventory and fix the scope.
Start with an AI system inventory. No clause names it, but you cannot scope the management system without one, and APRA expects regulated entities to hold one.
For each system in the inventory, record your role: developer, provider, deployer or a mix. That is the core of the clause 4.1 context analysis. Clause 4.2 then asks who has a stake in each system and what they require. Name the instrument behind each requirement, such as APRA CPS 230, the Privacy Act 2020 or the Algorithm Charter, so every line in the register points to a source.
Clause 4.3 turns the inventory into a scope covering named AI systems, business units, sites and processes. The scope statement is printed on the certificate. Clause 4.4 asks you to establish and maintain the system as a set of connected processes, and a process map with owners is the simplest evidence.
What you produce
An AI system inventory, a context analysis, a stakeholder register and an approved scope statement.
Worked example
A scope that lists the product families a customer recognises, with every AI feature inside them, gives the auditor a boundary to test. A buyer can also see whether the AI they use sits inside it.
Step 02 路 Clauses 5.1 to 5.3, 6.2
Get the policy approved and name an owner for every system.
Clause 5 puts the management system with top management. The evidence is a decision on paper: board or executive minutes approving the system and resourcing it, with a named executive sponsor.
The AI policy under 5.2 is approved at the top, communicated to staff and made available to interested parties as appropriate. Keep the approval date, the version history and proof of distribution.
Clause 5.3 asks who is accountable for what across the AI lifecycle, so name an owner for every system in the inventory. Clause 6.2 then sets measurable AI objectives, each with an owner and a timeframe.
What you produce
An approved AI policy, a responsibility matrix covering every inventoried system, and an objectives register.
Worked example
An objective written as a regulator outcome, such as no untested model in a critical operation, gives its owner a test to report against at management review.
Commonwealth agencies already name an accountable official under the DTA policy, and APRA expects clear ownership across the AI lifecycle.
Step 03 路 Clauses 6.1.1, 6.1.2, 8.2
Write the risk method and run the first assessments.
Set your risk criteria and choose a method. ISO/IEC 23894:2023, the AI risk management guidance aligned to ISO 31000, is the method reference. Annex C of 42001 is an informative catalogue of AI objectives and risk sources, including fairness, security, explainability, safety, privacy and environmental impact. Use it to seed the assessment.
The process must give comparable results across systems. Run it once for every in-scope system before stage 1. Clause 8.2 then requires it at planned intervals and whenever something significant changes, with the results kept.
What you produce
A written risk method with criteria, and a dated assessment for each in-scope system.
Worked example
APRA found few entities monitor model drift in real time. Write drift into the method as a change trigger, so a drift finding starts a fresh clause 8.2 assessment.
ASIC REP 798 expects licensees to update their risk frameworks for bias, transparency and data quality.
Step 04 路 Clauses 6.1.4, 8.4
Run the AI system impact assessment.
Clause 6.1.4 requires a documented process for assessing what an AI system does to individuals, groups and society. Clause 8.4 requires you to run it at planned intervals and on change, and keep the records. No other Annex SL standard has this pair, so ISO 27001 holders build it new.
ISO/IEC 42005:2025 is the guidance written for this clause. It describes how to integrate the impact assessment into risk management and into the management system. Build your process on it and the auditor will recognise the structure.
Australian public sector buyers run their own version. The DTA has an AI Impact Assessment Tool for Commonwealth agencies, and NSW agencies apply the AI Assessment Framework.
What you produce
An impact assessment method and a dated assessment for each in-scope system, listing the individuals and groups considered.
Worked example
A New Zealand organisation deploying an AI tool that uses personal information runs a privacy impact assessment before go-live, as the Privacy Commissioner expects. M膩ori data and te ao M膩ori considerations belong in the groups section of the same assessment. The Stats NZ Algorithm Impact Assessment toolkit is a workable starting point for it.
For the M膩ori data side of the assessment, see M膩ori data governance.
Step 05 路 Clauses 6.1.3, 8.3
Choose controls and write the Statement of Applicability.
Clause 6.1.3 asks you to decide the controls your risks need, compare them with the 38 in Annex A, and record which apply, which do not, and why. That record is the Statement of Applicability, and it is one of the first documents a stage 1 auditor reads. No control is automatically mandatory. Auditors check the selection and the reasoning, so a blanket adoption of all 38 with no scoping is as weak as an unjustified exclusion.
The treatment plan sits beside it, with an owner and a date for each action. Clause 8.3 requires you to carry the plan out and keep the records.
Exporters to the EU should keep A.6.2.7 technical documentation and A.6.2.8 event logs applicable. Annex A makes both optional, and excluding them leaves the system's logging coverage limited.
What you produce
The Statement of Applicability and a treatment plan with owners and dates.
Worked example
A company that only deploys Copilot, Bedrock or a vendor model can justify excluding several Annex A.6 development controls. The A.9 controls on responsible use and intended use apply in full. A vendor's own ISO 42001 certificate counts as evidence for A.10.3 supplier evaluation and covers nothing else in your system.
Every control, with an Australian or New Zealand example, is on the Annex A controls page.
Step 06 路 Clauses 7.1 to 7.5
Put people and documents in place.
Clause 7 covers resources, competence, awareness, communication and document control. ISO 27001 holders reuse the most here, because their procedures for training records and document control extend to AI.
Competence under 7.2 needs records for the people who develop, operate and oversee AI systems. Awareness under 7.3 means staff know the policy, their part in the system and the consequences of ignoring it. Clause 7.4 sets what you communicate about the system, to whom and when. Clause 7.5 controls the versions, approvals and retention of every document this page names.
What you produce
Competence records, acceptable use acknowledgements, a communication plan and a controlled document register.
Worked example
APRA found staff use of enterprise AI tools lacked preventative controls and expects training on use, misuse and limitations. An awareness module built on those topics, with completion records, answers clause 7.3 and the APRA expectation together.
APRA also found internal audit and risk functions short of AI specialist skills, which is a competence gap under clause 7.2.
Step 07 路 Clauses 8.1, 6.3
Control what you outsource and plan your changes.
Clause 8.1 puts the processes planned in clause 6 into operation and requires control of anything outsourced. Where a vendor supplies the model or platform, the evidence is the contract.
Check each AI contract for transparency, audit rights, incident notification and a tested exit. Map the supply chain through to fourth parties, which APRA expects of regulated entities.
Clause 6.3 requires changes to the management system to be planned. Keep change records that show each change was assessed before it went in.
What you produce
Reviewed supplier contracts, a supply chain map and a change log.
Worked example
An APRA-regulated entity runs one contract review for both regimes, because CPS 230 has applied to every contracted service provider since 1 July 2026.
APRA has flagged change management and assurance as an AI concern for regulated entities. See CPS 230 for AI for the contract terms.
Step 08 路 Clauses 9.1 to 9.3, 10.1, 10.2
Prove the system works before you book stage 1.
Clause 9.1 asks what you monitor, how, when and who evaluates the results. For AI systems that includes performance after deployment.
Clause 9.2 needs an internal audit programme run by people independent of the activity they audit, with reports and follow-up. Clause 9.3 needs top management to review the system against defined inputs and minute its decisions. Stage 1 reviews evidence of both, so complete one cycle of each before you book. Allow at least 3 months of live operation before stage 1, so the monitoring records, one internal audit and one management review all fall inside it.
Under clause 10, log each nonconformity with its root cause, the action taken and a check that the action worked. Trace improvements back to the audits, reviews and incidents that prompted them.
What you produce
Monitoring results, an internal audit report, management review minutes and a nonconformity log.
Worked example
The FMA is probing governance and oversight of AI in financial advice. A New Zealand adviser using AI can point to its management review minutes as the record of that oversight.
Annex A.8.4 adds communication of incidents to affected parties, which APRA also expects in supplier contracts.
Reference
Clause map and the stage 1 document set.
Check your build against this before you book. The document set lists what the clauses call for by name. The table below it covers every auditable sub-clause, with the evidence an auditor samples and the Australian or New Zealand document that asks for the same thing.
| Sub-clause | What it requires | Evidence an auditor samples | Who else asks for it in AU or NZ |
|---|---|---|---|
| Clause 4. Context of the organisation | |||
| 4.1 Understanding the organisation and its context | Identify the internal and external issues that bear on your AI use, including your role as developer, provider, deployer or a mix. | A context analysis naming your AI role per system and the regulatory issues attached to each. | APRA expects regulated entities to hold an AI inventory. |
| 4.2 Needs and expectations of interested parties | Name the regulators, customers, affected individuals, suppliers and staff with a stake, and what each requires. | A stakeholder register that cites the actual instrument: APRA CPS 230, the Privacy Act 2020, the Algorithm Charter. | ASIC reviewed 23 licensees and found AI adoption outpacing governance. |
| 4.3 Scope of the AI management system | Define which AI systems, business units, sites and processes the system covers. | The written scope statement. It becomes the scope printed on the certificate. | |
| 4.4 AI management system | Establish, implement, maintain and continually improve the system and its processes. | A process map showing how clauses 5 to 10 connect, with owners. | |
| Clause 5. Leadership | |||
| 5.1 Leadership and commitment | Top management owns the system, integrates it into business processes and resources it. | Board or executive minutes approving and resourcing the system, with named executive sponsorship. | APRA observed boards still building AI literacy and entities treating AI as just another technology. |
| 5.2 AI policy | A documented policy approved at the top, communicated internally and available to interested parties as appropriate. | The policy document with approval date, version history and distribution evidence. | Voluntary AI Safety Standard guardrail 1 asks for an accountability process. The NZ Privacy Commissioner expects senior leaders inside generative AI decisions. |
| 5.3 Roles, responsibilities and authorities | Assign who is accountable for what across the AI lifecycle. | A RACI or equivalent that names an owner for every AI system in the inventory. | The DTA policy requires Commonwealth agencies to name an accountable official. APRA expects ownership across the lifecycle. |
| Clause 6. Planning | |||
| 6.1.1 General | Determine the risks and opportunities the system must address. | Risk criteria and the chosen method, with ISO/IEC 23894:2023 as the method reference. | RBNZ expects AI exposures assessed inside existing risk management. |
| 6.1.2 AI risk assessment | A defined, repeatable process that produces comparable results across systems. | The written method, the criteria, and at least one completed assessment per in-scope system. | ASIC REP 798 expects licensees to update risk frameworks for bias, transparency and data quality. |
| 6.1.3 AI risk treatment | Select controls, compare them against Annex A, justify inclusions and exclusions, and record the result in the Statement of Applicability. | The Statement of Applicability and the treatment plan with owners and dates. | Annex A.10 supplier controls map to APRA鈥檚 supply chain expectations. |
| 6.1.4 AI system impact assessment | A documented process for assessing the consequences of AI systems on individuals, groups and society. Unique to ISO 42001 among the Annex SL standards. | The method, with ISO/IEC 42005:2025 as the reference, and completed assessments. | The DTA has an AI Impact Assessment Tool for Commonwealth agencies. NSW agencies apply the AI Assessment Framework. In New Zealand, the Stats NZ Algorithm Impact Assessment toolkit is a workable starting point. |
| 6.2 AI objectives and planning | Measurable objectives with owners and timeframes. | The objectives register and progress records. | |
| 6.3 Planning of changes | Changes to the system are planned, not ad hoc. | Change records showing assessment before implementation. | APRA has flagged change management and assurance as an AI concern. |
| Clause 7. Support | |||
| 7.1 Resources | Provide the resources the system needs. | Staffing and resourcing decisions tied to the AI programme. | |
| 7.2 Competence | Determine the competence needed, make sure people have it, and keep records. | Training records, role descriptions, evidence of competence for developers, operators and overseers. | APRA found internal audit and risk functions short of AI specialist skills. |
| 7.3 Awareness | Staff know the policy, their part in the system and the consequences of not following it. | Awareness training completion and acceptable use acknowledgements. | APRA expects training on use, misuse and limitations of enterprise AI tools. |
| 7.4 Communication | Decide what to communicate about the system, to whom, when and how. | A communication plan covering regulators, customers and staff. | Commonwealth agencies must publish AI transparency statements under the DTA policy. |
| 7.5 Documented information | Create, update and control the documents and records the system needs. | Version control, approval and retention evidence across the stage 1 document set. | |
| Clause 8. Operation | |||
| 8.1 Operational planning and control | Implement the processes planned in clause 6 and control outsourced processes. | Operating procedures and evidence that outsourced AI processes are controlled. | APRA expects supplier contracts with transparency, audit rights and incident notification. CPS 230 has covered all contracted providers since 1 July 2026. |
| 8.2 AI risk assessment | Run the risk assessment at planned intervals and on significant change. Keep the results. | Dated assessments showing the cadence and the change triggers. | APRA noted few entities monitor model drift in real time. |
| 8.3 AI risk treatment | Implement the treatment plan. Keep records. | Closed treatment actions with evidence. | |
| 8.4 AI system impact assessment | Perform the impact assessment at planned intervals and on change. Keep records. | Dated impact assessments per system, including the people and groups considered. | The Privacy Commissioner expects a privacy impact assessment before an AI tool that uses personal information goes live. |
| Clause 9. Performance evaluation | |||
| 9.1 Monitoring, measurement, analysis and evaluation | Decide what to monitor, how, when and who evaluates the results. | Metrics and monitoring results for in-scope systems, including performance after deployment. | APRA expects continuous monitoring and independent assurance capability. |
| 9.2 Internal audit | An audit programme that is independent of the activity audited, with records. | The programme, auditor independence evidence, reports and follow-up. | |
| 9.3 Management review | Top management reviews the system at planned intervals against defined inputs and records the outputs. | Review minutes covering the required inputs and the decisions taken. | The FMA is probing governance and oversight of AI in financial advice. |
| Clause 10. Improvement | |||
| 10.1 Continual improvement | Improve the suitability, adequacy and effectiveness of the system over time. | Improvement actions traced from audit, review and incidents. | |
| 10.2 Nonconformity and corrective action | React to nonconformities, deal with consequences, find root causes, act, and record all of it. | The nonconformity log with root cause and verification of effectiveness. | Annex A.8.4 adds communication of incidents to affected parties, which APRA also expects in supplier contracts. |
Questions implementers ask.
Which clauses are audited?
Clauses 4 to 10. Clauses 1 to 3 cover scope, normative references and terms and carry no requirements. Annex A controls are audited through clause 6.1.3 and the Statement of Applicability.
Are all 38 Annex A controls mandatory?
No. Each control is considered under 6.1.3 and included or excluded with a written justification. The auditor checks the selection and the reasoning. A blanket adoption of all 38 with no scoping is as weak as an unjustified exclusion.
What is the Statement of Applicability?
The document that records which Annex A controls apply, which do not, and why. It is produced under clause 6.1.3 and it is one of the first things a stage 1 auditor reads.
Can we reuse our ISO 27001 documents?
Partly. The shared Annex SL structure means clauses 4, 5, 7, 9 and 10 overlap heavily and procedures for document control, internal audit and management review can be extended. The AI risk assessment, the impact assessment and the lifecycle, data and supplier controls are new content. Certification bodies can audit both standards in one integrated visit.
Twenty-seven sub-clauses. One gap assessment tells you which are already covered.
The gap assessment maps your existing documents to each sub-clause and scores the AI-specific clauses against the build steps above. You leave with the first draft of your Statement of Applicability.
Free download
ISO 42001 readiness checklist.
Every document and record above as a yes or no item, with an owner column and the regulator pre-check for APRA, the Voluntary AI Safety Standard and the NZ Privacy Commissioner.
Get the checklistThirty-minute call
Gap assessment scoping.
A senior consultant, your current documents, and a clause-by-clause read of what an auditor would raise.