A.6.2.5 AI system deployment: requirements and evidence

What ISO 42001 A.6.2.5 asks before an AI system goes live

A.6.2.5 asks the organization to document a deployment plan for each AI system and confirm that the appropriate requirements are met before the system is deployed. If you are the compliance lead or engineer who must show that a release went out under a documented plan, this control is the one an assessor will ask you to prove at the moment of go-live, not later. The risk it addresses is straightforward: an AI system reaches production while its requirements, validation results or operating conditions were never checked against what was promised. A model that passed testing in a staging environment may behave differently with production data, access rights, or integrations, and nobody may have recorded whether that gap was acceptable.

The difficulty is that deployment evidence rarely sits in one place. The requirements may live in a specification document, validation results in a test repository, the release decision in a change ticket, and the actual rollout in a pipeline log. Approvals may be given in chat or email. Before an assessment, confirm that you can trace a single release across those sources: which plan applied, which requirements were checked, who approved the release, what environment it ran in, and how it would be reversed. Ticketing and change-management tools such as GLPI can hold the approval record, and a protected-branch policy in GitLab can show who was allowed to merge the release, but neither produces the plan or the requirement check on its own.

A.6.2.5 covers the moment of release and the conditions set for it. It is distinct from A.6.2.6, which governs what happens once the system is running: monitoring, drift detection, repairs, updates and decommissioning. Keep the two records separate so the deployment plan is not mixed into operational logs. The control sits in the A.6.2 AI system life cycle objective alongside A.6.2.2 to A.6.2.4 and A.6.2.6 to A.6.2.8, so the requirements, design records and validation results it depends on should already exist before your deployment plan can reference them.

Which AI systems, teams and changes fall under the deployment plan

A.6.2.5 only bites on the systems and changes the organization decides to bring under it. These scoping choices determine how many releases need a documented plan, who signs them off, and where the statement of applicability must explain an inclusion or exclusion under clause 6.1.3.

Systems and material enhancements

Start by listing every AI system the organization develops or provides, then mark which ones count as new or materially changed. A material enhancement is the trigger to check: a new model architecture, a changed intended purpose, or a new data source usually needs a fresh plan, while a cosmetic interface change may not. Record the threshold in the scope document so an assessor can see why each release was or was not covered.

Internal tools and staff copilots

Decide whether AI tools used only inside the organization fall under A.6.2.5. An internal tool that drafts reports or screens tickets still changes business processes, so the deployment plan should say who uses it, in which environment and under what conditions. Organizations that exclude internal tools should justify that choice in the statement of applicability and confirm the exclusion with their certification body before assessment.

Third-party AI services

Decide how externally hosted AI services are handled when the organization configures, integrates or fine-tunes them. Configuring a vendor model inside your own application is usually a deployment you control, so it needs a plan covering prompts, data flows and rollback. The vendor's own release process is a supplier matter under the third-party controls. Confirm the boundary in writing with the vendor and your auditor.

Release approval authorities

Name the roles that can approve a deployment, such as the product owner, a risk or compliance reviewer and the security lead, and state which decisions each one can make alone. Approval records should show who approved, against which requirements, and when. Separate the people who build a release from those who approve it, so the approval step has real effect and produces evidence an assessor can trace.

Model updates versus new deployments

Set a rule for when a retrained or fine-tuned model is a new deployment and when it is a routine update. A new model version that changes behavior, performance or intended use should go through the full plan, while a patch that only fixes infrastructure may follow a lighter path. Writing the criteria down prevents teams from quietly shipping behavioral changes as maintenance.

Hand-off to operation

Define where deployment ends and operation under A.6.2.6 begins, usually at the point the system is released to production and monitoring is switched on. Confirm that the plan names the monitoring owner and the rollback trigger before go-live. Ambiguity here leaves gaps in both controls, so document the handoff date and the artifacts passed across.

How an assessor tests the deployment plan and pre-release checks

This table shows how an independent auditor typically tests A.6.2.5 AI system deployment, from sampling releases to tracing each one back to its plan and approval. Read it as a guide to what to prepare: the auditor samples and reports, and DeployOpen prepares the records but does not issue audit conclusions.

