AI System Requirements and Specification
Before building a new AI system or materially changing an existing one, write down exactly what it must do and what it must not do, and keep that specification on file.
Plain language
When you start a new AI project or make a big change to one you already run, this control says you must write down what the system needs to deliver before work begins. That means setting out, in a document, the tasks it has to perform, how accurate it needs to be, what data it can use, and the privacy, safety and fairness limits it must respect. A material enhancement (a change big enough to alter how the system behaves or who it affects) triggers the same step, so the written requirements are revisited rather than left frozen at version one.
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 specify and document requirements for new AI systems or material enhancements to existing systems.
Why it matters
Without a written requirements specification, teams build or buy AI against assumptions that were never agreed, and a gap such as an unstated accuracy floor or an unstated rule against using a special-category data field is only discovered after the system is live and a wrong decision has already affected real people. A recruitment-screening or benefits-eligibility model can quietly fall short of an accuracy or fairness need that nobody documented, producing a cohort of incorrectly rejected applicants and a possible OAIC privacy complaint once individuals learn their data drove an automated outcome they were never told about. Fixing it after deployment usually means withdrawing the system and rebuilding from scratch.
Operational notes
Keep the requirements for each AI system in a versioned baseline (a requirements register) so you can see what was agreed and when it changed. Treat every material enhancement or significant change request as a trigger to reopen that baseline, re-validate the functional needs (what the system must do) and the non-functional needs (accuracy targets, latency, security, privacy and fairness limits), and record who signed off the new version. Where a requirement cannot be met, note the gap and the decision taken rather than deleting it, so the trade-off is traceable. Link each requirement to the test or acceptance check that will later prove it was satisfied.
Implementation tips
- Bring the people who will actually use the system together with the team that will build or buy it, and write down what the system has to achieve before any development or purchase starts; capturing those needs as a short numbered list keeps them testable later.
- Make sure the specification covers more than features: have the person responsible for the AI system record the accuracy or quality the model must reach, the data sources it is allowed to use, and the privacy, safety and fairness limits it must stay within, since these non-functional needs are what usually get missed.
- Treat any material enhancement as a reason to reopen the document. When someone raises a significant change request, the project owner should revisit the requirements, mark what has changed, and have the new version approved rather than letting the old one stand.
- Write each requirement so it can be checked, and have whoever leads testing tie every requirement to an acceptance criterion, so a missed accuracy or privacy need is caught before the system goes live instead of after.
- Where a requirement cannot be met, the system owner should record the gap and the decision taken instead of quietly dropping it, so the trade-off stays visible to whoever later approves the system for use.
Audit / evidence tips
- AskAsk for the written requirements specification for the most recently started or most recently changed AI system.GoodThe specification names concrete functional and non-functional requirements, carries a version number, and is signed off by a named owner before build or procurement began.
- AskAsk for the change or enhancement record for a material change made to an existing AI system in the last year.GoodThe record links to a dated, revised requirements version that reflects the enhancement and shows fresh approval.
- AskAsk the person who owns the AI system to show how each requirement will be confirmed as met.GoodEach documented requirement maps to an acceptance check or test case, and any requirement that could not be met is recorded with the decision taken.
- AskAsk for the requirements register or baseline covering AI systems in scope.GoodThe register lists each in-scope system with a current, versioned requirements document and no live system is missing one.
- AskAsk for the constraints recorded for a customer-facing or decision-making AI system.GoodThe specification records explicit prohibitions and human-review points, showing privacy and safety limits were specified up front, not added later.
Cross-framework mappings
How Annex A 6.2.2 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
sync_altPartially overlaps(2)expand_less | ||
| Annex A 5.8 | Annex A 6.2.2 (ISO/IEC 42001:2023) requires the organisation to specify and document requirements for new AI systems or material enhancem... | |
| Annex A 5.23 | Annex A 6.2.2 requires specifying and documenting requirements for new AI systems or material enhancements | |
handshakeSupports(2)expand_less | ||
| Annex A 5.1 | Annex A 6.2.2 requires specifying and documenting requirements for AI systems | |
| Annex A 5.31 | Annex A 6.2.2 requires documenting requirements for AI systems, including compliance-related aspects | |
ASD ISM
| Control | Notes | Details |
|---|---|---|
sync_altPartially overlaps(2)expand_less | ||
| ISM-0041 | Annex A 6.2.2 requires documented requirements/specifications for new or materially enhanced AI systems | |
| ISM-0072 | Annex A 6.2.2 requires documenting requirements for new AI systems or material enhancements, often including external services, data hand... | |
handshakeSupports(2)expand_less | ||
| ISM-0009 | Annex A 6.2.2 requires the organisation to specify and document requirements for new AI systems or material enhancements | |
| ISM-2113 | ISM-2113 requires AI applications to seek human approval for defined risky actions pre-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.