Template draft. Replace everything in [square brackets] with your own decision,
delete what does not describe what you really do, and approve it through your own document control. It is not legal
advice and does not make an organisation compliant or certified.
1. Introduction
A change that has been approved still has to be built, packaged and put into live use, and the way that is done decides whether the change helps customers or harms them. This procedure covers the work between the approval of a change and the point where the new or changed components are running in production, supported and recorded.
2. Purpose
The purpose is to make sure that releases are planned with the people and resources they need, built and tested from controlled sources, packaged so they can be deployed repeatedly and reversed, accepted against stated criteria, deployed with minimum disruption, and followed by a period of closer support, all with a complete record of what went live and when.
3. Objectives
- Every release is authorised by an approved change and described by a release record before deployment.
- Releases are built only from components held in the definitive repository, so that what is deployed is what was tested.
- At least [95%] of releases are deployed in the planned window with no incident above priority [3].
- Each release has a tested backout or recovery route, and the decision point for using it is agreed in advance.
- Release records and the CMDB are updated within [2 working days] of deployment.
- Early life support finds problems within the release and fixes or contains them before the release is closed.
4. Scope
- In scope: releases of software, infrastructure configurations, network and security configuration, documents, supplier components and services, whether new, changed or removed.
- In scope: planning, build and configuration, packaging, release acceptance, deployment, verification, early life support and release closure.
- In scope: emergency releases to fix a failure or a security weakness, and bundles of several approved changes.
- Out of scope: development of the software itself (see the System Development and Maintenance Procedure), and routine patching governed by the Patch Management Procedure, except where patches are bundled into a release.
- Applies to: release manager, developers, engineers, test teams, resolver groups, service desk, change authority, service owners and suppliers who prepare or deploy releases.
5. Terms and definitions
| Term | Meaning |
|---|
| Release | A collection of one or more approved changes that are built, tested and deployed together. |
| Release unit | The set of components that are normally released together, for example an application with its configuration and database scripts. |
| Release package | The deliverable files, scripts, configuration, documents and instructions that make up a release. |
| Definitive repository | The secure store that holds the authorised versions of software, configurations and documents used for releases. |
| Deployment | The act of moving a release package into an environment, in particular production. |
| Backout | The return to the previous state if a release fails. |
| Release record | The record of one release: scope, plan, results, and decisions. |
| Early life support | A defined period after deployment with closer monitoring and faster support. |
6. Roles and Responsibilities
| Role | Responsibilities |
|---|
| Process owner | Owns this procedure, approves release types and policy, and settles conflicts between release and change priorities. |
| Release manager | Runs the process, owns the release plan and calendar, chairs the release readiness review, authorises deployment within the change, and keeps the release records. |
| Release owner | Owns one release from planning to closure; accountable for its content and result. Usually a project or technical lead. |
| Build engineer | Builds the package from controlled sources, applies version numbers, checks integrity and stores the package. |
| Test lead | Tests the release and states whether the acceptance criteria are met. |
| Deployment engineer | Deploys the package to the environment, runs the checks and records the result. |
| Change authority | Approves the change that authorises the release and its window. |
| Service owner | Decides whether the release content is acceptable for live service and agrees timing. |
| Service desk and resolver groups | Prepare for the release by reading the notes, watch for problems in early life support, and take over operation. |
| Information security | Checks the package for security weaknesses and approves the use of tools and credentials for deployment. |
| Activity | Responsible | Accountable | Consulted | Informed |
|---|
| Plan release and window | Release owner | Release manager | Change authority, Service owner | Service desk |
| Allocate resources | Release manager | Process owner | Resolver groups, Release owner | Service owner |
| Build and package | Build engineer | Release owner | Configuration manager, Information security | Release manager |
| Test and accept the release | Test lead | Service owner | Resolver groups, Information security | Change authority |
| Authorise deployment | Release manager | Change authority | Service owner | Service desk, Customer representative |
| Deploy and verify | Deployment engineer | Release owner | Resolver groups | Service desk |
| Run early life support | Resolver groups | Service owner | Release owner, Service desk | Release manager |
| Close release and update records | Release owner | Release manager | Configuration manager | Process owner |
7. Release and Deployment Management Process
7.1 Inputs and outputs
| Inputs | Outputs |
|---|
| Approved changes and service design packages | Release plan, release calendar and release record |
| Source code, configuration and documents from the definitive repository | Release package with version and integrity data |
| Test results and acceptance criteria | Release acceptance decision |
| Capacity, continuity and security requirements | Deployed release and post-deployment checks |
| Knowledge from previous releases and incidents | Release notes, support information and backout record |
| Environment details from the CMDB | Updated CMDB, release baseline and closure report |
7.2 Process flow
- An approved change or group of changes is assigned to a release and the release owner is named.
- The release manager plans the release: scope, type, dates, resources, risks, and fits it to the release calendar.
- The release package is designed, then built and configured from controlled components.
- The package is tested in an environment that resembles production and a release readiness review is held.
- The change authority authorises deployment for the window.
- The deployment engineer deploys the release and the checks are carried out. Backout is used if the decision criteria are met.
- Early life support runs for the agreed period.
- The release is closed, baselines and the CMDB are updated and the lessons are recorded.
7.3 Release types and policy
| Release type | Content | Planning rule | Frequency |
|---|
| Major | New service or large change to a service; new platform or technology | Managed as a transition under the Service Design and Transition Procedure; full plan and rehearsal | [Per project] |
| Minor | Group of features or fixes; planned bundle of changes | Standard plan; fits the calendar; at least [5 working days] notice | [Every 2 to 4 weeks] |
| Maintenance | Patches, updates and configuration clean-up | Follows the Patch Management Procedure; release record per batch | [Monthly] |
| Emergency | Fix for a failure or security weakness that cannot wait | Approved as an emergency change; shortened testing is recorded as a risk | As needed |
- A release has a unique identifier and version number that follows the rule [major.minor.patch with date].
- Only components from the definitive repository may be part of a release.
- Changes to production outside a release are not allowed, apart from standard changes and emergency changes.
- Releases are not deployed during blackout periods in the change calendar, without approval from the change authority.
- Developers do not deploy to production unless they are authorised for that release under the principle of least privilege and a second person checks the result.
7.4 Release planning
- Group the changesThe release manager assigns approved changes to a release by service, dependency, risk and timing. Target: when the first change in the release is approved.
- Set the scope and typeThe release owner states what is in and out of the release, the type, the environments needed and the success criteria.
- Identify dependenciesCheck other releases, changes, supplier deliveries and customer events. Use the CMDB to find affected services and CIs.
- Select the windowThe release manager proposes the window from the change calendar and agrees it with the service owner.
- Assess riskList risks for the release as a whole, including the risk of bundling, with owners and responses.
- Agree the planThe change authority approves the plan as part of the change. Output: release plan. Target: [5 working days] before the planned build start.
7.5 Resource allocation
The release manager makes sure that the people, environments, tools and money required exist for the dates in the plan.
| Resource | What is confirmed | Confirmed by | When |
|---|
| People | Build, test, deployment, support and on-call staff, with deputies; no one is planned for more than [2] releases in the same week | Release manager with team leads | [10 working days] before |
| Environments | Build, test and pre-production environments are available and match production configuration | Release manager with infrastructure lead | [5 working days] before |
| Tools and access | Pipelines, repositories, credentials for deployment issued for the release only | Information security and build engineer | [3 working days] before |
| Budget and licences | Funds for licences, supplier effort and overtime | Service owner and finance | At plan approval |
| Communication | Notice to customers, users, the service desk and suppliers | Release owner | As the notice period in the plan |
7.6 Finalising the release plan
The plan is final when it contains the items below and has been approved by the change authority.
- Release scope, type, identifier and the changes included.
- Dates for build, test, readiness review, deployment and end of early life support.
- Roles and named people with deputies and on-call contacts.
- Deployment steps in order, with estimated time for each, plus the checks to run afterwards.
- The backout plan: trigger, decision maker, steps and time.
- Communications and the support information for the service desk.
- Acceptance criteria and test approach.
- Risks, assumptions and dependencies.
7.7 Designing and building the release
- Confirm the designThe release owner confirms that each change in the release is traceable to an approved design or request and that the design is current. Output: traceability list.
- Design the release packageDecide the components, order of deployment, tooling, configuration values, data migration, and how to deploy repeatedly. Owner: release owner with the build engineer.
- Prepare the buildThe build engineer confirms the sources and versions to be used, with the configuration manager. Only controlled versions are taken.
- Build and configureBuild the package with an automated, logged process where possible, apply the version number and record the source versions used. Owner: build engineer.
- Check integrityCalculate checksums or signatures, scan the package for known vulnerabilities and malware, and compare it with the approved list of components. Information security reviews findings. Target: before test.
- StoreThe package is placed in the definitive repository as read-only. Output: release package stored and CIs updated as in build in the CMDB.
| Package content | Check |
|---|
| Executable or deployable files | Built from tagged source; checksum recorded |
| Configuration files and environment values | Reviewed; secrets are not included in the package but supplied by the secret store |
| Database or data scripts | Tested forward and, where possible, backward |
| Deployment and backout scripts | Tested in a production-like environment |
| Release notes and support information | Reviewed by the service desk and resolver groups |
| Documents and training material | Reviewed and version controlled |
7.8 Release acceptance
- Test the releaseThe test lead tests the built package in the test environments, including deployment and backout, against the acceptance criteria. Output: test results. Owner: test lead.
- RehearseFor a major release or a medium or high risk change the deployment is rehearsed in pre-production with the real team, timed and recorded.
- Hold the readiness reviewAt least [2 working days] before deployment the release manager chairs a review of test results, open defects, risks, resources, communications and backout readiness. Attendees: release owner, test lead, resolver groups, service owner, information security.
- DecideThe service owner decides accept, accept with conditions, or reject. Conditions are recorded with owners and dates.
- AuthoriseThe change authority confirms the window and authorises deployment. Output: go decision on the release record.
| Readiness checklist item | Required state |
|---|
| Change approved and window confirmed | Yes |
| Acceptance criteria met | All critical; major defects accepted by the service owner in writing |
| Security checks complete | No open high-risk finding |
| Backup or snapshot of production taken | Yes, and the restore tested within the last [6 months] |
| Backout plan tested | Yes for medium and high risk |
| Support staff briefed | Service desk and on-call staff have the release notes |
| Customers and users informed | Notice sent within the notice period |
| CMDB baseline of the current state taken | Yes |
7.9 Deployment
- Pre-deployment checksThe deployment engineer confirms the go decision, the package checksum, the environment state, the availability of staff and the backups. Target: at window start.
- AnnounceThe service desk and monitoring team are informed of the start; customers are informed if the plan requires.
- DeployDeploy in the planned order, recording the start and end time of each step. Where possible deploy a small portion first (a canary or pilot group) before the whole.
- VerifyRun the post-deployment checks: service health, key transactions, monitoring, logs and security checks. A second person confirms the result.
- Decide on backoutIf a check fails and cannot be fixed within the time set in the plan [30 minutes], the release owner invokes backout. The decision and time are recorded.
- ConfirmThe release owner announces completion to the service desk, the service owner and customers, and the release record is completed. Target: within [1 hour] of the end of the window.
- Update recordsThe CMDB, release baseline, service catalogue and knowledge base are updated. Target: [2 working days].
Note. Production credentials used for deployment are issued for the window and revoked at its end. Deployment actions are logged so that they can be reviewed.
7.10 Early life support
Early life support gives closer attention to a newly released service so that problems are found and fixed quickly.
| Release type | Duration | What happens |
|---|
| Major | [30 days] | Daily review of incidents; release team on call; fixes through emergency release if needed; weekly report to the service owner |
| Minor | [5 working days] | Daily check of incidents and monitoring by resolver groups; release owner available |
| Maintenance | [2 working days] | Check of monitoring and incidents |
| Emergency | [5 working days] | As minor, plus a review of the root cause |
Incidents caused by a release are linked to the release record. Problems found are logged under the Problem Management Procedure with the release as the source. When early life support ends, the service owner confirms that the release performs as planned and the release owner closes the record, adding a short review of what went well and what did not.
8. Interfaces with other processes
| Process | Interface |
|---|
| Change management | Every release is authorised by a change; the change calendar fixes the window. |
| Service design and transition | Major releases carry out the transition plan; acceptance criteria come from the design. |
| Configuration and asset management | Release content is recorded as CIs; baselines are taken before and after. |
| Incident and problem management | Release-related incidents are linked; known errors travel with the release notes. |
| Capacity management | Capacity checks are part of the release tests. |
| Information security management for services | Security scans, credentials and approvals apply to every release. |
| Supplier management | Releases supplied by suppliers follow the same acceptance rules. |
9. Key Performance Indicators
| Measure | Target | Source | Frequency |
|---|
| Releases deployed in the planned window | [95%] | Release records | Monthly |
| Releases with no incident above priority [3] in early life support | [95%] | Incident records | Monthly |
| Releases backed out | Below [5%] | Release records | Monthly |
| Emergency releases as a share of all releases | Below [10%] | Release records | Monthly |
| Releases built only from the definitive repository | [100%] | Audit of build records | Quarterly |
| Releases with readiness review held before deployment | [100%] | Release records | Monthly |
| Release records and CMDB updated within [2 working days] | [95%] | CMDB audit sample | Monthly |
| Satisfaction of service owners with release quality | [4 out of 5] | Survey | Half-yearly |
10. Records and evidence
| Record | Kept in | Owner | Retention |
|---|
| Release record and plan | Ticketing tool | Release manager | [3 years] |
| Build logs and checksums | Build tool | Build engineer | [1 year] |
| Release packages | Definitive repository | Release manager | Last [5] versions plus every production release in [12 months] |
| Test results and readiness review minutes | Test management tool and document system | Test lead | [3 years] |
| Deployment logs and verification results | Deployment tool | Deployment engineer | [1 year] |
| Early life support reviews | Ticketing tool | Release owner | [3 years] |
Annexure A: Release record
| Field | Entry |
|---|
| Release identifier and version | |
| Type (major, minor, maintenance, emergency) | |
| Release owner | |
| Changes included (RFC numbers) | |
| Services and CIs affected | |
| Planned window | |
| Build: date, builder, source versions, checksum | |
| Test results summary and open defects | |
| Readiness review: date, attendees, decision | |
| Authorisation: name, role, date | |
| Deployment: start, end, deployer, result | |
| Backout used (yes, no) and reason | |
| Early life support: end date and findings | |
| Closure: date, CMDB updated, lessons | |
Annexure B: Release calendar
| Release identifier | Type | Services | Build start | Readiness review | Deployment window | Release owner | Status |
|---|
| [REL-2026-07] | [Minor] | [Customer platform] | [date] | [date] | [date, 22:00 to 02:00] | [Name] | [Planned] |
| | | | | | | |
| | | | | | | |
Annexure C: Deployment checklist
| Step | Done by | Time | Result | Notes |
|---|
| Go decision and checksum confirmed | | | | |
| Backups and snapshots confirmed | | | | |
| Start announced to service desk | | | | |
| Deployment steps completed in order | | | | |
| Post-deployment checks passed | | | | |
| Completion announced | | | | |
| CMDB and baseline updated | | | | |
Annexure: Document history
| Version | Date | Author | Reviewed by | Approved by | Summary of change |
|---|
| [1.0] | [date of issue] | [Process manager] | [Process owner] | [Management representative] | Initial issue of SM15 |
| | | | | |
| | | | | |
11. Exception
Exceptions to this document are allowed only where compliance is not practicable and the risk has been assessed. A request must state what is to be excepted, why, the risk it creates, the compensating controls, and an end date no later than [6 months]. It is approved in writing by the document owner and the risk owner, recorded in the exceptions register, and reviewed at the end date. An exception does not change the document.
12. Enforcement
Compliance is monitored through internal audits, management review and routine checks by the document owner. Non-compliance is reported through the incident or non-conformity process and handled under the organisation's disciplinary procedure, and under the terms of any contract for people who are not employees. Serious or repeated non-compliance may lead to loss of access and, where the law is broken, to referral to the authorities.
13. Review
This document is reviewed at least every [12 months], and when there is a significant change to the organisation, its systems, its risks or the law, or after an incident that shows it was not effective. Each review is recorded in the revision history.
ISO/IEC 20000-1:2018 references
| Reference | Title |
|---|
| 8.5.3 | Release and deployment management |
| 8.5.1 | Change management |
| 8.5.2 | Service design and transition |
| 8.2.6 | Configuration management |