A.6.1.3 responsible AI design processes: evidence

What ISO 42001 A.6.1.3 asks for, and why it is hard to evidence

If you are the compliance lead or engineering manager who must show an auditor or customer how AI systems are designed and built, A.6.1.3 is the control that asks for your actual process on paper. Control A.6.1.3 asks the organization to define and document the specific processes it uses for the responsible design and development of AI systems. It is distinct from A.6.1.2, which covers the objectives that guide responsible development, such as fairness, security or transparency. A.6.1.2 says what good looks like; A.6.1.3 says how your teams get there, step by step, and where decisions are made. The exact wording lives in ISO/IEC 42001:2023, available from ISO, and you should read the control text there rather than rely on a paraphrase.

The risk behind the control is straightforward. An AI system can move from idea to production without anyone defining where human oversight applies, which tests must pass, or who decides whether it is safe to proceed. When that happens, release decisions are informal, and nobody can later explain why a model went live or why it was pulled back. A well-written process addresses these gaps by naming the checkpoints: an oversight review before design is locked, defined testing gates, and a documented approval to proceed or stop at each stage. The NIST crosswalk to ISO/IEC 42001 links this control to human oversight processes, test, evaluation, verification and validation, and the decision whether to proceed, which gives you a useful checklist for what the process should cover.

The difficulty is usually not writing the document. It is making the process real and proving it. Teams often produce a design procedure that describes ideal steps, but engineers follow whatever their pipeline and sprint rhythm allow, so the written process and the actual practice drift apart. The second problem is missing records: a gate was passed, but no one captured who approved it, what evidence they reviewed, or what conditions were attached. Auditors test both the document and the trail. Before you commit to a scope, confirm with your certification body how it expects process conformity to be sampled, and check which of your existing change, code review and release tools already generate approval records you can reuse.

Which AI systems, teams and suppliers the A.6.1.3 processes must cover

A.6.1.3 applies to whatever the organization decides is in scope for responsible AI design and development, so the scope itself is the first decision to document. The cards below cover the decisions that shape how much work the process requires, and each one should be recorded with its reasoning in the statement of applicability under clause 6.1.3.

In-house builds versus adapted systems

Decide whether the process covers only systems the organization builds from scratch or also systems it fine-tunes, configures or wraps around a third-party model. Fine-tuning changes model behavior, so it normally counts as development. A thin integration that only calls a hosted API may fall under the use controls instead. Write the boundary down with a worked example for each pattern, labeled as illustrative, so an assessor can follow the logic.

Teams that must follow the process

Name the roles that must work through the documented process: product owners who approve requirements, data scientists who build and evaluate models, security engineers who run adversarial tests, and legal or privacy staff who sign off on use restrictions. A process that only data science follows will not show the cross-functional oversight the control expects. Confirm each role's gate responsibilities in writing.

Material changes to existing systems

Define what counts as a material change that re-enters the process, such as a new model version, a changed training dataset, a new intended purpose or a new user population. Routine retraining on the same data may not qualify, but the threshold must be written and applied consistently. Without this rule, systems in production drift outside the approved design with no gate that catches the change.

Supplier-built components

Decide how models, datasets, libraries and APIs supplied by third parties enter the process. Organizations usually cannot apply their own design records to a vendor's training pipeline, so the process should require supplier documentation, a defined intake review and clear limits on what the organization can verify. Ask suppliers which parts of the lifecycle they document and what they will share under contract.

Gating and exclusion justifications

Record which AI systems are excluded from the process and why, such as prototypes that never reach users or internal tools with no decision impact. Each exclusion needs a stated basis, reviewed on a set schedule. Scope decisions drive the effort: a narrow scope means fewer gates and documents, while a broad scope means more reviews and more evidence to maintain. Ask any implementation partner to price against the written scope.

How an assessor tests the A.6.1.3 design processes

This table sets out each step an assessor takes to test A.6.1.3, the evidence requested at each step, and the findings that most often appear. Read it as a sequence: the documented process comes first, then proof that it is approved, applied to real projects and understood by the people who run it.