Test step	What the assessor does	Where it usually goes wrong
Scope the sample	Selects recent AI system releases and deployments within the certification scope, often including a mix of new systems and material changes	Release records are scattered across tools, so the auditor cannot build a complete population
Trace to the plan	Checks that each sampled release has a documented deployment plan that exists before the deployment date	Plans written after go-live or reconstructed later to match what was deployed
Check requirements were met	Compares the plan against the requirements and acceptance criteria approved for that system, confirming the relevant ones were satisfied before release	Requirements exist, but no evidence shows they were checked before the release
Match approval to version	Confirms the release approval names the exact model, configuration and artifact version that went live	Approval covers an earlier build, so the deployed version differs from the one signed off
Review environment checks	Looks for records of pre-release checks in the target environment, such as configuration, access and dependency checks	Checks were done informally or in a non-production environment, with no record kept
Verify rollback readiness	Asks for the rollback steps in the plan and evidence that they were tested or could be executed	Rollback is described in general terms only, with no owner or tested procedure
Interview owners	Asks the people who approve and deploy to explain the process and how exceptions, such as emergency releases, are handled	Staff describe a process that differs from the written procedure
Report the result	Records conformity or nonconformities for each sampled release, and the organization responds to any findings	Findings repeat across samples because the release gate was never enforced in the pipeline

How to implement a deployment plan and release gate, step by step

This sequence turns A.6.2.5 into a repeatable release gate, so each AI system has a documented deployment plan, approved release criteria, named approvers, verified environments and a tested way back if a release fails.

Define a deployment plan template per AI system
Start by agreeing a standard deployment plan template that every AI system uses before release. It should cover the system name and version, the target environments, the components being deployed (model, data pipelines, prompts, configuration and integrations), the people responsible, the planned release window, the monitoring that starts at go-live, and the rollback path. The organization owns the template and its required fields, and an implementation partner can draft it and fit it to your existing change process. The step is done when each AI system in scope has a completed plan in a version-controlled location, reviewed by its system owner.
Map requirements and verification results into release criteria
Translate the requirements approved under A.6.2.2 and the verification and validation results from A.6.2.4 into a concrete list of release criteria. Each requirement should become a checkable condition, such as a performance threshold, a documented limitation, a human oversight arrangement or a passed red-team exercise, with a pointer to the test record that proves it. Where a requirement has no matching test, flag the gap before release rather than accepting it silently. The output is a release criteria checklist for each system, signed off by the owner of the requirement and the owner of the test results.
Set release approval roles and decision rights
Name who may approve a release, who may request one and who may stop one. Separate the people who build the system from the people who approve its release where your size allows it, and record the approval authority in a written matrix that links to the release criteria. Confirm that the approvers have the competence and the access to read the test evidence they are signing off. The output is an approval matrix and a sign-off record format. Ask your auditor how they expect segregation of duties to be shown in your environment.
Add environment checks before promotion
Define the checks that run in each environment before the AI system moves forward, such as confirming the deployed model version matches the approved artifact, that configuration and secrets are correct for the target environment, that access controls and logging are switched on, and that data sources are the ones approved for that use. Where your delivery pipeline allows it, automate these checks as gates and keep the results. Semgrep Community Edition can scan infrastructure and application code in pipelines where those languages are used, which supports part of the configuration review. The output is a documented checklist and pipeline gate results attached to each release record.
Protect the release branch and record every change
Control how deployable code and configuration reach production. GitLab Community Edition protected branches let you restrict which roles can push or merge, block direct pushes by setting push access to no one, and keep force pushes disabled unless explicitly allowed. Pair this with merge requests that link to the approved release criteria. The output is a repository configuration that shows who could release and a traceable record connecting each deployed version to its approval. Confirm the exact settings with your GitLab edition and administrator before relying on them.
Define and test the rollback procedure
Write the steps to return the system to the last approved version, including who triggers the rollback, the criteria that trigger it, how user-facing services are switched back, how data or model state is handled, and how stakeholders are informed. Then test it in a non-production environment before the first live release that depends on it. Keep the rollback test record. The output is a rollback runbook and evidence that it was exercised, because an untested rollback is unlikely to satisfy an assessor who asks how a failed release would be reversed.
Log the approval, open the change record and hand over to operation
Bring the release into your service management process so every deployment has a ticket or change record. GLPI's Assistance module supports tickets and changes following ITIL practices, and Zammad can route customer-facing issues into one ticket system. Record the approval, the environment check results, the rollback plan and the go-live time in that record. Then hand over to monitoring and operation, which is governed separately under A.6.2.6. The output is a closed release record for each deployment that an assessor can follow from requirement to production.
Review the gate after each release
Hold a short review after each release, or after any rollback, to decide whether the template, criteria, approvals and checks still fit the system. Record the findings and update the plan template or release criteria where needed. Your internal governance owners should own this review, and an implementation partner can help you run it and keep the records consistent. The step is done when the review outcome is filed against the release and any changes to the gate have an owner and a version.

