ISO 42001 Annex A 6.1.3 Processes for responsible AI system design and development
What it says
The organization shall define and document the specific processes for the responsible design and development of the AI system.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishWrite down the specific step-by-step processes your teams follow to design and build each AI (artificial intelligence) system responsibly, so responsible practices are built into how the system is made rather than left to chance.
This control is about how your artificial intelligence (AI) systems get designed and built, and making sure responsible practices are baked into that process rather than added as an afterthought. "Responsible" here means the way you build the AI deliberately guards against harm: checking the data and model for bias (the system unfairly favouring or disadvantaging some groups), testing that it is safe and accurate before release, building in human oversight (a person who can review or override the AI), and being able to explain how it reaches its results. The control asks you to define and document the specific processes your teams follow to do this: in plain terms, a written, repeatable set of steps that says, for each AI system, how it moves from idea to design to a built, tested system, and where the responsibility checks happen along the way. It is not enough to describe the finished AI; you have to describe the process used to create it. For example, your documented process might require a design review before coding starts, a bias and fairness test before training is signed off, a safety and accuracy test before release, and a named person who must approve human-oversight controls. Writing this down means every project follows the same responsible steps, and you can show an auditor or regulator exactly how each system was built, not just claim it was done carefully.
Free. Save your status, tasks and notes.
Why it matters
If you never define a responsible design-and-development process, each AI project is built however its team decides on the day, and the safety and fairness checks that should be mandatory simply get skipped under deadline pressure. A model can then go live without anyone testing it for bias against a protected group or building in a way for a person to override it, so a discriminatory hiring or credit-scoring tool ships unnoticed and is only discovered after it has harmed applicants, exposing the organisation to an OAIC complaint and forcing the system to be withdrawn and rebuilt.
How to implement
The person who owns your AI work (often called the AI lead, the manager accountable for how AI is built and run) should write a single design-and-development procedure that lays out the stages every AI project must pass through (concept, design review, build, testing, and release) and the responsible-design check that has to happen at each stage.
Build the responsible practices directly into the process steps: the procedure should require a bias and fairness test (checking the AI does not unfairly disadvantage particular groups) before a model is trained, and a safety and accuracy test before it is released, so these checks are mandatory rather than optional.
Whoever runs each project should record evidence as each stage is completed (the signed-off design review, the test reports, and the release approval) so the project file shows the responsible process was genuinely followed, not just intended.
When designing each system, the development team should decide and document how a person can oversee, review, or override the AI's outputs, and how the system's results can be explained, treating these as design decisions made early rather than features added after the build.
The AI lead should set named sign-off points so a project cannot move to the next stage until the right person has approved it (for example approval to begin training and approval to release) which stops any project quietly skipping a responsible-design step under deadline pressure.
Keep it running
Treat the documented process as a living procedure: when you adopt a new model type (for example a generative AI tool), face a new regulatory expectation, or learn from an incident, update the process steps and the responsibility checkpoints rather than leaving the document frozen. Make sure the process names who must sign off at each responsible-design gate (design review, bias and fairness testing, safety and accuracy testing, human-oversight approval) so a project cannot quietly skip a stage. Periodically check a sample of recent projects against the documented process to confirm teams are actually following the steps, not just that the document exists.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the documented process or procedure your organisation follows to design and develop its AI systems responsibly.
Look at
Whether it sets out specific, repeatable stages (such as design review, bias testing, safety and accuracy testing, release approval) rather than just describing one finished system.
Good evidence
There is a written, repeatable design-and-development process that names the stages and the responsible-design check required at each one.
- Check 2 of 5What an auditor asks for
Ask for
Pick one recent AI system and ask for the records proving each step of that documented process was actually carried out for it.
Look at
Whether you can see real artefacts for each stage, such as a completed design review, a bias and fairness test report, and a safety and accuracy test before go-live.
Good evidence
The project file shows each documented stage was completed in order, with dated evidence for the responsible-design checks.
- Check 3 of 5What an auditor asks for
Ask for
Ask who must approve a project before it moves from one stage to the next, and for evidence those approvals occurred.
Look at
Whether named sign-off points exist (for example approval to begin training and approval to release) and whether a project could skip a stage without anyone noticing.
Good evidence
Defined approval gates name who signs off at each stage, and the records show approvals were given before the project advanced.
- Check 4 of 5What an auditor asks for
Ask for
Ask how human oversight and the ability to explain the AI's results were built in during development.
Look at
Whether the process requires a documented way for a person to review or override the AI, decided during design rather than bolted on afterwards.
Good evidence
The process requires human-oversight and explainability controls to be designed in, and the project records show they were built and tested before release.
- Check 5 of 5What an auditor asks for
Ask for
Ask when the documented process itself was last reviewed and updated.
Look at
Whether updates were prompted by real events such as adopting a new AI type, a regulatory change, or lessons from an incident, rather than the document sitting unchanged.
Good evidence
The process has a dated review history showing it was updated when AI types, regulations, or incidents changed what responsible development requires.
Mappings
Closest match in ASD Information Security Manual: ISM-0401, Implement secure by design in software development, which partially overlaps with this control.
ASD Information Security Manual: 1 mapping
This control partially overlaps ISM-0401.
ISO/IEC 42001 Annex A 6.1.3 requires the organisation to define and document specific processes for the responsible design and development of AI systems. ISM-0401 requires Secure by Design principles and practices to be followed throughout the software development life cycle, which would form the security part of those documented AI development processes. Annex A 6.1.3 also covers responsible AI concerns beyond security, while ISM-0401 applies to all software, not only AI systems.
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