Assessor step	What the assessor checks	Evidence requested and common findings
Confirm a documented process exists	A written process for responsible AI design and development that covers the design and development stages, not only deployment	Process document with version history. Finding: processes exist only as tribal knowledge or as informal team practices
Check approval and currency	The process is approved by an accountable owner and reflects current AI products, teams and risk decisions	Approval record, revision date and review log. Finding: the document was approved years ago and no longer matches how teams build AI
Confirm gates are defined	Each gate, such as design review, testing gate and approval to proceed, has entry criteria, owners and outcomes	Gate checklists and gate definitions. Finding: gates are named in the process but have no criteria an assessor can test
Sample real AI projects	A selection of live or recent AI projects shows that gates were applied in practice, with dated records	Project tickets, review minutes and signed gate checklists for each sampled project. Finding: gates were skipped under deadline pressure with no recorded exception
Verify human oversight assignments	Named people hold the human oversight roles the process defines, with authority to stop or change a release	Oversight role assignments and responsibility records. Finding: oversight is described generically with no named individual
Review testing records	Testing and evaluation results were produced before each gate and tied to the release decision	Test reports, evaluation results and sign-off timestamps. Finding: test results exist but are dated after the release they were meant to support
Confirm approvals name a decision maker	Each approval to proceed identifies who decided, on what evidence and with what conditions	Approval records showing approver name, role and decision. Finding: approvals recorded as team or group sign-off with no accountable individual
Interview developers and approvers	Staff can explain how design decisions were made, escalated and recorded, consistent with the documents	Interview notes and walkthroughs. Finding: staff describe a different process from the one documented

How the design process gates the A.6.2 life cycle stages

A.6.1.3 is the process layer that the A.6.2 controls then apply stage by stage. Its job is to fix, in writing, the steps a team follows from concept to retirement and the decision points where work may move forward. The A.6.2 controls then supply the content for each stage: requirements and specification under A.6.2.2, design and development records under A.6.2.3, verification and validation under A.6.2.4, deployment under A.6.2.5, operation and monitoring under A.6.2.6, technical documentation under A.6.2.7 and event logs under A.6.2.8. If the process is vague, each stage control becomes a separate, unconnected paperwork exercise, so the first decision is to define the gates between stages and who signs each one.

The NIST AI RMF to ISO/IEC FDIS 42001 crosswalk, contributed by Microsoft through the NIST AI Resource Center, maps several AI RMF subcategories to B.6.1.3, the implementation guidance for this control. The relevant links are MAP 3.5, which concerns defining human oversight processes; MAP 2.3, which concerns scientific integrity and test, evaluation, verification and validation (TEVV); GOVERN 3.2; MANAGE 1.1, which concerns the decision whether to proceed; and MANAGE 2.4, which concerns mechanisms to deactivate AI systems. NIST states that posting the crosswalk is not an endorsement, so treat it as a working reference to check against your own process, not as proof of conformity. Confirm the current mapping version directly with NIST before citing it to an assessor.

ISO/IEC 5338:2023 describes AI system life cycle processes that an organization can use to define, control, manage, execute and improve its AI systems. It is a useful reference when drafting your own life cycle procedure, because it gives the team a shared vocabulary for stages and process activities. It does not replace the organization's documented process, and an assessor will look for your process, not for the reference. Practically, decide which human role can stop a release, what evidence each gate requires, and how a stopped or retired system is handled, then confirm that the A.6.2 records can be traced back to those gate decisions.

Implementing the design and development process, step by step

This sequence turns A.6.1.3 from a policy statement into a documented process with named owners, gate criteria, enforced repository controls and a tested first run, so that each AI system passes through the same visible decisions before it moves forward.