Which deployment records satisfy the control and how to keep them current

A.6.2.5 is tested by records, not by intent. Each record below shows a step from plan to release, and together they let an assessor trace a deployed AI system back to the requirements it was supposed to meet. Keep each record tied to a specific system and version so it stays current between audits.

Signed deployment plan per system

This is the document that A.6.2.5 asks for: a plan for each AI system describing what is deployed, where, to whom, and under which conditions. Give every system its own plan, name an owner, and record the approver and date. Review the plan whenever the target environment, user population or intended purpose changes, and keep superseded versions so an assessor can see what was approved at each point.

Requirements traceability before release

Traceability links each requirement set out during specification to the test, review or check that showed it was met before release. Without this link, a deployment plan only states intent. Maintain the matrix in the same repository as the release, and update it when requirements change so that the record still matches the version in production.

Release approval record

The release approval shows who authorized deployment, against which plan and evidence, and when. Confirm that the approver is independent of the team that built the system, and that approval is recorded in a system the organization controls, such as a ticketing tool or protected merge request. Re-approval should be required for material changes, not only for the first release.

Environment check results

Before release, record the results of checks on the target environment: access controls, network placement, configuration baselines, data sources and dependency versions. Store the outputs of the checks, not only a statement that they passed. Re-run the checks for each new environment, and compare results against the environment named in the deployment plan.

Tested rollback procedure

A rollback procedure describes how to return to the previous version or to a safe state if the release fails. Auditors look for evidence that the procedure was exercised, such as a dated test log or a record of a rehearsal in a non-production environment. Update the procedure whenever the release pipeline or the infrastructure changes, and note which version it applies to.

Change record linking version to plan

The change record ties the deployed artifact, identified by version or hash, to the approved plan and approval. It answers the question an assessor asks most often: is what runs in production the thing that was approved? Use protected branches and required reviews so that changes cannot reach production without a record. Review change records periodically against production inventory to catch drift.

Open-source tools that can hold deployment evidence

A.6.2.5 is judged on records: a deployment plan, approvals and proof that requirements were met before release. The tools below can each hold one part of that trail, from the approved change ticket to the reviewed code and the protected branch that ships it. None of them satisfies the control on its own, and the organization must confirm each capability in its own environment before relying on it.

GLPI change tickets and planning

The Assistance module of GLPI lets teams create, follow and process tickets, problems and changes following ITIL practices, with plannings, statistics and a Kanban view. For A.6.2.5, a change record can hold the deployment plan, the named approvers, the requirement checks completed before release and the rollback steps. Check that your configured change workflow requires approval before the ticket can move to deployment, and that closed records cannot be silently edited. GLPI is licensed under GPL-3.0-or-later, so confirm that your use and any modifications meet its terms.

Zammad incident and request tracking

Zammad is a web-based helpdesk that brings customer communication from email, chat, telephone and social media into one ticket system. For A.6.2.5, it can record communications with customers or internal stakeholders about a release, such as acceptance of a release date, notice of a deployment window or a customer objection that must be resolved before go-live. Those records help show that interested parties were told about changes. Confirm which channels your deployment uses and how ticket history is retained. Zammad is licensed under AGPL-3.0-only, so review the obligations that apply if you modify and offer it over a network.

GitLab protected branches for release control

