ISO 42001 Requirements: What the Standard Asks For and How to Implement It

ISO/IEC 42001 is short. The requirements run to clauses 4 to 10, and Annex A lists 38 controls. What makes it hard is not the length. It is that the standard expects you to know which AI you use, what it could do to people, and who decides when it should stop.

This guide sets out what each clause asks for, what the Annex A controls cover, and how to implement the standard depending on whether you use AI built by others or build it yourself.

Short answer

ISO 42001 requires an AI management system: a defined scope, an AI policy, named roles, an AI risk assessment, an AI system impact assessment, a Statement of Applicability against the 38 Annex A controls, AI objectives, competence and awareness, operational controls across the AI life cycle, monitoring, internal audit, management review and corrective action. If you already hold ISO 27001 or ISO 9001, about half of this is familiar. The impact assessment, the AI system inventory and the life cycle controls are what is new.

The structure of the standard

ISO/IEC 42001:2023 follows the same harmonised structure as ISO 9001, ISO 14001, ISO 27001 and ISO 45001. Standards Australia has adopted it unchanged as AS ISO/IEC 42001:2023.

Like the other management system standards, ISO 42001 was amended in 2024 to add climate change to clause 4.1. You decide whether climate change is relevant to your AI management system. For most organisations the answer is brief, but the auditor will expect to see that you considered it.

Clause by clause

Clause 4: Context

• 4.1 Context, including your role. Decide the issues that affect your AI management system, and which roles you play in relation to AI. The standard draws on the roles in ISO/IEC 22989, such as AI provider, AI producer, AI customer, AI partner and AI subject. Most organisations play more than one role.
• 4.2 Interested parties. Identify who has requirements, including customers, regulators, staff and the people your AI systems affect.
• 4.3 Scope. Define which AI systems, activities, sites and roles are inside the system. A clear scope is the single biggest factor in audit effort.
• 4.4 The AI management system. Establish, implement, maintain and improve it.

Clause 5: Leadership

• 5.1 Leadership and commitment. Top management must be visibly involved. Our clause 5.1 guide covers what auditors look for.
• 5.2 AI policy. A policy suited to your purpose that sets a framework for AI objectives and commits to meeting requirements and continual improvement. Annex A control A.2 adds detail.
• 5.3 Roles, responsibilities and authorities. Assign who is responsible for the system and for reporting on its performance.

Clause 6: Planning

This is the clause that separates ISO 42001 from ISO 27001.

• 6.1.1 General. Determine risks and opportunities, and set criteria for which AI risks are acceptable and which are not.
• 6.1.2 AI risk assessment. A repeatable process to identify, analyse and evaluate AI risks. It must take account of the impact assessment results. ISO/IEC 23894 gives guidance.
• 6.1.3 AI risk treatment. Choose treatment options and controls, compare them against Annex A so nothing necessary is missed, and produce a Statement of Applicability: which controls apply, why, and why any are excluded. You can add controls of your own.
• 6.1.4 AI system impact assessment. Assess the potential consequences of your AI systems for individuals, groups and society. This is a separate process from the risk assessment, and its results are documented. ISO/IEC 42005:2025 now gives detailed guidance on how to run one.
• 6.2 AI objectives. Measurable objectives, with plans for achieving them.
• 6.3 Planning of changes. Changes to the system are made in a planned way.

Clause 7: Support

• 7.1 Resources and 7.2 Competence: the people working on AI have the skills their role needs, with evidence. Our article on free AI training and clause 7.2 covers a low-cost route.
• 7.3 Awareness: staff know the AI policy and their part in it.
• 7.4 Communication and 7.5 Documented information.

Clause 8: Operation

• 8.1 Operational planning and control, including control of externally provided processes, products and services.
• 8.2 AI risk assessment, 8.3 AI risk treatment and 8.4 AI system impact assessment are carried out at planned intervals and when significant changes occur. This is where the clause 6 processes are actually run and recorded.

Clauses 9 and 10: Performance and improvement

• 9.1 Monitoring, measurement, analysis and evaluation.
• 9.2 Internal audit, against both the standard and your own requirements. See our internal auditing service.
• 9.3 Management review.
• 10.1 Continual improvement and 10.2 Nonconformity and corrective action.

Documented information the auditor will ask for

None of this needs to be a separate document. A register in the tools your team already uses is fine, as long as it is controlled and current.

The 38 Annex A controls

Annex A is a reference list, not a checklist you must complete. You include a control when your risk treatment needs it, and record a reason when you leave one out. An organisation that only uses third-party AI will usually justify excluding most of the development controls in A.6 and A.7. An organisation that trains its own models will not.

Two pathways: using AI or building it

If you use AI built by others

This covers most Australian organisations: Copilot, ChatGPT Enterprise, AI features inside your CRM or contact centre platform, or an AI agent from a vendor.

1. Build the AI system inventory. List every AI system in use, including AI features switched on inside existing software. Record the owner, purpose, data it touches, and supplier.
2. Define your role and scope. You are usually an AI customer and, where you configure or connect systems, partly an AI provider to your own staff and clients.
3. Write the AI policy and acceptable use rules. Keep vendor names out of the policy itself. Our article on why your AI policy should not name a vendor explains why.
4. Run an impact assessment per use case. Focus on who could be affected, how, and what human oversight is in place.
5. Assess and treat the risks, then build the Statement of Applicability. Expect A.9 (use) and A.10 (suppliers) to carry most of the weight.
6. Tighten supplier controls. What the vendor does with your data, where it is processed, and how you are told about incidents.
7. Train, monitor, audit and review.

