Documentation of AI System Design and Development
Write down how each AI system was designed and built, and show that those design choices trace back to your organisation's objectives, its documented requirements, and the specification criteria the system was meant to meet.
Plain language
This control asks you to keep a written record of how your artificial intelligence (AI) system was designed and built, and to tie that record to three specific things named in the standard. The first is your organisational objectives, meaning what the business actually wanted the AI to achieve, for example "cut loan-application processing time without increasing wrongful rejections". The second is documented requirements, which are the agreed, written-down things the system must do or must not do, such as "must give a reason for every declined application" or "must not use a customer's postcode as an input". The third is specification criteria, which are the measurable targets and design rules the system was checked against, for example "accuracy of at least 95 per cent on the test set" or "responses under two seconds". The point is that someone reviewing the system later (a new engineer, your board, an auditor, or a regulator) can open the documentation and see not just what was built but why each design decision was made and which objective or requirement it serves. Without this, design knowledge lives only in the heads of the people who built it, and when they leave or when something goes wrong you cannot tell whether the system was built the way it was supposed to be.
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 document the AI system design and development based on organisational objectives, documented requirements and specification criteria.
Why it matters
When design and development are not documented against the objectives, requirements and specification criteria, no one can later prove the system was built to do what was agreed, or trace a fault back to the decision that caused it. A bank that cannot show its credit-scoring model was designed to the documented "must give a reason for every decline" requirement has no way to answer an affected applicant or an OAIC enquiry, and may have to pull the model from production while it reconstructs the design from scratch. The departure of one or two key engineers can leave the organisation unable to safely change or rebuild a system it still depends on.
Operational notes
Anchor the design record explicitly to the three things the statement names: keep a traceability link from each major design decision back to the organisational objective, documented requirement, or specification criterion it satisfies, so gaps are visible at a glance. Update the documentation as part of each design change rather than at year-end, because an out-of-date design record is worse than none. Where a requirement or criterion could not be met, record the deviation and who approved it, so the trade-off is a deliberate, evidenced decision rather than an unexplained gap.
Implementation tips
- The AI or technical lead should keep a living design document for each AI system that captures the key design decisions and, for each one, records which organisational objective, documented requirement, or specification criterion it serves, so the reasoning is preserved rather than lost in people's heads.
- Before development starts, the product owner should write down the organisational objectives the system must achieve and turn them into specific documented requirements, such as mandatory behaviours, prohibited inputs, or decisions the AI must explain, so there is a clear baseline to design against.
- Whoever owns the technical specification should set measurable specification criteria the design will be checked against, for example a minimum accuracy on a test set or a maximum response time, and record them so design choices can later be judged against a concrete target.
- The technical lead should maintain a simple traceability matrix that maps each documented requirement and specification criterion to the part of the design that satisfies it, and review it during design so any requirement with no matching design element is caught early.
- When a design change is made or a requirement cannot be met, the engineer making the change should update the design record there and then, noting the reason and, for any deviation from a requirement or criterion, the person who approved it, so the documentation stays accurate and decisions are evidenced.
Audit / evidence tips
- AskAsk for the design and development documentation for a named AI system the organisation runs.GoodThe documentation sets out the system's design choices and explains why each was made, dated and attributable to the people who made them.
- AskAsk for the organisation's written objectives for that AI system and the design documentation alongside them.GoodThe design record visibly connects design choices to the organisational objectives the system was meant to achieve.
- AskAsk for the documented requirements and specification criteria the system was built against.GoodA clear set of documented requirements and measurable specification criteria exists and predates or accompanies the build.
- AskAsk to see how a particular requirement or specification criterion is traced through to the design.GoodEvery documented requirement and criterion can be traced to a design element, with no orphaned requirements.
- AskAsk the AI or technical lead how the design documentation is kept current and what happens when a requirement cannot be met.GoodThe documentation is updated at each design change, and any deviation from a requirement is recorded with a named approver.
Cross-framework mappings
How Annex A 6.2.3 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ASD ISM
| Control | Notes | Details |
|---|---|---|
sync_altPartially overlaps(1)expand_less | ||
| ISM-0041 | Annex A 6.2.3 requires the organisation to document AI system design and development based on organisational objectives, documented requi... | |
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.