GitLab Community Edition supports protected branches that restrict which roles can push or merge, block direct pushes by setting push access to no one, and keep force pushes disabled unless explicitly allowed. For A.6.2.5, this gives a technical gate so that only an approved change reaches the release branch, and the merge history shows who released what. Verify that your production branch is protected in your own instance, that approvals are enforced on merge, and that administrators cannot bypass the rule without a logged exception. GitLab Community Edition is MIT-licensed.

Semgrep checks in the pipeline

Semgrep Community Edition scans code in languages including Python, Go, Java, JavaScript, TypeScript and Terraform, using community or custom rules, and can run in CI/CD pipelines to scan repositories continuously. For A.6.2.5, a scan result attached to each release build can serve as evidence that a defined verification step ran before deployment, including infrastructure definitions written in Terraform. Confirm which rule sets your organization has approved, whether a failed scan blocks the pipeline, and how exceptions are recorded. Semgrep Community Edition is licensed under LGPL-2.1-only, so confirm that the license terms fit how you distribute or modify it.

What meeting A.6.2.5 costs in money and effort

This table breaks the cost of meeting A.6.2.5 into its components, showing who is paid for each, whether it is one-time or recurring, and what moves it up or down. No prices or durations are given because none are supplied, so use the last column to build the questions you send to vendors, partners and auditors. The main takeaway is that the recurring cost of evidencing each release usually matters more than the one-time build.

Cost component	One-time or recurring, and who is paid	What drives it up or down	What to ask for in a quote
Tooling and licenses	Recurring where commercial. Self-hosted open-source tools such as GitLab Community Edition, GLPI or Zammad carry no license fee, but hosting, backup and administration remain internal or partner effort.	Number of AI systems and users, hosting footprint, and whether ticketing and code hosting already exist. Reusing existing tools lowers this cost.	Confirm the license model for each tool, what features the Community or free edition excludes, and the hosting and support cost you will carry.
Engineering time to build release templates and gates	One-time, paid to internal engineers or an implementation partner. Covers the deployment plan template, approval workflow and protected-branch setup.	Number of distinct AI system types, existing change management, and how many environments must be covered. Standardizing one template across systems reduces effort.	Ask for a fixed-scope deliverable list naming the templates, pipeline gates and approval steps, plus what the client must supply such as named approvers and environments.
Evidence upkeep per release	Recurring, paid to internal release managers or to partners on retainer. Covers recording the deployment plan, approvals and environment checks for each release.	Release frequency is the main driver. Automating evidence capture from pull requests, tickets and pipeline logs reduces manual effort per release.	Ask how evidence is generated automatically, where it is stored, how long it is retained, and who reviews it before each release.
Rollback and release gate testing	Recurring for each significant change, and one-time for the initial test. Paid to internal staff or external testers who verify that rollback works and gates block unapproved releases.	Complexity of the deployment architecture, the number of rollback paths, and whether tests are run in a staging environment that mirrors production.	Ask for the test cases, the environment used, the frequency of retests, and whether the tester produces a written record that an assessor can review.
External review of the deployment process	Optional and occasional, paid to an independent consultant or security firm. Confirms that the design of gates and rollback meets the requirement before an assessment.	Maturity of internal change management and the number of AI systems in scope. A first review costs more than a periodic check.	Ask for the review scope, the criteria used, the written findings format, and whether the reviewer is independent of the team that built the process.
Auditor sampling time	Recurring at each audit cycle, paid to the independent auditor or certification body. The auditor selects releases and examines the evidence. DeployOpen does not issue audit reports or certificates.	Number of releases sampled, how cleanly evidence is organized, and whether approvals are traceable to each deployment. Well-indexed evidence shortens sampling.	Ask the certification body how it samples releases, what evidence format it accepts, and how many releases it expects to review in a cycle.
Ongoing support and retainers	Recurring, paid to an implementation partner if one is used. Covers template updates, pipeline maintenance and responses to changes in the release process.	Degree of change in the release process and the number of AI systems supported. Clear ownership inside the organization lowers the need for external support.	Ask whether support is fixed-scope or retainer-based, what response expectations are written into the agreement, and what the client must own internally.

Who owns the deployment plan, who can help, and where the auditor stops

