ISO 42001 Annex A 6.1.2 Objectives for responsible development of AI systems
What it says
The organization shall identify and document objectives to guide the responsible development AI systems, and take those objectives into account and integrate measures to achieve them in the development life cycle.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishWrite down the responsible-development goals your AI systems must meet, then build checkpoints into each stage of development so those goals actually shape what gets built and released.
This control asks you to decide, up front, what "responsible" means for the AI you build (for example that it must be accurate, fair across different groups of people, explainable, and safe) and to write those goals down. It then asks you to weave those goals into the way you actually build the system, from the first design sketch through to the moment someone signs off the release, so the goals are not just a poster on the wall. The aim is that a developer cannot quietly skip them, because each stage of building the AI has to show it has met the goals before work moves on.
Free. Save your status, tasks and notes.
Why it matters
Without documented responsible-development objectives wired into the build, a recruitment-screening model can reach production having been trained on years of biased hiring data with no fairness goal ever set or tested, so it systematically down-ranks women and older applicants, the kind of automated decision that draws an OAIC complaint or a discrimination claim once a rejected cohort works out why they keep being filtered. Teams also end up reverse-engineering goals like explainability or human-override after launch, which usually means a costly rebuild or pulling the system. When the objective was never written down, there is also nothing to test against, so no one can prove the AI was fit to release.
How to implement
Have the AI product owner draft a short, specific list of responsible-development objectives for each AI system (things like a minimum accuracy level, fairness across the groups the system affects, explainability of its decisions, security, and where a human must stay in the loop) and get a named accountable owner to approve it so the goals are settled before coding starts.
Get the development lead to build those objectives into your stage-gate or definition-of-done so each phase of the life cycle has to satisfy them: the design stage records how the architecture will meet explainability and oversight, the data-sourcing stage checks training data against the fairness objective, the training and testing stages produce results measured against the accuracy and bias targets, and release is blocked until each objective is confirmed.
Ask the data and model engineers to translate each objective into a concrete check they run during the build: for example a bias test across the named groups before a model is accepted, or a documented data-provenance record (where the training data came from and that it was lawful to use) that satisfies a data-quality objective.
Have the test or QA lead produce evidence against the objectives before release (a fairness report, an accuracy benchmark, an explainability review) and attach it to the release sign-off so no system ships without showing it met the goals.
When a project cannot meet an objective in the planned timeframe, have the accountable owner record the deviation, the reason, and a remediation date rather than dropping the objective, so the gate stays meaningful and the trade-off is on the record.
Keep it running
Keep the objectives in a single living document tied to each AI system, and revisit them whenever the system's purpose, training data source, or user population changes, not only at an annual review. Make the development-stage gates real by recording, against each objective, the evidence that satisfied it (a fairness test result, an explainability review, a sign-off) before the system moves from one stage to the next. When a project genuinely cannot meet an objective, record the deviation and who accepted it rather than letting the gate be skipped silently, so the trade-off is visible later.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask the AI system owner for the documented responsible-development objectives for a specific AI system.
Look at
Whether the objectives are concrete and measurable for this system (for example a stated accuracy target, named groups fairness must hold across, an explainability or human-oversight requirement) rather than a generic statement that the AI should be ethical.
Good evidence
There is a dated, approved list of responsible-development objectives specific to the AI system, covering qualities such as accuracy, fairness, explainability, safety and human oversight.
- Check 2 of 5What an auditor asks for
Ask for
Ask for the development life-cycle or stage-gate checklist that ties each objective to a development stage.
Look at
Whether each objective is mapped to a stage (design, data sourcing, training, testing, release) and whether there is a record that the objective was checked before the stage was passed.
Good evidence
Each objective is assigned to a development stage and the checklist shows it was verified, with evidence, before work moved on.
- Check 3 of 5What an auditor asks for
Ask for
Ask to see the test or evaluation results produced before the system was released.
Look at
Whether the tests actually measure the system against the stated objectives, for example a bias test mapped to the fairness objective, not just a generic functional test.
Good evidence
Pre-release test results map directly to the documented objectives and show each was assessed before sign-off.
- Check 4 of 5What an auditor asks for
Ask for
Ask for the release sign-off record for the AI system.
Look at
Whether sign-off confirms the objectives were met, and how any objective that was not met was handled.
Good evidence
The sign-off confirms each objective was met, or records a deviation that a named approver formally accepted.
- Check 5 of 5What an auditor asks for
Ask for
Ask the development team to walk through how an objective changed a build decision.
Look at
Whether they can point to a real design or training choice driven by an objective, rather than describing the objectives as documentation they file and ignore.
Good evidence
The team can name a concrete build decision (such as choosing an explainable model or rebalancing training data) that an objective directly drove.
Mappings
Closest match in ASD Information Security Manual: ISM-2074, Develop and maintain AI usage policy, which partially overlaps with this control.
ASD Information Security Manual: 2 mappings
This control partially overlaps ISM-2074.
Annex A 6.1.2 requires the organisation to set and document responsible-development objectives for AI systems and integrate them into the development life cycle through measures and checkpoints. ISM-2074 requires an AI usage policy, which can operationalise organisational expectations and constraints that inform those responsible-development objectives and the acceptance criteria for release. The overlap is AI governance and documented intent, but ISM-2074 focuses on use and user behaviour post-deployment rather than SDLC integration of development objectives.
This control partially overlaps ISM-2120.
Annex A 6.1.2 requires the organisation to document responsible-development objectives for AI systems and integrate measures to achieve them throughout the AI development life cycle. ISM-2120 similarly requires a secure software development policy to be developed, implemented and maintained, which can be one of the key measures used to realise responsible-development objectives during build and release activities. The overlap is in SDLC governance and embedding requirements into development, but Annex A 6.1.2 is AI-responsibility focused (e.g. safety, fairness, transparency) while ISM-2120 is broader secure software assurance and is not AI-specific.
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