AI System Verification and Validation
Define 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.
Plain language
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.
Framework
ISO/IEC 42001:2023
Control effect
Preventative
Classifications
N/A
Official last update
01 Dec 2023
Control Stack last updated
19 June 2026
Official control statement
The organisation shall define and document verification and validation measures for the AI system and specify criteria for their use.
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.
Operational notes
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.
Implementation tips
- 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.
Audit / evidence tips
- AskRequest the verification and validation plan for a named AI system.GoodThe plan ties every test to a defined acceptance criterion (such as a minimum accuracy or error rate) and states when each check is triggered.
- AskAsk for the test result records that supported the most recent decision to approve or release this AI system.GoodEach 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.
- AskAsk how verification and validation are repeated after a model or its data feed changes.GoodEvery model or data change is linked to re-run checks before the updated system goes back into use.
- AskAsk how the criteria distinguish technical verification from real-world validation.GoodValidation evidence shows the system meets the user's real need, separate from the technical accuracy figures.
- AskReview the contract for any third-party AI model in use.GoodThe contract requires the supplier to provide test evidence and notify changes so you can re-verify and re-validate.
Cross-framework mappings
How Annex A 6.2.4 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
sync_altPartially overlaps(1)expand_less | ||
| Annex 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 ap... | |
ASD ISM
| Control | Notes | Details |
|---|---|---|
sync_altPartially overlaps(4)expand_less | ||
| ISM-0402 | Annex A 6.2.4 requires documented AI system verification and validation measures and criteria for their use | |
| ISM-1524 | Annex A 6.2.4 requires defined and documented verification and validation measures to confirm an AI system performs as intended against s... | |
| 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... | |
| ISM-2102 | Annex A 6.2.4 requires the organisation to define and document verification and validation measures for an AI system, including criteria ... | |
handshakeSupports(1)expand_less | ||
| ISM-2113 | ISM-2113 requires AI applications to flag risky actions and obtain human approval prior to execution | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
Related ISO 42001 controls in A.6 AI system life cycle
See all A.6 AI system life cycle controls, or browse the full ISO/IEC 42001:2023 library.
Want to implement this AI control?
Mindset Cyber runs PECB-accredited ISO/IEC 42001 training that maps directly to the AI controls in this library.