ISO 42001 Annex A 6.2.2 AI system requirements and specification
What it says
The organization shall specify and document requirements for new AI systems or material enhancements to existing systems.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishBefore 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.
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.
Free. Save your status, tasks and notes.
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.
How to implement
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.
Keep it running
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.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the written requirements specification for the most recently started or most recently changed AI system.
Look at
Whether it sets out both what the system must do and non-functional limits such as a stated accuracy target, permitted data sources, and privacy or fairness constraints, not just a feature wish-list.
Good evidence
The 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.
- Check 2 of 5What an auditor asks for
Ask for
Ask for the change or enhancement record for a material change made to an existing AI system in the last year.
Look at
Whether the original requirements were reopened and revised for that change rather than the change going ahead against the version-one document.
Good evidence
The record links to a dated, revised requirements version that reflects the enhancement and shows fresh approval.
- Check 3 of 5What an auditor asks for
Ask for
Ask the person who owns the AI system to show how each requirement will be confirmed as met.
Look at
Whether requirements are tied to acceptance criteria or tests, so an unmet requirement would be caught before go-live.
Good evidence
Each documented requirement maps to an acceptance check or test case, and any requirement that could not be met is recorded with the decision taken.
- Check 4 of 5What an auditor asks for
Ask for
Ask for the requirements register or baseline covering AI systems in scope.
Look at
Whether every in-scope new system and material enhancement has a current documented requirements entry, or whether some systems have none.
Good evidence
The register lists each in-scope system with a current, versioned requirements document and no live system is missing one.
- Check 5 of 5What an auditor asks for
Ask for
Ask for the constraints recorded for a customer-facing or decision-making AI system.
Look at
Whether the document states data the system may not use and decisions it must not make without human review.
Good evidence
The specification records explicit prohibitions and human-review points, showing privacy and safety limits were specified up front, not added later.
Mappings
Closest match in ISO/IEC 27001: A.5.8, Information security in project management, which partially overlaps with this control.
ISO/IEC 27001: 2 mappings
This control partially overlaps 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 enhancements to existing systems. Annex A 5.8 (ISO/IEC 27001:2022) requires integrating information security into project management processes, including defining security requirements as part of project deliverables. They overlap where AI system requirements include information security aspects managed through project processes, although Annex A 6.2.2 has a specific focus on AI systems.
This control partially overlaps A.8.26.
Annex A 6.2.2's requirement to document AI system specifications overlaps with Annex A 8.26's focus on specifying and approving security requirements during application development.
ASD Information Security Manual: 4 mappings
This control partially overlaps ISM-0009.
ISM-0009 requires system owners, with the authorising officer, to identify supplementary security controls based on the system's nature, operating environment and organisational risk tolerance. ISO/IEC 42001 Annex A 6.2.2 relates because specifying and documenting AI system requirements commonly includes identifying additional security controls needed for the AI system's context and risk profile. The overlap is that both drive context-specific control selection/definition, but Annex A 6.2.2 is AI-system requirements-focused while ISM-0009 is broader to any system and explicitly anchored to authorising officer consultation for supplementary controls.
This control partially overlaps ISM-0041.
Annex A 6.2.2 requires documented requirements/specifications for new or materially enhanced AI systems. ISM-0041 requires a system security plan describing the system purpose, boundaries, management approach, and applicable controls. They overlap because AI system specifications inform the system security plan, particularly for security, boundaries, and control selection. ISM-0041 covers security planning for any system, while Annex A 6.2.2 focuses on broader AI system requirements.
This control partially overlaps ISM-0072.
Annex A 6.2.2 requires documenting requirements for new AI systems or material enhancements, often including external services, data handling, and constraints. ISM-0072 mandates documenting security requirements in service provider contracts and reviewing them for fitness for purpose. They overlap when AI system requirements must flow down into contractual security requirements, especially for vendors handling AI components.
This control partially overlaps ISM-2034.
Both Annex A 6.2.2 and ISM-2034 require maintained documentation, with the former focusing on AI system specifications and the latter on security design decisions. They overlap where design decisions trace back to documented AI requirements.
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