Skip to content
A.6 AI system life cycle
ISO 42001A.6.2.3

ISO 42001 Annex A 6.2.3 Documentation of AI system design and development

What it says

The organization shall document the AI system design and development based on organizational objectives, documented requirements and specification criteria.

Quoted as published. Everything else on this page is written by Control Stack.

What it means

In plain English

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.

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.

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.

How to implement

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

Keep it running

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.

Evidence and audit

  1. Check 1 of 5What an auditor asks for

    Ask for

    Ask for the design and development documentation for a named AI system the organisation runs.

    Look at

    Whether it records the actual design decisions and the reasoning behind them, not just a finished-product description.

    Good evidence

    The documentation sets out the system's design choices and explains why each was made, dated and attributable to the people who made them.

  2. Check 2 of 5What an auditor asks for

    Ask for

    Ask for the organisation's written objectives for that AI system and the design documentation alongside them.

    Look at

    Whether the design documentation actually refers back to those business objectives rather than standing alone.

    Good evidence

    The design record visibly connects design choices to the organisational objectives the system was meant to achieve.

  3. Check 3 of 5What an auditor asks for

    Ask for

    Ask for the documented requirements and specification criteria the system was built against.

    Look at

    Whether they are written down, specific and measurable (for example accuracy targets or mandatory behaviours) rather than vague intentions.

    Good evidence

    A clear set of documented requirements and measurable specification criteria exists and predates or accompanies the build.

  4. Check 4 of 5What an auditor asks for

    Ask for

    Ask to see how a particular requirement or specification criterion is traced through to the design.

    Look at

    Whether a traceability matrix or equivalent shows each requirement mapped to the design element that meets it.

    Good evidence

    Every documented requirement and criterion can be traced to a design element, with no orphaned requirements.

  5. Check 5 of 5What an auditor asks for

    Ask for

    Ask the AI or technical lead how the design documentation is kept current and what happens when a requirement cannot be met.

    Look at

    Whether the change log is updated with each design change and whether unmet criteria are recorded with an approval.

    Good evidence

    The documentation is updated at each design change, and any deviation from a requirement is recorded with a named approver.

Mappings

Closest match in ISO/IEC 27001: A.8.27, Secure system architecture and engineering principles, which partially overlaps with this control.

ISO 27001

ISO/IEC 27001: 1 mapping

  • A.8.27Secure system architecture and engineering principlesPartially overlaps
ASD ISM

ASD Information Security Manual: 2 mappings

  • ISM-0041Maintain a system security plan with overview and controls annexPartially overlaps
  • ISM-2034Document and review security design in developmentPartially overlaps

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.

PolicyMint

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