Change Enablement Policy: [Organisation name]
Organisation policy for changes to services and configuration items: what is a change, change types (standard, normal, emergency), risk assessment, change authorities by type and risk, peer review and the change advisory meeting, standard change models, the change schedule and freeze periods, the emergency path, automated pipelines as a control, separation of duties, records, and change metrics including the DORA software delivery metrics. Structure aligned with ISO/IEC 20000-1:2018 with Amendment 1:2024 (the current edition as of October 2026), clause 8.5.1 change management (8.5.1.1 policy, 8.5.1.2 initiation, 8.5.1.3 activities), and ISO/IEC 27001:2022 Annex A control 8.32. "Change enablement" is the ITIL practice name, cited by name only. This policy sets the rules; each change is recorded with the Change Request template (ops/change-request). Replace every [bracketed] value and every row marked Example.
Document control
| Field | Value |
|---|
| Document ID | [POL-ITSM-CHG] |
| Version | [1.0] |
| Status | [Draft / In review / Approved / Retired] |
| Owner (change enablement process owner) | [@change-manager] |
| Approvers/reviewers | [@head-of-service-management], [@cto], [@ciso] |
| Applies to | [Services, environments and teams in scope] Example: All production services and their configuration items, including infrastructure as code, managed cloud services and supplier-operated components |
| Effective date | YYYY-MM-DD |
| Next review | YYYY-MM-DD (at least yearly) |
| Last updated | YYYY-MM-DD |
| Classification | [Internal] |
Approvals
| Role | Name | Date |
|---|
| Process owner | [@name] | YYYY-MM-DD |
| Head of service management | [@name] | YYYY-MM-DD |
| Chief information security officer | [@name] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change summary |
|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 1.0 | YYYY-MM-DD | [@name] | Example: Approved; weekly change advisory meeting limited to High risk changes |
| 1.1 | YYYY-MM-DD | [@name] | Example: Added "removes a safety check?" question to the risk model after problem PRB-0042 |
Contents
1. Purpose, scope and principles
Purpose. Increase the number of successful changes to services by making sure that risks are assessed, changes are authorised by the right people, and the organisation learns from changes that fail, while keeping the time from idea to production as short as safety allows.
Scope. Every addition, modification or removal of a configuration item that could affect a service in the service catalogue, in every environment that serves users or holds production data. Out of scope: [list] Example: content edits through the content management system, routine data changes made through application features, and changes in development environments that never hold production data.
| Principle | Meaning in practice |
|---|
| CHG-P1 Risk decides the route | The more a change can hurt, the more scrutiny it receives; low risk changes are not slowed down to match high risk ones |
| CHG-P2 Authority sits close to the work | The people who understand the change and the service decide, wherever possible by peer review |
| CHG-P3 Automate the evidence | Tests, approvals and deployment logs recorded by the pipeline count as evidence; nobody re-types them |
| CHG-P4 Every change is traceable | Each change links to its configuration items, its record and, if it fails, to the incident it caused |
| CHG-P5 Learn from failure | Failed changes are reviewed without blame and feed the risk model and change models |
2. Definitions
| Term | Meaning in this policy |
|---|
| Change | Adding, modifying or removing anything that could directly or indirectly affect a service |
| Change record | The record of one change, using ops/change-request or the equivalent pipeline record |
| Change authority | The person or group allowed to authorise a type or risk class of change |
| Change model | A pre-defined, tested way to carry out a recurring kind of change, with its own risk assessment and steps |
| Change schedule | The calendar of planned and implemented changes, shared with the service desk and stakeholders |
| Freeze period | A period during which only listed kinds of change may be made |
| Failed change | A change that caused an incident, was backed out, or needed an unplanned fix to restore service |
| Configuration item (CI) | A component that is managed to deliver a service, recorded in the CMDB (ops/cmdb-data-model) |
3. Roles
| Role | Responsibilities |
|---|
| Change requester | Raises the change with a clear reason and expected benefit |
| Change owner | Accountable for the change from assessment to closure, including risk assessment, scheduling and review |
| Implementer | Carries out the change and records the result; never authorises their own Medium or High change |
| Peer reviewer | A qualified engineer who reviews Low and Medium changes for correctness and risk |
| Service owner | Accepts business risk for changes to their service; authorises Medium and High changes |
| Change advisory meeting | A forum of service owners, security and operations that advises on High risk changes and conflicts |
| Emergency change authority | A small named group (on-call manager plus service owner, or their deputies) that authorises emergency changes |
| Change manager | Owns this policy, the change schedule, change models and metrics; facilitates the change advisory meeting |
4. Change types
| Type | Definition | Route | Lead time (Example) |
|---|
| Standard | Low risk, repeatable change that follows an approved change model (section 7) | Pre-authorised; implementer follows the model and the record is created by the tool or pipeline | None beyond the model's own steps |
| Normal | Any change that is not standard or emergency | Assessed and authorised by risk class (sections 5 and 6) | Low: same day; Medium: 2 business days; High: 5 business days |
| Emergency | Must be made as soon as possible to restore service, prevent imminent serious harm or close an actively exploited vulnerability | Emergency path (section 9) | As fast as safely possible |
- A change that does not match its model exactly is a normal change.
- Urgency alone does not make a change an emergency: a missed deadline for a planned project is a normal change with a request for faster assessment.
- Security patches follow the cadences in
ops/patch-management-policy; routine patching runs as standard changes where a model exists.
5. Risk and impact assessment
Every normal change is scored on six questions, each from 1 (lowest risk) to 3 (highest risk). The Change Request template (ops/change-request, section 2.2) uses the same questions.
| Question | 1 | 2 | 3 |
|---|
| How critical is the affected service? | Internal, non-critical | Important, workaround exists | Tier 1 or revenue-bearing |
| How many users or customers are affected if it fails? | Few, internal | A segment | All, or external customers |
| Has this kind of change succeeded here before? | Many times | Similar changes | Never |
| Is the change reversible within the window? | Fully, tested | Partly, or untested | No |
| Was it tested in a production-like environment? | Yes, with production-like data | Partly | No |
| Does it change security controls or data flows? | No | Indirectly | Yes |
| Total score | Risk class (Example) |
|---|
| 6 to 8 | Low |
| 9 to 12 | Medium |
| 13 to 18 | High |
Overriding rules (Example):
- A score of 3 on reversibility makes the change High, whatever the total.
- A change that removes or weakens a safety check (validation, rate limit, alert, backup, access control) is at least Medium.
- A change during a freeze period (section 8) is at least High, unless the freeze exception list allows it.
6. Change authorities
| Change type or risk class | Change authority (Example) | Minimum evidence |
|---|
| Standard | Change model owner (pre-authorised through the model) | Pipeline or tool record showing the model steps passed |
| Low | Peer review by a second qualified engineer | Approved code or configuration review, tests passed |
| Medium | Service owner plus technical peer | Risk assessment, test evidence, backout plan |
| High | Service owner after advice from the change advisory meeting, with security for security-relevant changes | All of the above, plus rehearsed backout and communication plan |
| Emergency | Emergency change authority (on-call manager and service owner) | Verbal or chat approval recorded with time; full record within [2] business days |
6.1 Change advisory meeting
| Item | Rule (Example) |
|---|
| Purpose | Advise on High risk changes, resolve schedule conflicts, review failed changes and the metrics |
| Members | Change manager (chair), owners of the services on the agenda, operations lead, security representative, service desk lead |
| Cadence | Weekly, 30 minutes; cancelled if no High change is pending |
| Inputs | Change records submitted at least 3 business days before the meeting |
| Outputs | Advice recorded on each change record; actions in the minutes |
| Quorum | Chair plus the service owner of each change discussed |
7. Standard change models
| Model ID | Description | Owner | Preconditions | Approved | Review due | Failures in last 12 months |
|---|
| CM-001 (Example) | Application deployment through the main pipeline with automated tests and canary release | [@platform-lead] | All pipeline gates green; no open P1 or P2 on the service | YYYY-MM-DD | YYYY-MM-DD | 2 of 1,140 |
| CM-002 (Example) | Monthly operating system patching of non-critical servers, ring by ring | [@infra-lead] | Previous ring healthy for 24 h | YYYY-MM-DD | YYYY-MM-DD | 0 of 36 |
| CM-003 (Example) | Add or remove a user-facing feature flag | [@product-eng-lead] | Flag registered, owner named | YYYY-MM-DD | YYYY-MM-DD | 1 of 410 |
| CM-004 (Example) | Scale a stateless service within approved limits | [@sre-lead] | Within the capacity plan limits | YYYY-MM-DD | YYYY-MM-DD | 0 of 95 |
| [CM-] | [Description] | [@name] | [Preconditions] | YYYY-MM-DD | YYYY-MM-DD | [n of m] |
Model lifecycle: a model is proposed with at least [5] successful normal changes of the same kind, approved by the change manager and the service owner, reviewed yearly, and suspended after any failure that caused a P1 or P2 incident until the problem review is complete.
8. Change schedule and freeze periods
8.1 Change schedule
All Medium, High and emergency changes appear on the change schedule with service, configuration items, window and change owner. Standard changes are visible in the pipeline log and summarised on the schedule. The service desk reviews the schedule at the start of each shift.
8.2 Freeze periods (Example)
| Freeze | Dates | Scope | Allowed during freeze | Exception authority |
|---|
| FRZ-01 Peak trading | [YYYY-MM-DD to YYYY-MM-DD] Example: Last two weeks of November | Checkout, payments, orders, warehouse systems | Emergency changes; standard models CM-002 and CM-004 | Head of service management and the service owner |
| FRZ-02 Financial year end | [YYYY-MM-DD to YYYY-MM-DD] | Finance and reporting systems | Emergency changes only | Chief financial officer delegate and service owner |
| FRZ-03 Major event | [Dates] | [Scope] | [Allowed] | [Authority] |
A freeze exception is requested on the change record, explains why the change cannot wait, and is decided before scheduling.
9. Emergency changes
| Step | Rule (Example) |
|---|
| 1 Qualify | The change meets the emergency definition in section 4, usually linked to a P1 or P2 incident or an actively exploited vulnerability |
| 2 Authorise | Emergency change authority approves by call or chat; the approval time and names are recorded |
| 3 Minimum safety | A second engineer reviews the command or diff before it runs, unless that would extend a P1 outage, in which case the review happens within [24] hours |
| 4 Implement | Changes are made through the normal tooling where possible, so that logs exist |
| 5 Record | A full change record is completed within [2] business days |
| 6 Review | Every emergency change is reviewed at the next change advisory meeting |
Indicator: if emergency changes exceed [5]% of all changes in a month, the change manager reviews why with the service owners concerned.
10. Automated pipelines and separation of duties
| Control | Requirement (Example) | Evidence |
|---|
| CHG-C01 Version control | Every change to code and infrastructure configuration is committed to version control | Commit history |
| CHG-C02 Independent review | Merges to the main branch need approval from someone other than the author | Repository branch protection settings and review log |
| CHG-C03 Automated tests | Unit, integration and security checks pass before deployment | Pipeline run record |
| CHG-C04 Progressive release | Production deployments use canary or ring release with automatic rollback on health checks | Deployment log |
| CHG-C05 No direct production access for change | Manual production changes only through break-glass access, which is logged and reviewed | Access logs reviewed in ops/access-review |
| CHG-C06 Traceability | Deployments carry the change or model ID | Deployment metadata |
Separation of duties: the person who writes a change does not alone approve it for production. In small teams where full separation is not possible, a compensating control applies (Example): automated tests plus after-the-fact review of every production change within [1] business day.
11. Post-implementation review and records
| Change category | Review rule (Example) |
|---|
| Failed changes (incident, backout or unplanned fix) | Always reviewed; problem record opened if the cause is not obvious |
| Emergency changes | Always reviewed at the next change advisory meeting |
| High risk changes | Always reviewed by the change owner within [5] business days |
| Medium and Low changes | A [5]% sample reviewed monthly by the change manager |
| Standard changes | Reviewed through model failure counts in section 7 |
Records: change records are kept for [3] years or longer if a contract or regulation requires it. Configuration item records in the CMDB are updated as part of closing each change.
12. Change metrics
12.1 DORA software delivery metrics
The DORA research programme describes five software delivery performance metrics, grouped as throughput and instability (checked at dora.dev on 2026-10-30):
| Metric | Group | Definition used here | Target (Example) |
|---|
| Change lead time | Throughput | Time from commit to running in production | Median under 1 day for CM-001 |
| Deployment frequency | Throughput | Number of production deployments per period | Trend only |
| Failed deployment recovery time | Throughput | Time to recover from a deployment that needs immediate intervention | Median under 1 hour |
| Change fail rate | Instability | Share of deployments needing immediate intervention such as rollback or hotfix | Below 5% |
| Deployment rework rate | Instability | Share of deployments that are unplanned and triggered by a production incident | Trend only |
12.2 Control metrics
| ID | Measure | Formula | Target (Example) |
|---|
| CHG-M01 | Change failure rate (all change types) | failed changes / changes implemented | Below 5% |
| CHG-M02 | Emergency change share | emergency changes / changes implemented | Below 5% |
| CHG-M03 | Standard change share | standard changes / changes implemented | Above 60% and rising |
| CHG-M04 | Unauthorised changes found | changes detected without a record or model | 0 |
| CHG-M05 | Records completed on time | emergency records completed within 2 business days / emergency changes | 100% |
| CHG-M06 | Incidents caused by change | incidents linked to a change / incidents | Trend only |
Worked example (Example): in a quarter with 214 implemented changes (150 standard, 58 normal, 6 emergency) and 7 failed changes, the change failure rate is 7 / 214 = 3.27%, the emergency share is 6 / 214 = 2.8% and the standard share is 150 / 214 = 70.1%. The same figures appear in the Service Review Report example (ops/service-review-report).
13. Exceptions and non-compliance
| Item | Rule (Example) |
|---|
| Exception request | Raised to the change manager with scope, reason, compensating controls and end date |
| Exception approval | Head of service management; security exceptions also need the chief information security officer |
| Maximum duration | [90] days, renewable once with fresh review |
| Unauthorised change detected | Logged as an incident, assessed for impact, retrospective record created within [1] business day, root cause reviewed |
| Repeated non-compliance | Escalated to the team's line management with a corrective action plan |
14. Standards mapping and references
| Section of this policy | ISO/IEC 20000-1:2018 | ISO/IEC 27001:2022 Annex A | Topic (short original label) |
|---|
| 1, 2, 4 Scope, definitions, types | 8.5.1.1 Change management policy | 8.32 Change management | Define what is controlled and how changes are classified |
| 5, 6 Risk and authority | 8.5.1.2 Change management initiation, 8.5.1.3 Change management activities | 8.32 | Assess, approve and plan changes |
| 7 Change models | 8.5.1.3 | 8.32 | Pre-defined routes for repeatable changes |
| 8 Schedule and freezes | 8.5.1.3 | 8.32 | Plan and communicate the schedule |
| 9 Emergency changes | 8.5.1.3 | 8.32 | Handle urgent change with control |
| 10 Pipelines and separation | 8.5.3 Release and deployment management | 8.25 Secure development life cycle, 8.31 Separation of environments, 5.3 Segregation of duties | Controlled deployment |
| 11 Review and records | 8.5.1.3, 8.2.6 Configuration management, 10.2 Continual improvement | 8.32, 8.9 Configuration management | Review results and update records |
| 12 Metrics | 9.1 Monitoring, measurement, analysis and evaluation, 9.4 Service reporting | | Measure and report |
| Reference | Version or date checked | Use |
|---|
| ISO/IEC 20000-1:2018, Information technology, Service management, Part 1: Service management system requirements, with Amd 1:2024 | Current edition as of October 2026 | Clause numbers |
| ISO/IEC 27001:2022, Information security management systems, Requirements, with Amd 1:2024 | Current edition as of October 2026 | Annex A control numbers |
| DORA software delivery performance metrics, dora.dev/guides/dora-metrics | Checked 2026-10-30 | Names and definitions of the five metrics, summarised |
| ITIL, PeopleCert | ITIL 4 available; ITIL (Version 5) released in phases from 2026; checked 2026-10-30 | Practice name "change enablement" and change type names, by name only |
Standard and licence note
Structure aligned with ISO/IEC 20000-1:2018 with Amendment 1:2024, clause 8.5.1 change management and the related clauses in section 14, and with ISO/IEC 27001:2022 with Amendment 1:2024, Annex A control 8.32. Both are copyrighted standards: this template cites clause and control numbers with short original labels only; no text, table or definition is copied. Official text: ISO, purchase or licensed access: https://www.iso.org/standard/70636.html (ISO/IEC 20000-1) and https://www.iso.org/standard/82875.html (ISO/IEC 27001), also sold by national standards bodies. The DORA metric names are summarised from the public DORA guide at https://dora.dev/guides/dora-metrics/. The practice name change enablement and the change type names follow common ITIL usage and are cited by name only; ITIL is published by PeopleCert, which released ITIL (Version 5) in phases during 2026 while ITIL 4 remains available (https://www.peoplecert.org/news-and-announcements/itil-version-5-explained); ITIL is a registered trademark of the PeopleCert group. The risk model, authorities, lead times, freeze examples and targets are illustrative, not taken from any standard. All text is original, written for this collection. Check the current edition of any standard you certify against. Template licence: MIT.