Your organization owns the control. Under A.6.2.5 the organization must document a deployment plan for each AI system and confirm that the appropriate requirements are met before release. Only your people can accept the risk of going live, so release approval authority and the content of each plan must sit with named owners inside the company. An outside partner can draft material, but it cannot sign off on your behalf.

Release authority: Name the people who may approve a deployment and record their decisions against each release.
Plan content: Decide the target environment, dependencies, data flows, rollback trigger and go or no-go criteria for each system.
Requirement confirmation: Check that the requirements set under A.6.2.2 and the verification results under A.6.2.4 were met before approval.
Ongoing ownership: Keep the plan current when the system changes, and hand operation to the controls under A.6.2.6.
Competent reviewers: Make sure approvers understand the system's intended purpose and known limits.

Before relying on this model, confirm that every AI system in scope has a named approver and a plan that predates its most recent release.

Where organizations fall short on AI deployment controls and how to close each gap

A.6.2.5 asks for a documented deployment plan and proof that requirements are met before release. The gaps below tend to appear when that evidence is produced after the fact, scattered across tools or never exercised, and each has a practical fix an assessor can verify.

Deployment plans written after go-live

A plan drafted once the system is already live records what happened, not what was intended. For A.6.2.5, the plan should exist before release and name the target environment, the version being deployed, the owner, the checks to run and the conditions for stopping. Assessors typically compare the plan's date with the release record. Fix: make an approved plan a required input to the release ticket, so the release cannot be scheduled without it.

Approvals recorded in chat

Release approvals given in a chat thread or by email are hard to tie to a specific version, cannot be shown to be complete, and may be lost when messages expire. The evidence should show who approved which deployment, when, against which requirements. Fix: record approval as a change or ticket in a system of record with named approvers, a timestamp and a link to the deployment plan. Chat can notify people, but it should not be the approval.

No link between requirements and the deployed version

A.6.2.5 requires that the appropriate requirements are met before deployment, but teams often cannot show which requirements a given build satisfies. Without a trail from the requirements specification to the code, configuration and artifact, an assessor cannot confirm that what shipped is what was approved. Fix: tag each release with its requirement identifiers and keep the mapping in the repository alongside the deployment plan.

Unpushed or unreviewed changes reaching production

If developers can push directly to the branch that feeds production, a release may contain changes no approver reviewed. Protected branches restrict who can push or merge, block direct pushes and keep force pushes off unless explicitly allowed. Fix: protect the release branch, require review before merge, and confirm in the platform settings that direct pushes and force pushes are blocked. Verify this setting in your own environment, since configuration varies by installation.

Rollback never tested

A rollback plan that has never been run is an assumption. A.6.2.5 expects environment checks and a way to return to a known state if a release fails. Teams often discover during an incident that the previous model artifact, configuration or data pipeline cannot be restored. Fix: rehearse rollback in a non-production environment before release, record the result in the deployment plan, and confirm the prior version is still retrievable.

Deployment evidence split across tools

Release approvals sit in the ticketing system, scan results in the pipeline, and environment checks in a runbook on a shared drive. Assembling the record for an assessor then takes days and invites gaps. Fix: choose one system of record for each release and link out to the others from it. Semgrep Community Edition can run in CI/CD to scan repositories on each change, so its results can be attached to the same release record. Confirm which languages your code uses against the supported list before relying on it.

Questions buyers and engineers ask about A.6.2.5

How much effort does it take to meet A.6.2.5 AI system deployment?

The effort depends mainly on how many AI systems are in scope, how many release paths they have and how much evidence already exists. A control that asks for a documented deployment plan and proof that requirements were met before release is not large in itself, but it becomes heavy when each system has its own pipeline, approvers and environments. The main drivers are the number of systems, the maturity of release management, whether requirements from A.6.2.2 are written down in a form that can be checked, and whether verification results from A.6.2.4 are stored where a reviewer can find them. Ask any provider for the effort split between building the deployment plan template, configuring tooling, and collecting evidence for each system. Ask whether the quote covers one-time setup, recurring reviews, or both.

Can a small team meet A.6.2.5 without outside help?