Define the stages and their owners
Start by listing the stages your organization actually uses to design and develop AI systems, from idea and requirements through design, build, verification and release. For each stage, name the accountable owner and the people who contribute. The output is a stage map that lists each stage, its entry and exit points and its owner. You know this step is done when every stage has one accountable owner and the product, engineering, risk and compliance leads have each confirmed their part in writing.
Write the process document and approval rights
Document the design and development process in one controlled document that describes each stage, the artifacts it produces and the approval each stage needs. Specify who may approve a transition to the next stage and who may override an approval, and state that approval rights cannot be exercised by the person who built the work. The output is the approved process document with a version number and a named approver. It is done when the document is published in your management system and the approvers have acknowledged their rights.
Set gate criteria for each stage
For every stage boundary, write the criteria that must be met before work proceeds. Criteria should be checkable, such as a completed impact assessment, an approved requirements record, a documented test plan with acceptance thresholds or a recorded risk decision. Keep them in a gate criteria register that links each criterion to its evidence type. The output is the register. It is done when each gate has a criterion, an evidence location and a named decision owner.
Assign human oversight roles with stop authority
Name the people who oversee AI system development and give them explicit authority to pause or stop work at any gate. Record this in a RACI that shows who is responsible, accountable, consulted and informed for each gate decision. Confirm that the oversight role has access to the evidence it needs and is not overruled by delivery pressure without a recorded decision. The output is the signed RACI and a documented stop procedure. It is done when the stop procedure has been read by the oversight roles and by the delivery leads.
Connect gates to ticketing and repository controls
Make the gates enforceable in the tools your teams use. In a self-hosted GitLab Community Edition instance, for example, protected branches can restrict which roles may push or merge, block direct pushes by setting push access to no one, and keep force pushes disabled. Link merge requests or tickets for each gate to the criteria in the register, and add scanning jobs such as Semgrep Community Edition in CI/CD for code checks. The output is a configuration record showing the branch rules, pipeline jobs and ticket fields tied to each gate. It is done when a test change cannot reach the release branch without the required approvals. Confirm the exact settings against your GitLab version and edition.
Run a pilot on one live AI project
Apply the process to one AI project that is already in active development, rather than a demonstration build. Walk it through every gate, record each decision, each exception and each stop or override, and note where the process was unclear or slow. For language model components, the verification evidence can include probe reports from garak, which writes a JSONL report of every attempt and a hit log of attempts that found a vulnerability. The output is a pilot record with gate decisions, evidence links and a list of corrections to the process document. It is done when the corrections are approved and the process document is reissued.
Review the process at management review
Bring the process, the gate decisions from the pilot and any stop or override records into management review. Decide whether the criteria are still correct, whether the oversight roles had enough authority and information and whether the tooling enforces what the document says. Record the decisions and assign actions with owners. The output is the management review minutes and an updated process document. It is done when the review decisions are recorded and the next review date is set in your management calendar. The review also feeds the internal audit program under the management system clauses.

Evidence that passes an A.6.1.3 audit and how to keep it current

An auditor testing A.6.1.3 wants to see a defined process, the people who hold authority within it, and dated records showing the gates were applied to real AI systems. The six artifacts below connect those pieces, and each one is most reliable when it is produced as a by-product of delivery rather than assembled before an assessment.

Approved design and development process

The documented process for responsible AI design and development is the anchor document for A.6.1.3. It should set out the stages, the gates between them, the roles that approve each gate and the criteria used, and it should carry a version history showing who approved each revision and why. Check that the process names the life cycle stages that the A.6.2 controls later apply, so the document reads as one system rather than separate policies. Confirm the review date and that the current version is the one teams actually follow.

Gate criteria and checklists per system

Each AI system should have its own record of the gate criteria that applied to it, such as data suitability, testing results, human oversight arrangements and risk treatment decisions. Generic checklists copied across projects are weak evidence because an assessor will ask whether the criteria fit the system in front of them. Keep the checklist versioned alongside the system so the criteria in force at each gate can be reconstructed later.

Human oversight role assignments

A.6.1.3 expects human oversight to be part of the design process, so the assessor will look for named people with defined authority to intervene, pause or reject work. Record each role, the person holding it, their scope and the conditions under which they can stop a release. Review assignments when staff change, because a role assigned to someone who has left the organization is a common audit finding.

Approval to proceed records

Every gate passed should leave a record naming the approver, the date, the system version and the evidence reviewed. This is the record that proves the process was followed rather than described. Tie these approvals to the workflow tool that controls promotion, such as protected branches or required reviewers in the code platform, so an approval cannot be skipped without leaving a trace. Sampling these records before an audit shows whether approvals are consistent across teams.

Records of stopped or returned work

