Decide all 38 ISO 42001 Annex A controls and write your Statement of Applicability.
This page takes you from your AI risk treatment plan to a finished Statement of Applicability. You finish with one line per control, each recording whether it applies, the reason, and the record that will prove it. The full set of 38 sits in a reference table at the end, with the evidence an Australian or New Zealand auditor, regulator or tender panel asks to see.
Clause 6.1.3 of ISO/IEC 42001:2023 requires the Statement of Applicability. It lists every Annex A control, records whether the control applies, and gives the reason either way.
No control applies automatically. Every exclusion needs a written reason, and the certification auditor reads those reasons at stage 1.
The controls are identical in AS ISO/IEC 42001:2023 and NZS ISO/IEC 42001:2025. One statement serves an organisation that operates in both countries.
Step 1 of 7
Gather the inventory and the risk results.
Put three records on the table before you open Annex A: the AI inventory, the results of your clause 6.1.2 risk assessment, and the treatment plan that came out of it. Every decision in the statement points back to one of them.
If the risk assessment is thin, fill it from Annex C of the standard. Annex C is a catalogue of AI objectives and risk sources, including fairness, security, explainability, safety, privacy and environmental impact. If you have no assessment yet, start with the AI risk assessment template.
Produces
An input pack. Each AI system in the inventory has an owner, and each risk in the register has a treatment.
Worked example
An inventory copied from the IT asset register lists the platforms IT bought and nothing inside them. The AI features embedded in SaaS products are the ones that go missing. Add them before you go further, because A.4.2 asks for the resources behind every AI system.
For an APRA-regulated entity, the inventory is a baseline APRA expectation.
Step 2 of 7
Set up one row per control.
Build the statement as a table of 38 rows with four columns: control, decision, reason and evidence. Use the control numbers exactly as the standard prints them.
The numbering starts at A.2.2. A.1 introduces the annex, and the first item in each group states the objective, so the controls begin at the second item of each group.
Produces
A blank statement with 38 rows, ready for decisions.
Worked example
A finished row for A.6.2.6, operation and monitoring, reads: applies; the risk register treats drift in the customer-facing model; evidence is a drift dashboard with thresholds and a named owner.
If you hold ISO 27001, reuse the format of its statement and write new rows. The two standards share clauses 4, 5, 7, 9 and 10, and Annex D of 42001 covers running both systems together. The 42001 Annex A controls are AI-specific content that 27001 does not hold.
Step 3 of 7
Mark the controls your risk treatment already needs.
Read down the treatment plan. For each treatment, find the Annex A control it implements, mark that row as applicable, and enter the risk reference as the reason.
Then read the 38 rows in order and ask of each one whether it covers a risk you left untreated. That second pass is the comparison clause 6.1.3 asks for, so that nothing in Annex A is missed.
Produces
A first pass in which every applicable control cites a risk.
Worked example
A business whose register rates supplier failure as high marks A.10.2 and A.10.3 on this pass. Its customer chatbot runs on a SaaS product that calls a foundation-model API. That is two links in the supply chain, and both go into the A.10.2 allocation of responsibilities.
Step 4 of 7
Check the rows your regulators and buyers will look at.
Before you write a single exclusion, test the unmarked rows against the obligations you already carry. Three sets of controls are hard to defend as not applicable for an Australian or New Zealand organisation.
Mark every row that matches your situation as applicable, with the obligation as the reason.
If APRA regulates you
A.4.2 for the inventory. A.10.2 and A.10.3 for the supply chain mapped to fourth parties and for tested exit options. A.6.2.6 for drift monitoring, and A.6.2.5 for the fallback where AI supports a critical operation. A.4.6 and A.9.2 cover board literacy and staff use.
APRA asks for globally recognised control frameworks and names no standard. ISO 42001 is the certifiable one.
If a system reaches EU users
A.6.2.7 for technical documentation, A.6.2.8 for event logs, and A.8.4 for incident communication. A.6.2.8 is optional in Annex A, so keeping it applicable closes a logging gap in your statement.
ISO 42001 is not a harmonised standard under the EU AI Act and gives no presumption of conformity. EN 18286:2026, the European quality management standard for Article 17, maps to Annex A, so these three rows shorten a later EU exercise.
If you operate or sell in New Zealand
A.4.3 and A.7.2, because the Privacy Commissioner expects a privacy impact assessment before deployment. A.5.4, because Māori data and te ao Māori considerations belong in the impact question. A.4.5 for hosting location in public-sector procurement. A.10.3, because agencies use the AI procurement checklist MBIE publishes.
MBIE's Responsible AI Guidance for Businesses names ISO/IEC 42001 as a framework New Zealand businesses can use.
Step 5 of 7
Write a reason for every exclusion.
A good exclusion reason names the fact that makes the control irrelevant. "No system in scope trains on our own data" is a fact the auditor can test against the inventory. "Low risk" gives the auditor nothing to test.
Read the Annex B entry for a control before you exclude it. Annex B is informative guidance on implementing each control and does not prescribe one method. It sets out lighter ways to apply a control, and a light implementation is easier to defend than an exclusion.
Produces
A reason on every excluded row that names a checkable fact.
Worked example
A company that only deploys a vendor model wants to exclude A.6.2.3, documentation of design and development, because it designed nothing. For a deployer, the design record is the configuration, prompt and integration documentation, with the vendor's certificate or technical file as an input. The team already holds those documents, so the row moves to applicable.
Clause 6.1.3 requires a justification for each exclusion, and auditors check the selection.
Step 6 of 7
Name the evidence for every control you apply.
For each applicable row, write the record that proves the control runs. A document, a register entry or a log all qualify. Put an owner's name beside it.
The reference table below gives the evidence for each of the 38 controls, with the Australian or New Zealand instrument that asks for it.
Produces
A complete evidence column. It doubles as your list of records for the stage 2 audit.
Worked example
A.9.2, responsible use, is evidenced by an acceptable use procedure, a list of approved tools, and training records. APRA found staff use of enterprise AI tools lacked preventative controls, and those records answer that finding.
At stage 2 the auditor confirms the controls work through interviews, observation and sampling of these records.
Step 7 of 7
Version the statement and review it with the risk assessment.
Date the statement and give it a version number. Reopen it each time the risk assessment runs, which clause 8.2 sets at planned intervals and on significant change.
A new system in the inventory reopens the rows that cover it. So does a new supplier or a new regulator expectation.
Produces
A versioned Statement of Applicability, ready for the stage 1 audit.
Worked example
Version 1 carries the date management approved it. When a new supplier enters the inventory, version 2 reopens the A.10 rows and records what changed.
The stage 1 audit reviews the statement alongside the scope, the AI policy, and the risk and impact assessment methods.
The 38 controls, with the evidence for each.
Use this table while you work through steps 3 to 6. Each row gives the control title, what the control asks for, and the evidence that shows it, with the instrument that asks for that evidence.
Control titles are reproduced as written. The descriptions are ours.
A.2 · 3 controls
Policies related to AI.
An approved AI policy, its fit with the policies you already run, and a record of its review. APRA has found regulated entities treating AI as just another technology and missing bias, privacy and model-adaptation issues as a result. A.2.3 is the control that answers that finding.
AI policy
A statement approved at the top of the organisation that sets out how it will develop and use AI responsibly. It is the parent document for every other AI control.
Evidence
The policy with its approval record. In Australia it cites guardrail 1 of the Voluntary AI Safety Standard, which asks for an accountability process. In New Zealand it cites the Privacy Act 2020 information privacy principles and, for signatory agencies, the Algorithm Charter.
Alignment with other organizational policies
The AI policy must not contradict the privacy, security, data, HR or procurement policies already in force. The control asks for the cross-references to be explicit.
Evidence
A one-page policy map showing where AI obligations sit inside the privacy and outsourcing policies. APRA's finding on AI treated as just another technology is the reason to make the map explicit.
Review of the AI policy
The policy is reviewed on a schedule and whenever something material changes. The review and its outcome are recorded.
Evidence
A dated review record naming the trigger and the outcome. Triggers include a new regulator expectation on AI, such as APRA's, and an update to the government AI policy you work under. A policy not reviewed since the last such change has a gap.
A.3 · 2 controls
Internal organization.
Named owners across the AI lifecycle, and a route for anyone to raise a concern about an AI system. The evidence for both controls is a set of names and a channel people know about.
AI roles and responsibilities
Each stage of the AI lifecycle has a named owner: who approves a use case, who signs off deployment, who monitors it, who retires it.
Evidence
A responsibility matrix that names individuals. Commonwealth agencies must name an accountable official under the Digital Transformation Agency's AI policy, and APRA expects clear ownership across the lifecycle in regulated entities.
Reporting of concerns
Staff and others can report concerns about an AI system without reprisal, and the reports go somewhere that acts on them.
Evidence
The whistleblower or speak-up channel you already run under local law, extended to name AI concerns as a category, with its log of reports. A separate AI hotline that nobody knows about scores worse than a known channel with one extra category.
A.4 · 5 controls
Resources for AI systems.
What every AI system depends on: data, models and tooling, compute and hosting, and people. The standard never uses the words "AI inventory", but this group is where the inventory lives.
Resource documentation
A record of the data, tooling, compute and people each AI system relies on, kept current as the system changes.
Evidence
The AI inventory, including the AI features embedded in SaaS products, since those are the ones that go missing. APRA sets the inventory as a baseline expectation for the entities it supervises.
Data resources
The datasets each system is trained on, tested on and fed in operation, documented by source and purpose.
Evidence
A dataset record for each system. In New Zealand it is the input to the privacy impact assessment the Office of the Privacy Commissioner expects before an AI tool that uses personal information goes live.
Tooling resources
The models, libraries, platforms and APIs behind each system, with versions.
Evidence
A tooling list with versions. Foundation-model APIs count as tooling. Recording which vendor model sits behind a customer-facing feature is what makes the supplier mapping in A.10 possible.
System and computing resources
Where each system is hosted and what compute it uses, including region and provider.
Evidence
Hosting region and provider for each system. New Zealand public-sector procurement asks where data is hosted and processed, and this record answers the data sovereignty question before a tender panel asks it.
Human resources
Competent people for development, operation and oversight, with the competence recorded.
Evidence
Training records for the board, internal audit and risk. APRA observed that boards are still building AI literacy and that internal audit and risk functions lack AI specialist skills.
A.5 · 4 controls
Assessing impacts of AI systems.
A security review asks whether the system is protected. These four controls ask who could be harmed by its decisions, which is the part of ISO 42001 an information security programme does not hold. ISO/IEC 42005:2025 is the companion standard that describes the method.
AI system impact assessment process
A defined, repeatable method for assessing the consequences of an AI system, with criteria for when it is triggered and who runs it.
Evidence
A written method with its triggers and owner, using ISO/IEC 42005:2025 as the reference. In New Zealand, the Stats NZ Algorithm Impact Assessment toolkit is a workable starting point.
Documentation of AI system impact assessments
Each completed assessment is kept as a record, with its findings and the decisions taken on them.
Evidence
A completed assessment for each in-scope system. The Digital Transformation Agency has an AI Impact Assessment Tool for Commonwealth agencies, and NSW agencies must apply the NSW AI Assessment Framework. Suppliers to either will be asked for the equivalent record.
Assessing impacts on individuals or groups of individuals
The assessment covers effects on the people the system makes decisions about, including fairness, access and the ability to challenge an outcome.
Evidence
A section of each assessment on affected people. ASIC flagged a credit-scoring model it called a black box. In New Zealand, Māori data and te ao Māori considerations belong in the individual and group impact question.
Assessing societal impacts of AI systems
Wider effects beyond the individual: environment, economy, public institutions and concentration of dependence on a few providers.
Evidence
A section of each assessment on wider effects. The Reserve Bank of New Zealand names concentration of AI in a small number of third-party providers as a systemic vulnerability. For a bank or insurer, that is a societal impact with a regulator attached.
A.6 · 9 controls
AI system life cycle.
The largest group. It runs from stated development objectives through design, testing, deployment, monitoring, technical documentation and logging. ISO/IEC 5338:2023 is the lifecycle process reference. Three of these controls carry APRA expectations directly: A.6.2.4, A.6.2.5 and A.6.2.6.
Objectives for responsible development of AI systems
Written goals for how systems are built: what fairness, safety and reliability mean for this organisation, stated before design starts.
Evidence
Approved development objectives, dated before design began. Guardrails 2 and 4 of the Voluntary AI Safety Standard (a risk management process, and testing) are the Australian wording for the same objectives.
Processes for responsible design and development of AI systems
Defined lifecycle steps for AI work, with a governance gate at each stage.
Evidence
Your existing software lifecycle mapped to ISO/IEC 5338:2023, showing where the AI-specific gates sit.
AI system requirements and specification
Functional and non-functional requirements for each system, including fairness, safety and performance thresholds, recorded before build.
Evidence
A requirements record that names the consumer outcomes the system must meet. The Financial Markets Authority is probing suitability and consumer outcomes in AI-assisted financial advice.
Documentation of AI system design and development
Design decisions, model choices and development records are kept so that a later reviewer can follow why the system is built the way it is.
Evidence
For a deployer of a vendor model: the configuration, prompt and integration documentation, plus the vendor's own certificate or technical file as an input.
AI system verification and validation
The system is tested against its requirements before release, and the results are recorded.
Evidence
Test results against requirements, with the depth set by criticality and the logic written down. APRA expects pre-deployment assessment proportionate to the criticality of the use, so a customer-facing credit model gets more testing evidence than an internal summarisation tool.
AI system deployment
Release is controlled, approved by the right owner, and reversible.
Evidence
A release approval that names the fallback, and a record that the fallback was tested. APRA expects a credible fallback wherever AI supports a critical operation, which links this control to CPS 230 tolerance levels.
AI system operation and monitoring
Performance and behaviour are watched after release, against defined metrics, with a trigger for intervention.
Evidence
A drift dashboard with thresholds and an owner. APRA found few entities monitoring model drift in real time and expects continuous monitoring.
AI system technical documentation
A technical file for the system: architecture, data, performance, limitations and the controls around it.
Evidence
A technical file for each system. For an Australian or New Zealand exporter whose system reaches EU users, this control is the closest thing in 42001 to the EU AI Act's technical documentation obligation.
AI system recording of event logs
The system logs events so that its behaviour can be reconstructed after the fact.
Evidence
Event logs that let you reconstruct a decision. Annex A makes this control optional, and excluding it leaves logging coverage limited. Keep it applicable if EU users are in scope.
A.7 · 5 controls
Data for AI systems.
Where training and operating data came from, whether you were allowed to use it, how good it is and what was done to it. Guardrail 3 of the Voluntary AI Safety Standard (data governance, quality and provenance) covers the same ground for Australia. The New Zealand Privacy Act 2020 applies whenever the data is personal information.
Data for development and enhancement of AI system
Data is managed as a governed asset across the whole lifecycle, from first collection to retraining.
Evidence
A data management record from collection through retraining. In New Zealand the thirteen information privacy principles apply to every use of personal information in AI. Purpose limitation is the one that catches retraining on data collected for something else.
Acquisition of data
Data is sourced lawfully, and the terms it came with are recorded.
Evidence
An acquisition record with the terms each dataset came with. Know the supplier's terms on data governance and whether the vendor on-shares your data.
Quality of data for AI systems
Training and input data are fit for the purpose the system serves, and the quality checks are documented.
Evidence
A quality report for each dataset, with the bias checks run and their results. Guardrail 3 of the Voluntary AI Safety Standard names data quality directly.
Data provenance
Where each dataset came from and how it changed on the way to the model, traceable end to end.
Evidence
A lineage record for each dataset. It is what lets you answer a Privacy Commissioner, an OAIC enquiry or an iwi partner asking what data the model learned from.
Data preparation
Cleaning, labelling and transformation steps are recorded, so that a result can be traced back through them.
Evidence
A labelling guide with reviewer sign-off. Labelling decisions are where bias enters unnoticed.
A.8 · 4 controls
Information for interested parties.
What users, affected people, customers and regulators are told, and how they tell you when something goes wrong. Guardrails 6 and 7 of the Voluntary AI Safety Standard (inform end users, and challenge processes) cover the same obligations in Australia.
System documentation and information for users
Users get what they need to use the system properly: intended use, limitations and what to do when it is wrong.
Evidence
A short user notice for each system, in plain language. Guardrail 6 asks organisations to inform end users.
External reporting
People outside the organisation can report an adverse impact, and the report reaches someone who can act.
Evidence
The existing complaints channel, extended to accept challenges to AI-enabled decisions, with its log. Guardrail 7 asks for processes that let people challenge those decisions.
Communication of incidents
Affected parties are told about incidents involving the AI system, within a defined time and through a defined channel.
Evidence
An incident communication procedure with timeframes and channels. APRA expects supplier contracts to include incident notification, and this control is the organisation's side of the same obligation. Keep it applicable if EU users are in scope.
Information for interested parties
Obligations to tell regulators, customers and the public about AI use are identified and met.
Evidence
A list of disclosure obligations and what was published against each. Commonwealth agencies publish AI transparency statements under the DTA policy. For a supplier to government, the equivalent record is what the agency will ask for to write its own statement.
A.9 · 3 controls
Use of AI systems.
Rules for how people inside the organisation use AI, and a boundary around what each system is for. APRA found staff use of enterprise AI tools lacked preventative controls and expects training on use, misuse and limitations.
Processes for responsible use of AI systems
Documented procedures for how staff may use AI, including approved tools, prohibited uses and what to do with sensitive data.
Evidence
An acceptable use procedure, a list of approved tools, and training records. Those records answer APRA's finding on staff use.
Objectives for responsible use of AI systems
Stated goals for use, so that "responsible" has a definition staff can be measured against.
Evidence
Written use objectives. The New Zealand Public Service AI Framework's principles, including human-centred values and accountability, give agencies ready-made objectives to adopt.
Intended use of the AI system
Each system is used within its documented purpose. Use outside that purpose is a change that goes back through the lifecycle gates.
Evidence
A purpose statement for each system in the inventory. Guardrail 5 of the Voluntary AI Safety Standard (human control and oversight) is the Australian counterpart.
A.10 · 3 controls
Third-party and customer relationships.
Who is responsible for what between you, your suppliers and your customers. For an APRA-regulated entity these three controls overlap with CPS 230, which has applied to all contracted service providers since 1 July 2026. For a New Zealand business, MBIE's AI Procurement Checklist covers the same questions.
Allocation of responsibilities
Responsibilities across the AI supply chain are allocated and written down, including the parties your suppliers depend on.
Evidence
A supply chain map for each system, down to fourth parties, which APRA expects. A SaaS vendor that calls a foundation-model API is two links, and both go on the map.
Suppliers
Suppliers of AI systems, components or data are evaluated before engagement and bound by contract terms that cover the AI risks.
Evidence
Supplier evaluations, and contracts with transparency, audit rights and incident notification, plus exit options that have been tested. APRA expects all four. MBIE's AI Procurement Checklist is the New Zealand equivalent for the evaluation step.
Customers
Customer requirements for the AI system are identified and met, and customers are told what they need to know to use it responsibly.
Evidence
Customer documentation for each AI product. Guardrail 8 of the Voluntary AI Safety Standard (supply chain transparency) describes this side. If you sell AI to an APRA-regulated entity, this control is how you answer its A.10.3 questions.
Questions about Annex A.
How many controls are in ISO 42001 Annex A?
38 controls under nine control objectives, numbered A.2 to A.10. The counts are A.2 (3), A.3 (2), A.4 (5), A.5 (4), A.6 (9), A.7 (5), A.8 (4), A.9 (3) and A.10 (3).
Why does the numbering start at A.2.2?
A.1 is the general clause that introduces Annex A, and the first item in each group (A.2.1, A.3.1 and so on) states the objective. The controls themselves begin at the second item of each group.
Are all 38 Annex A controls mandatory?
No. Clause 6.1.3 requires you to consider each control and record in the Statement of Applicability whether it applies. Exclusions must be justified, and auditors check the selection.
What is Annex B in ISO 42001?
Annex B is informative implementation guidance for each Annex A control. It describes how a control can be implemented without prescribing one method.
What is Annex C in ISO 42001?
Annex C is an informative catalogue of AI-related organisational objectives and risk sources, such as fairness, security, explainability, safety, privacy and environmental impact. It supplies candidate objectives and risk sources for the clause 6.1.2 risk assessment.
Thirty-eight decisions, each with a reason an auditor will read.
PolyGovern builds the Statement of Applicability with the APRA, ASIC, OAIC, MBIE and Privacy Commissioner references attached to each line, so every exclusion has been checked against the regulator before the auditor reads it.
Free · self-assessment
ISO 42001 readiness checklist.
26 scored questions across clauses 4 to 10 and the nine Annex A groups, with a readiness band at the end.
Open the checklistThirty-minute call
Statement of Applicability review.
A senior consultant walks your draft statement against the three checks in step 4 and tells you which exclusions will not survive stage 1.