A small team with a single AI system and a simple release process can often write the deployment plan and approval steps itself, provided someone owns the work and the team understands the standard's intent. Outside help is more useful when the team lacks experience with ISO/IEC 42001 terminology, needs to connect deployment records to other controls, or must configure tooling in its own cloud or data center. Remember that the organization owns its controls. An implementation partner can prepare systems and evidence, but only an independent auditor or certification body issues reports or certificates. Whether the team can do this alone depends on its capacity to keep records current after each release, not on the first document it writes.

How long does it take to put an A.6.2.5 deployment process in place?

The timeline depends on scope, and no reliable duration is supplied for this control, so treat any single number with caution. Time is driven by how many AI systems need deployment plans, how many environments each one moves through, how much existing release tooling can be reused, and how quickly approvers can review plans. A realistic plan starts with one representative system so the template and approval flow can be tested, then extends to the rest. Ask a provider to split the timeline into scoping, design of the template, tooling setup, pilot release and rollout to other systems, with dates agreed in writing before work starts. Most engagements are fixed-scope, so the written scope is the basis for the schedule.

What does the internal team need to provide for A.6.2.5?

The internal team must provide the knowledge the organization alone holds. That includes named owners for each AI system, the business purpose and requirements that the release must satisfy, the people who can approve a release, and the rules for when a release may proceed or must stop. The team also needs to decide what counts as acceptable evidence of rollback readiness and environment checks. Engineers should maintain the deployment record for every release, and risk or compliance staff should review whether the approval criteria match the organization's AI policy. These responsibilities stay internal even when a partner builds the tooling, because the approvals and risk decisions are the organization's to make.

Can self-hosted open-source tools produce the evidence for A.6.2.5?

Yes, self-hosted open-source tools can generate much of the evidence, but they do not decide whether the control is met. A ticketing system such as GLPI can hold change requests, approvals and planning records, with its Assistance module supporting tickets, problems and changes following ITIL practices. Zammad can route customer-facing requests, and GitLab Community Edition protected branches can block direct pushes and keep force pushes disabled, so releases move through reviewed merges. Semgrep Community Edition can run in CI/CD pipelines to scan repositories continuously before release. Confirm for each tool that the feature you rely on exists in your version, and check how records are retained and exported for an auditor.

How does A.6.2.5 differ from A.6.2.6 AI system operation and monitoring?

A.6.2.5 covers the moment before release: documenting a deployment plan for the AI system and confirming that the appropriate requirements are met before it goes live. A.6.2.6 covers what happens after the system runs in production, including monitoring, repairs, updates, drift detection and decommissioning. In practice, the deployment plan sets the release approval, environment checks and rollback steps, while the operation control governs what is watched and how the system is maintained over time. The same system can have records under both controls, but the evidence differs. Deployment evidence shows the approval and readiness at release, while operation evidence shows continuing performance and response.

How DeployOpen scopes and prepares deployment evidence for A.6.2.5

DeployOpen prepares the deployment plan, release controls and evidence that A.6.2.5 asks for, inside your own infrastructure and on self-hosted open-source platforms. Your organization keeps ownership of the release decision and the controls, and an independent auditor or certification body is the only party that issues a report or certificate.

How we scope

Agree in writing which AI systems and release paths fall under the A.6.2.5 deployment plan before work starts.
Confirm which pre-release requirements from A.6.2.2 and A.6.2.4 must be shown as met before each deployment.
Identify which environments, approvers and rollback procedures the written scope will cover, and which stay with your team.

How we build

Configure a helpdesk or change workflow, such as GLPI's ITIL-based change module, to record each release request and approval.
Set protected branches in GitLab so that production changes require the approved roles to merge, with direct pushes blocked.
Add Semgrep scanning to CI/CD pipelines so pre-release checks produce repeatable results that can be attached to the deployment record.

How we hand over

Deliver a deployment plan template and a per-system record covering approvals, environment checks and rollback steps.
Provide the release evidence set, such as approval tickets, pipeline results and branch protection settings, with an index your assessor can follow.
Document who owns each step after handover, so your team can run future releases without outside help.

How we support

Engagements are fixed-scope, so the deliverables and timelines are agreed in writing before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer after the initial delivery.
Ask your DeployOpen contact to confirm in writing which evidence your auditor has reviewed and what remains open.