Assessors look for evidence that the gates can say no. Keep a log of work that was returned for rework, held or cancelled, with the reason and the gate that caught it. A process that never stops anything suggests the gates are decorative. These records are also the best input for improving criteria, so link each entry to the change it produced.

Process review log after incidents and changes

A.6.1.3 is not a one-time design exercise. The review log should show when the process was examined, what triggered the review, such as an incident, a regulatory change or a failed evaluation, and what changed as a result. Entries should reference the version of the process document they modified. Schedule reviews so they occur even when nothing has gone wrong, since an empty log across a long period invites questions about whether the process is being maintained.

Self-hosted open-source tools that produce gate evidence for A.6.1.3

Open-source tools can make the gates defined under A.6.1.3 leave a record, but they do not decide what the gates require. The organization owns the design, development and approval process and must set the criteria for each gate first. Once those criteria exist, self-hosted tools running inside the organization's own infrastructure can capture the evidence that shows the gates were applied. GitLab Community Edition (MIT) is the most direct example. Its protected branches let maintainers restrict which roles can push or merge to a branch, block direct pushes by setting push access to no one, and keep force pushes disabled unless explicitly allowed. Configured this way, the approval to proceed becomes a merge event in the repository history rather than a verbal sign-off, and the assessor can check who approved what and when.

Semgrep Community Edition (LGPL-2.1-only) supports a technical gate. Its documentation lists supported languages including C/C++, C#, Go, Java, JavaScript, TypeScript, Python, Ruby, Rust, PHP, Kotlin, Swift and Terraform, and it can run in CI/CD pipelines to scan repositories continuously. The output is a gate result, not a judgment on whether the design is responsible. Confirm that the languages in your AI system are covered, decide which rules are blocking and which are advisory, and record who may override a failed scan. garak (Apache-2.0) fits a testing gate for language models. It probes for hallucination, data leakage, prompt injection, misinformation, toxicity and jailbreaks, and writes a JSONL report of every attempt and evaluation plus a hit log of attempts that found a vulnerability. Langfuse (MIT) traces each operation in a request, including LLM calls, retrieval steps and tool executions, which gives reviewers the runtime behavior behind a design decision.

Confirm three points before relying on these tools as gate evidence. First, check the license terms with your legal team, since Semgrep Community Edition is LGPL-2.1-only and the MIT and Apache-2.0 licenses carry their own notice and distribution duties. Second, confirm that each tool's features in your chosen version match the behavior described here, because the capabilities above come from vendor documentation and project readmes. Third, decide retention and access for the logs and reports, because a gate record is only useful if it is kept unaltered and can be produced for an independent auditor. Maintain a short mapping of each gate to the tool, the criterion and the approver so that the evidence is traceable from the process definition to the record.

What meeting A.6.1.3 costs in money and effort

This table lists the cost components of defining and running the responsible AI design and development processes that A.6.1.3 asks for, and shows who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to build a quote request, since a written scope should show which components are in and out of scope before work starts. No figures are shown because none were supplied for this control.

Cost component	One-time or recurring	What drives it up	How to keep it down
Process design and documentation labor	One-time, with periodic revision	Number of AI system types, number of business units writing their own procedures, regulated use cases	Start from one written development procedure with per-system annexes, and reuse templates across systems
Gate and approval time from reviewers and engineers	Recurring, per AI system release	Number of gates, reviewers per gate, releases per year, unclear approval criteria	Keep gates few and defined, set written pass criteria, and pre-approve low-risk changes under a stated rule
Tooling licenses	Often recurring, depending on vendor	Number of seats, commercial scanning or observability tiers, number of environments	Prefer open-source tools where they meet the need, and confirm each tool's license terms and feature limits before selecting it
Hosting and administration of self-hosted tools	Recurring, staff time and infrastructure	Number of instances, upgrade frequency, backup and access control requirements	Consolidate tooling onto shared, hardened platforms and automate upgrades and backups
Testing and red teaming of gated systems	Recurring, per gated release or on a schedule	Number of gated systems, model types, generative AI features, external testing scope	Scope testing by risk tier, automate repeatable checks in CI/CD, and reserve external red teaming for high-impact systems
Evidence upkeep	Recurring, continuous	Number of systems and gates producing records, retention periods, manual evidence collection	Generate approval, test and deployment records automatically in the normal workflow rather than assembling them later
Auditor sampling time	Recurring, per audit cycle	Number of AI systems sampled, gaps in records, unclear ownership of decisions	Keep one indexed evidence location per system so samples can be pulled quickly, and confirm the auditor's sampling approach in advance