Typical timeline: three to five months for a small to medium business.

If you build or train AI

This covers software companies, AI startups and internal teams that develop models, fine-tune them or build AI agents for customers.

1. Everything in the user pathway, plus the following.
2. Map the AI system life cycle. Requirements, design, data, training, verification and validation, deployment, operation, retirement. Decide what evidence each stage produces.
3. Put data controls in place (A.7): where training data comes from, rights to use it, quality checks and preparation steps.
4. Set release criteria. What testing a model or agent must pass before deployment, and who signs it off.
5. Log and monitor in production (A.6.2.6 and A.6.2.8): drift, failures, misuse and complaints.
6. Write technical documentation and user information (A.6.2.7 and A.8.2) your customers can rely on.
7. Agree responsibilities with customers (A.10.4) so it is clear who is accountable for what once your system is in their hands. Our article on governing the harness, not the model covers this for AI agents.

Typical timeline: five to nine months, depending on how many systems are in scope and how mature your development process is.

If you already have ISO 27001

You can extend your existing system rather than start again. The clause structure, document control, internal audit, management review and corrective action processes carry across. The AI policy, AI risk criteria, impact assessment, AI system inventory and the Annex A controls are additions. Our guide to how ISO 42001 and ISO 27001 fit together covers the overlap in detail, and our integrated management system guide explains combined audits.

How it lines up with Australian guidance

ISO 42001 is voluntary in Australia. The government’s Guidance for AI Adoption, published by the National AI Centre in October 2025, sets out six essential practices: deciding who is accountable, understanding impacts, measuring and managing risks, sharing essential information, testing and monitoring, and maintaining human control. Each one maps to ISO 42001: accountability to clause 5.3 and A.3, impacts to clause 6.1.4 and A.5, risks to clauses 6.1.2 and 6.1.3, information to A.8, testing and monitoring to A.6 and clause 9.1, and human control to A.9.

If your AI makes or substantially assists decisions about people, the Privacy Act changes from 10 December 2026 also apply. Our article on automated decisions and your privacy policy covers what changes.

Common mistakes

• Treating the impact assessment as a risk assessment with a new name. The risk assessment asks what could go wrong for your organisation. The impact assessment asks what your AI could do to people.
• Missing AI that came in through existing software. The inventory has to include AI features in tools you already pay for.
• Copying Annex A as a checklist. Every included control needs a reason, and so does every exclusion.
• A scope that is too wide. Start with the AI systems customers ask about, then extend.
• No named person who can stop an AI system. Auditors ask who has that authority and when they last used it.

An example

We built the ISO 42001 AI management system for a contact centre and message answering service in 2026, on top of the ISO 27001 and ISO 9001 systems we had built for them two years earlier. Each AI use case, from call summaries to message routing, has its own impact assessment, and the Statement of Applicability excludes the model development controls because the business configures AI rather than trains it.

ISO 42001 requirements: FAQs

How many controls are in ISO 42001?

Annex A lists 38 controls in 9 groups, from A.2 to A.10. You include the ones your risks require and justify any you exclude.

What is the difference between the AI risk assessment and the AI system impact assessment?

The risk assessment (clause 6.1.2) looks at risks to achieving your AI objectives and to your organisation. The impact assessment (clause 6.1.4) looks at potential consequences for individuals, groups and society. The standard requires both, and the impact assessment feeds into the risk assessment.

Do we need a Statement of Applicability?

Yes. Clause 6.1.3 requires one. It lists the controls you need, why you need them, whether they are implemented, and why any Annex A control is excluded.

Does ISO 42001 apply if we only use tools like Copilot or ChatGPT?

Yes, it can. Many certified organisations use AI rather than build it. Your scope, impact assessments and Statement of Applicability reflect that, and many development controls are justifiably excluded.

Are Annexes B, C and D mandatory?

No. Annex B is guidance on implementing the Annex A controls, Annex C lists example objectives and risk sources, and Annex D covers use across sectors. They are useful, but auditors audit against clauses 4 to 10 and the controls in your Statement of Applicability.

How long does implementation take?

For organisations that use AI, three to five months is typical. For organisations that build AI, five to nine months. Our ISO 42001 cost and timeline guide has more detail.

How Streamline can help

Streamline builds and audits ISO 42001 AI management systems for Australian organisations, whether you use AI or build it. You deal directly with an experienced ISO Lead Auditor. A gap analysis shows where you stand against each clause, and ISO mentoring helps your own people build the system. New to the standard? Start with what ISO 42001 is. If you would like a hand, get in touch.

Sources

• ISO/IEC 42001:2023, Artificial intelligence: Management system
• ISO/IEC 42005:2025, AI system impact assessment
• Department of Industry, Science and Resources: Guidance for AI Adoption

Published 16 October 2026 | Facts checked 16 October 2026 | Next review April 2027 | Jurisdiction: Australia | Edition: ISO/IEC 42001:2023 (AS ISO/IEC 42001:2023), including Amendment 1:2024