ISO 42001 Annex A 6.2.4 AI system verification and validation
What it says
The organization shall define and document verification and validation measures for the AI system and specify criteria for their use.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishDefine and document how you will verify (confirm the AI system is built correctly) and validate (confirm it does what users actually need), and set clear criteria for when each measure applies and what counts as a pass.
This control asks you to prove that your AI system both works correctly and is fit for the real job it is meant to do. Verification confirms the system meets its technical specification, for example that a model achieves the accuracy you designed for on held-out test data. Validation confirms the system actually solves the user's problem in the real world, for example that a stock-ordering model genuinely reduces overstock for your shop rather than just scoring well on a benchmark. The control has two parts you must both satisfy: write down the specific checks you will run, and write down the criteria that govern them, meaning when each check is triggered, who runs it, and what result counts as a pass or a fail. Without documented criteria, a check that returns a poor number still has no agreed line that forces someone to stop or fix the system.
Free. Save your status, tasks and notes.
Why it matters
Without documented verification and validation measures and clear pass or fail criteria, a faulty AI system can ship and keep running because no one agreed in advance what "working" means or who must act when a number looks wrong. A loan-scoring or candidate-screening model quietly performs worse for one cohort and runs unchecked, producing discriminatory outcomes that surface only as an OAIC (Office of the Australian Information Commissioner) complaint. Setting a criterion such as a hypothetical minimum of 95 per cent accuracy on a representative test set, chosen to fit your own risk appetite rather than any fixed standard, turns a vague "it seems fine" into a defensible go or no-go decision you can show an auditor or regulator.
How to implement
Write a short verification and validation plan that lists each check next to a clear pass or fail line, for example a stated minimum accuracy on held-out test data, so a poor result forces a decision instead of a shrug.
Pick the threshold to suit your own risk, not a number copied from elsewhere.
Separate the two questions when defining tests: verification asks whether the system meets its specification, and validation asks whether it solves the user's real problem.
Run a pilot or user-acceptance step so a model that scores well on a benchmark still has to prove it works for the actual task.
Record every test result against its criterion with the observed value, the date, and a named approver, so the go or no-go decision has an audit trail rather than living in someone's memory.
Re-run the relevant checks and re-confirm the criteria whenever the model, its training data, or the upstream data feed changes, because a shift in input data can break a system that previously passed.
Add a clause to supplier contracts requiring them to disclose changes to their AI model and share enough test evidence for you to apply your own acceptance criteria when they update their algorithm.
Keep it running
Keep the verification and validation plan and its acceptance criteria in one document, version controlled, so you can show what the thresholds were at the time a model was approved. Re-run the relevant checks and re-confirm the criteria still hold whenever the model, its training data, or the upstream data feed changes, since a drift in input data can break a system that previously passed. Record each result against its criterion (pass or fail, the value observed, the date, and who signed off) so the decision trail is auditable. Where a supplier provides the model, agree in the contract that they will share enough test evidence for you to apply your own acceptance criteria.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Request the verification and validation plan for a named AI system.
Look at
Whether it lists specific tests and, for each, a documented pass or fail criterion rather than just describing checks in general.
Good evidence
The plan ties every test to a defined acceptance criterion (such as a minimum accuracy or error rate) and states when each check is triggered.
- Check 2 of 5What an auditor asks for
Ask for
Ask for the test result records that supported the most recent decision to approve or release this AI system.
Look at
Whether results are recorded against their criteria, with the observed value, date, and a named approver.
Good evidence
Each result shows the value measured, the criterion it was checked against, the date, and the person who signed off the go or no-go decision.
- Check 3 of 5What an auditor asks for
Ask for
Ask how verification and validation are repeated after a model or its data feed changes.
Look at
Whether a change log links updates to fresh test runs and re-confirmed criteria.
Good evidence
Every model or data change is linked to re-run checks before the updated system goes back into use.
- Check 4 of 5What an auditor asks for
Ask for
Ask how the criteria distinguish technical verification from real-world validation.
Look at
Whether validation evidence reflects actual user needs and not only benchmark scores.
Good evidence
Validation evidence shows the system meets the user's real need, separate from the technical accuracy figures.
- Check 5 of 5What an auditor asks for
Ask for
Review the contract for any third-party AI model in use.
Look at
Whether it obliges the supplier to share test evidence and disclose changes so you can re-apply your criteria.
Good evidence
The contract requires the supplier to provide test evidence and notify changes so you can re-verify and re-validate.
Mappings
Closest match in ISO/IEC 27001: A.8.29, Security testing in development and acceptance, which partially overlaps with this control.
ISO/IEC 27001: 1 mapping
This control partially overlaps A.8.29.
Annex A 6.2.4 requires defining and documenting verification and validation measures for an AI system, with criteria for when they are applied. ISO/IEC 27001 Annex A 8.29 requires defined and implemented security testing processes in the development life cycle, which is a key subset of verification activities for AI system software and infrastructure. The overlap is partial because Annex A 8.29 is limited to security testing in development/acceptance, while Annex A 6.2.4 also covers AI-specific validation of intended purpose, model behaviour, and non-security quality attributes.
ASD Information Security Manual: 3 mappings
This control partially overlaps ISM-1524.
Annex A 6.2.4 requires defined and documented verification and validation measures to confirm an AI system performs as intended against specified criteria. ISM-1524 requires rigorous security testing of content filters to ensure they perform as expected and cannot be bypassed, which aligns with validating a specific safety/security control that may be part of an AI system's boundary protections (e.g., prompt/output filtering). ISM-1524 is narrower and security-bypass oriented, whereas Annex A 6.2.4 covers the overall AI system V&V lifecycle, including functional and quality criteria beyond filter robustness.
This control partially overlaps ISM-1636.
Annex A 6.2.4 requires the organisation to define and document AI system verification and validation measures and criteria to confirm the system operates as intended. ISM-1636 requires security assessment of system controls and the operating environment to determine if controls are implemented correctly and operating as intended, which overlaps strongly with the 'verification' aspect for security controls within an AI system deployment. ISM-1636 is security-control assurance for systems generally, while Annex A 6.2.4 is AI-system-specific and also includes broader validation (e.g., model performance, bias, robustness, intended use).
This control partially overlaps ISM-2102.
Annex A 6.2.4 requires the organisation to define and document verification and validation measures for an AI system, including criteria for when those measures are used. ISM-2102 mandates periodic testing of software artefacts (e.g., via SAST/DAST/SCA) to detect known weaknesses throughout the SDLC, which is one concrete class of verification activity relevant to AI system components. The overlap is limited because ISM-2102 focuses on vulnerability/weakness detection in software artefacts, while Annex A 6.2.4 also covers non-security validation (fitness for purpose, performance, behaviour, model evaluation) and broader AI-system V&V criteria.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.
Get help with this control
ISO 42001 training
Mindset Cyber runs PECB-accredited ISO/IEC 42001 training that maps directly to the AI controls in this library.
Turn this control into your AI policy
PolicyMint writes customised ISO 42001 policy documents for your business, audit-ready and exported in your branding (Word, PDF, Excel). Skip the blank page and the boilerplate that does not fit. First document free.
Draft your ISO 42001 documents