Who does what: your team, an implementation partner and the auditor

Your organization owns the design and development process for each AI system, and it owns the decisions the process produces. A.6.1.3 expects a documented process, so the people who build AI systems must recognize it as their own. Start by naming who writes the process, who approves each stage, and who has authority to stop a release. Those roles should sit with managers who can act on what reviews find, not only with a committee that meets occasionally.

Process ownership: A named owner maintains the documented process, reviews it on a set cadence and records each change.
Approvers: Name the people who approve each gate, including the approval to proceed, and state what each approver must see before signing.
Gate criteria: Your team decides the testing gates, the thresholds for human oversight and the conditions that trigger a stop. Criteria should be specific enough that two reviewers reach the same answer.
Sign-off records: Each approval is recorded with the approver, the date, the system version and the evidence reviewed.
Daily execution: Engineers, data scientists and product owners run the process on every project, using the tooling that enforces it.

Check that every gate has a named approver who did not build the system being approved.

Where organizations fall short on A.6.1.3 and how to close each gap

Most A.6.1.3 findings are not about missing documents. They appear when a documented process and the way delivery teams actually build AI systems drift apart. The cards below cover the gaps assessors most often trace back to this control, and the practical correction for each.

Process written for auditors only

The design and development process exists as a policy document, but delivery teams follow their own sprint routines. The symptom is a process that describes stages nobody runs, such as a model risk review that never appears in the backlog. To close the gap, map the documented stages to the tickets, pipelines and templates teams already use, and check a sample of recent AI projects against the written process before the assessment. Assessors usually ask for that comparison.

Gates without a named approver

Approval to proceed is written as a step, but no individual holds the decision or the authority to stop a release. The symptom is a gate signed off by whoever is available, or by a committee that never meets on schedule. Name one accountable approver per gate, record their decision criteria, and give them explicit authority to halt work. Confirm that the approver is independent of the team that built the system where your risk profile requires it.

Approvals outside the system record

Approvals are given in chat threads or email, with no reference to the model version, dataset or configuration that was approved. The symptom appears when an auditor asks which version was signed off and the team cannot say. Route approvals through a tracked change process, such as protected branches and merge requests in GitLab documentation, so each approval links to a specific commit. Store the approver, date and artifact identifier together.

Oversight without time or authority

Human oversight is defined in the process, but the named reviewer has no time allocated, no access to the system's behavior, and no real ability to pause it. The symptom is a reviewer who confirms outputs in bulk without reading them. Set a review capacity for each oversight role, give reviewers monitoring access and a documented stop mechanism, and record each intervention or decision not to intervene. Test the stop mechanism in a drill, since an untested control is hard to defend.

Supplier and fine-tuned components outside scope

Pre-trained models, third-party APIs and open-weight checkpoints enter the system without passing through the design and development process. The symptom is a fine-tuned model or open-source library that no internal gate ever reviewed. Inventory every externally sourced component, apply the same gates to fine-tuning and configuration changes as to new builds, and put the supplier's testing evidence in the approval record. Scan the codebase for unreviewed dependencies on each release, for example with Semgrep documentation rules in CI/CD.

No review after incidents or failed gates

When a gate fails or a production incident occurs, the team fixes the immediate problem and moves on, and the process itself never changes. The symptom is the same failure recurring across projects, with no record that the design process was reviewed. Log each failed gate and incident against the stage where it should have been caught, then revise the criteria or approver assignments on a set schedule. Keep the review record, since it shows the process is maintained rather than assumed to work.

Questions buyers ask about A.6.1.3 cost, effort and outside help

How much effort does A.6.1.3 take for a team with a few AI systems compared with many?

Effort grows with the number of AI systems, the number of teams building them and how many distinct development paths exist. A team with a few systems on one shared pipeline usually needs one documented process, a short list of gates and a small set of approvers. A team with many systems across several products, vendors and risk levels needs variants of the process for each category, more evidence to collect per release and more approval records to keep current. The main drivers are how many development paths you run, how much of the work is new model development versus configuring third-party AI, how mature your existing change control is, and how many people must review and sign off. Ask any provider to show how the effort scales with each of these drivers before you accept a fixed-scope quote.

Can our own team implement A.6.1.3 without an outside partner?

Yes. ISO/IEC 42001 does not require an external party to write your processes, and an organization can define and document its own responsible design and development processes. What matters is ownership: a named role must own the process, and named people must hold the authority to approve or stop an AI system at each gate. Your team needs people who know your delivery pipeline, your risk owners and your AI systems well enough to write gates that can actually be enforced. Internal teams often underestimate the time needed to collect evidence consistently across projects, so pilot the process on one or two live systems before rolling it out.

What does an implementation partner need from our team?

A partner needs concrete access and decisions, not just meetings. In practice, that means read access to the repositories, pipelines and ticketing systems where AI systems are built and released, a named workflow owner for each development path, and named approvers who can accept or reject a system at each gate. The partner also needs a few sample projects so that the documented process is tested against real work rather than an imagined one. Your team should confirm early which systems are in scope, where evidence is currently kept and who can change branch protection or pipeline settings. Write these dependencies into the statement of work so that delays on your side are visible.

How long does A.6.1.3 implementation take?

The duration depends on the scope you agree, and no fixed figure applies to every organization. The main variables are how many AI systems and development paths are included, how many gates and approvers the process needs, how much existing tooling can enforce the gates, and how quickly your team can make decisions. Timelines are set in the fixed-scope written agreement, which lists the deliverables and the schedule before work starts. Ask for a timeline that separates design of the process, pilot on live systems, and rollout, because the pilot usually reveals the gaps that change the later phases.

Can a consultant certify that we comply with A.6.1.3?

No. A consultant or implementation partner can help you design, document and evidence your processes, but only an independent certification body can issue an ISO/IEC 42001 certificate. ISO does not certify organizations itself, and certification bodies assess the management system against the standard. DeployOpen prepares systems, controls and evidence for assessment, and does not issue audit reports, attestations or certifications. Keep the roles separate in your contract, and make sure the certification body you choose is independent of the firm that helped you build the process.

What should we ask for in a quote for A.6.1.3 work?

Ask for a quote built from a written scope, not a headline price. It should list the AI systems and development paths in scope, the deliverables (a documented process, gate definitions, approval records, evidence templates and pilot results), the systems and repositories the work touches, and the roles your team must fill. Ask which costs are one-time, such as design and pilot, and which recur, such as updates after standards or internal policy changes, and whether retainer support is included. Confirm what is excluded, who owns the resulting documentation, and how changes to scope are priced. DeployOpen does not publish a price list, so compare quotes on the written scope rather than on rates alone.

How DeployOpen scopes and prepares A.6.1.3 evidence

DeployOpen works on A.6.1.3 by helping the organization turn its design and development processes into written, reviewable records. The organization owns the processes and approval decisions, while DeployOpen plans, builds and documents the supporting systems and evidence. Only an independent auditor or certification body can issue any report or certificate.

How we scope

Agree in writing which AI systems and development stages the A.6.1.3 processes will cover before work starts.
Confirm which human oversight roles, testing gates and approval-to-proceed decisions the organization already uses.
Record which parts stay with the organization, such as policy decisions and sign-off, and which parts DeployOpen will build.

How we build

Configure branch protections so that changes to AI development code require named roles to review and approve them.
Add automated code scanning to CI/CD pipelines so that security gates run on every repository change.
Set up tracing and event records for AI application runs so that reviewers can inspect how a system behaved during testing.

How we hand over

Deliver written process documents that show each development stage, its owner, its gate criteria and its approval record.
Provide a mapping from each documented process to the evidence it produces, so an assessor can trace claims to records.
Train the organization's owners on running the gates and keeping approval records current after handover.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope work is complete.
Review the processes when the organization changes its development tooling or adds new AI system categories.
Confirm with the organization's chosen auditor which evidence formats and sampling they will expect before final handover.