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
Most serious service failures follow a change that nobody assessed, tested or told others about. At the same time, an organisation that cannot change quickly cannot respond to customers or threats. This procedure lets the Organisation change services at the pace the business needs while keeping the risk visible, the decisions accountable and the records complete.
The security aspects of change, such as review of security impact and separation of environments, are set out in the Change Management Policy and Procedure; this procedure covers the service management process.
2. Purpose
The purpose is to make sure that every change to a service or a configuration item is requested, assessed for benefit and risk, authorised at the right level, scheduled to avoid conflict, implemented with a way back, and reviewed, so that changes succeed without causing incidents.
3. Objectives
- Every change to a production service is recorded before implementation, apart from standard changes that are logged as they are done.
- At least [95%] of changes are successful, meaning they achieve their purpose with no incident or unplanned outage.
- Emergency changes remain below [5%] of all changes, and each is reviewed afterwards.
- Changes are approved by an authority proportionate to their risk, and no person approves their own change.
- Conflicts between changes are found and removed before the change window through a single change calendar.
- The CMDB and service documentation are updated within [2 working days] of each change closure.
4. Scope
- In scope: addition, modification, removal or replacement of services, service components, configuration items, service level targets, supplier arrangements, documents that define services, and the security configuration of any of them.
- In scope: changes initiated by service owners, projects, resolver groups, suppliers, security, customers and the problem process.
- In scope: emergency changes made to restore service or to stop an active security threat.
- Out of scope: service requests that follow a fixed procedure with no effect on the service (for example a password reset), which are handled by the service request process, and changes to staff or organisation structure.
- Applies to: all staff and suppliers who plan, assess, approve or make changes in the production environment.
5. Terms and definitions
| Term | Meaning |
|---|
| Change | The addition, modification or removal of anything that could have an effect on services. |
| Request for change (RFC) | A formal proposal for a change, recorded in the ticketing tool. |
| Change authority | The person or group that approves a change. It may be the change manager, a change advisory board, or senior management, depending on risk. |
| Change advisory board (CAB) | A group that advises the change authority and reviews higher-risk changes; it includes technical, service and security members. |
| Standard change | A pre-approved, low-risk, repeatable change that follows a documented procedure. |
| Normal change | Any change that is not standard or emergency, assessed and approved case by case. |
| Emergency change | A change that must be made faster than the normal process allows, to restore a service or stop a threat. |
| Change calendar | The schedule of approved changes and blackout periods. |
| Post-implementation review | A check after a change that it achieved its purpose and caused no harm. |
6. Change Management Policy
6.1 Objectives of the policy
- Protect the services customers depend on from harm caused by change.
- Enable the changes that the business needs to be delivered quickly and predictably.
- Give every change an accountable owner, a record and a decision that can be explained later.
- Learn from failed changes and feed what is learned into design, testing and the next change.
6.2 Principles
- Every change is recorded, and a change that is not recorded is a breach of this policy and is treated as an unauthorised change.
- The effort of control matches the risk: low-risk repetitive changes are pre-approved, high-risk changes are examined by senior people.
- No one approves a change they requested or will implement, apart from pre-approved standard changes.
- Every change is tested or otherwise verified in a place that resembles production before it is made, and has a backout plan that has been considered.
- Changes are made in agreed windows and avoid blackout periods, unless the change authority accepts the risk in writing.
- Customers and users are told in advance of changes that affect them.
- Security and privacy impact is assessed for every change that is not standard, by information security where the risk is medium or higher.
- Changes made by suppliers on the Organisation's behalf follow this procedure.
- Emergency change is for emergencies, not for late planning, and is reviewed within [2 working days].
6.3 Policy statements
- Only the change manager, or a deputy appointed in writing, may approve normal changes of low risk; others follow the approval authority table.
- Developers do not have write access to production unless it is granted for the duration of an approved change.
- All change records identify the configuration items affected, so that the CMDB can be updated.
- A change that fails is backed out unless the change authority decides otherwise, and a review is held.
- Management receives a monthly report of volume, success rate, emergency changes and unauthorised changes.
- Adherence to this policy is checked by internal audit and by the change manager's monthly sample.
7. Roles and Responsibilities
| Role | Responsibilities |
|---|
| Process owner | Owns this procedure, appoints the change manager and approves the approval authority table and the standard change catalogue. |
| Change manager | Runs the process, triages requests, chairs the CAB, keeps the change calendar, monitors success, and produces the monthly change report. |
| Change requester | Describes the change, its reason and the benefit, and supplies the plans, tests and backout. |
| Change owner | Is accountable for one change from request to review. Usually the requester or a delegated engineer. |
| Change implementer | Carries out the change as approved and records the result. |
| Change authority | Approves or rejects changes within its limits. Levels are given in the approval authority table. |
| Change advisory board | Reviews medium and high risk changes for technical, service, security and customer impact, and advises the change authority. |
| Emergency change group | A small group of change manager, service owner and technical lead (or their deputies) that can approve emergency changes at any hour. |
| Service owner | Confirms business timing and impact and accepts residual risk to the service. |
| Information security | Assesses security and privacy impact, and may require extra controls or reject. |
| Release manager and configuration manager | Schedule releases and keep the CMDB up to date for each change. |
| Activity | Responsible | Accountable | Consulted | Informed |
|---|
| Raise request for change | Change requester | Change owner | Service owner | Change manager |
| Triage and categorise | Change manager | Process owner | Change owner | Service desk |
| Assess risk and impact | Change owner | Change manager | Information security, Service owner, Resolver groups | Configuration manager |
| Approve change | Change authority | Process owner | Change advisory board, Service owner | Change owner |
| Schedule and keep calendar | Change manager | Process owner | Release manager, Service owner | Service desk, Customer representative |
| Implement and record result | Change implementer | Change owner | Resolver groups | Service desk |
| Review and close | Change owner | Change manager | Service owner, Configuration manager | Process owner |
| Approve emergency change | Emergency change group | Change manager | Information security | Top management |
8. Change Management Process
8.1 Inputs and outputs
| Inputs | Outputs |
|---|
| Requests from service owners, projects, suppliers and customers | Approved, rejected or deferred changes with reasons |
| Problem records and known errors needing a fix | Change calendar and communication of schedule |
| Incident records requiring urgent change | Implemented changes with results and reviews |
| Release plans and service design packages | Updated CMDB and documentation |
| Security alerts and vulnerability findings | Monthly change report and improvement actions |
| Risk assessments and lessons from earlier changes | Standard change catalogue, kept current |
8.2 Process flow
- The requester raises an RFC in the ticketing tool.
- The change manager checks completeness and decides the change type: standard, normal or emergency.
- Standard changes are executed under their procedure and logged. Normal and emergency changes continue to assessment.
- The change owner assesses risk and impact; the change manager assigns the risk level.
- The change authority for that level approves, rejects or defers the change.
- The change is placed in the change calendar and communicated.
- The implementer makes the change in its window and records the result; failure triggers the backout plan.
- The change owner verifies the result, updates the CMDB and documents, and closes the record.
- The change manager reviews selected changes after implementation and reports.
8.3 Types of change
| Type | Description | Approval | Lead time |
|---|
| Standard | Low risk, well understood, repeatable, with a documented procedure and a place in the standard change catalogue. Examples: add a user to a group, replace a failed disk, renew a certificate. | Pre-approved by the process owner when the entry is added to the catalogue; no case-by-case approval. | Logged when done, or booked [1 working day] ahead where it affects users |
| Normal | Any change that is not standard or emergency. Divided into low, medium and high risk by the risk matrix. | By the change authority for the risk level in the approval authority table. | Low [2 working days]; medium [5 working days]; high [10 working days] |
| Emergency | A change needed at once to restore a failed service, to stop a security incident or to meet a legal deadline. | By the emergency change group, in person or by recorded message. | As fast as safety allows; paperwork within [2 working days] |
Note. A standard change is added to the catalogue only after the same change has been made successfully at least [3 times] under normal change, with documented steps and checks. The catalogue is reviewed every [6 months] and an entry is removed after a failure that was caused by the change itself.
8.4 Request for change
- RaiseThe requester raises an RFC with reason and benefit, services and CIs affected, proposed date and window, implementation steps, test evidence, backout plan, who will implement, and who needs to be told. Owner: requester. Target: lead time for the type.
- CheckThe change manager checks completeness and rejects or returns incomplete requests with comments. Target: [1 working day].
- CategoriseThe change manager sets the type, a first risk view and the change authority, and names the change owner. Target: [1 working day].
- LinkRelated incidents, problems, releases and projects are linked so that the history is complete.
A change that arises from an incident or problem keeps the link to that record, and the incident or problem is not closed until the change is closed.
8.5 Assessment of risk and impact
- Identify impactThe change owner lists the services, customers, suppliers and CIs affected, and the effect if the change fails. Use the CMDB dependencies.
- Rate likelihood and impactScore each from 1 to 3 using the matrix below. Consider previous failures, complexity, test quality, timing and the skill of the implementer.
- Assess security and privacyInformation security rates security and privacy effect for every normal change of medium or higher risk and any change touching customer data, access control, network boundary or cryptography.
- Check capacity and continuityThe change owner asks the capacity manager and continuity manager for comment where load or recovery is affected.
- Confirm the backoutThe backout plan states the trigger, steps, time to execute and who decides. It is tested where the risk is medium or higher.
- RecordThe assessment is stored on the RFC. Target: complete [2 working days] before the CAB.
| Impact of failure / Likelihood | Low (1) | Medium (2) | High (3) |
|---|
| Minor, one team affected (1) | Low | Low | Medium |
| Moderate, one service degraded (2) | Low | Medium | High |
| Major, a tier 1 service or many customers (3) | Medium | High | High |
8.6 Approval authority
A change is approved by the level that matches its risk. The approval is recorded in the RFC with the name, time and any conditions. The requester and the implementer cannot approve their own change.
| Risk level | Change authority | Advice sought from | Time to decide |
|---|
| Standard | Pre-approved by the process owner | Not applicable | Not applicable |
| Low | Change manager or deputy | Service owner for timing | [2 working days] |
| Medium | Change advisory board with the service owner | Information security, resolver groups, capacity manager | At the next CAB, within [5 working days] |
| High | Change advisory board and the process owner, with top management informed | As medium, plus customer representative | Within [10 working days] |
| Major (new service, large migration) | Handled under the Service Design and Transition Procedure; gate 5 approval by the change authority | Transition team | As the transition plan states |
| Emergency | Emergency change group | Information security by phone | Within [1 hour] of the request, any time |
The change advisory board meets [weekly] and on demand. Quorum is the change manager, a service owner or delegate, one resolver group lead and information security. Its agenda covers: review of changes since last meeting (successes, failures, emergency changes), changes proposed for approval, the change calendar for the next [2 weeks], and lessons and improvements.
8.7 Scheduling and the change calendar
- The change manager keeps a single change calendar covering all services, showing approved changes, owners, windows, affected services and blackout periods.
- Standard windows are [Tuesday and Thursday, 22:00 to 02:00 local time] for tier 1 services; other windows are agreed with the service owner.
- Blackout periods apply for [month-end close, customer peak events and the last week of the financial year], and changes then need approval from the process owner.
- Two changes affecting the same service or the same CI are not placed in one window without a stated reason.
- The calendar is published to the service desk, resolver groups and customer representatives, and updated within [1 working day] of any move.
- Where several changes belong together, the release manager groups them into a release under the Release and Deployment Management Procedure.
8.8 Implementation
- Confirm readinessBefore the window the change owner confirms approval, tests passed, resources ready, backups taken and communications sent. If any is missing, the change is postponed.
- StartThe implementer informs the service desk and the monitoring team that the change is starting and sets a monitoring note on the affected services.
- ImplementMake the change exactly as approved. Any deviation is recorded and, if it alters the risk, referred to the change authority.
- VerifyThe implementer runs the post-change checks in the plan and the service owner or monitoring confirms service health. Target: within [30 minutes] of finishing.
- Back out if neededIf the checks fail or the window ends, the change owner invokes the backout plan, informs the change manager, and records the reason.
- RecordThe implementer records start and end time, result (successful, successful with issues, backed out, failed), and actual effects. Target: same working day.
| Result | Meaning | Action |
|---|
| Successful | Purpose achieved; no incident | Close after review |
| Successful with issues | Purpose achieved; minor incident or deviation | Review and learn; close |
| Backed out | Change reversed as planned | Understand cause; raise a new RFC |
| Failed | Purpose not achieved, service harmed | Raise incident; mandatory review |
8.9 Emergency change
- DeclareThe incident manager, service owner or security lead requests an emergency change by phone and raises the RFC as soon as possible. Owner: requester.
- ConveneThe change manager (or deputy) convenes the emergency change group within [1 hour]. A group of at least three members including one service owner approves.
- Assess brieflyThe group considers what will happen if the change is not made, what could go wrong, and how to reverse it.
- Decide and recordDecision, names and time are recorded. Security impact is checked by phone.
- ImplementCarry out the change under the same implementation rules, with a person to check results.
- Complete recordsFull details of the RFC and CMDB updates are completed within [2 working days], and a review is held within [5 working days].
Note. If three emergency changes are made for the same cause in a quarter, the change manager raises a problem record and reports it to management.
8.10 Post-implementation review and closure
- Review sampleThe change manager reviews every failed, backed out and emergency change, every change with incidents, and a sample of [10%] of the others. Target: [5 working days] after implementation.
- QuestionsWas the purpose achieved? Was the plan followed? Were there incidents? Was the backout needed? Were the estimates of risk and time correct? Was the CMDB updated?
- LearnFindings are recorded; weaknesses in tests, assessment or planning go to the improvement log. A repeat failure leads to a problem record.
- CloseThe change is closed only when the CMDB and documents are updated and review items are done.
9. Interfaces with other processes
| Process | Interface |
|---|
| Incident and problem management | Incidents may need emergency change; problems produce changes; failures create incidents. |
| Release and deployment management | Releases are authorised by change records and built from approved changes. |
| Configuration and asset management | Changes name the CIs and trigger CMDB updates. |
| Service design and transition | Major changes are managed as transitions with gate 5 approval through change management. |
| Capacity and demand management | Capacity changes follow this procedure; capacity advises on risk. |
| Supplier management | Changes at suppliers that affect services are submitted as RFCs. |
| Information security management for services | Security impact is assessed for changes; security fixes may be urgent changes. |
10. Key Performance Indicators
| Measure | Target | Source | Frequency |
|---|
| Change success rate | [95%] or higher | Change records | Monthly |
| Emergency changes as a share of all changes | Below [5%] | Change records | Monthly |
| Unauthorised changes found | [0]; each one investigated within [5 working days] | Change and configuration audit | Monthly |
| Incidents caused by change | Below [5%] of all incidents | Incident records | Monthly |
| Changes implemented within their approved window | [95%] | Change records | Monthly |
| Changes closed with CMDB updated within [2 working days] | [95%] | CMDB audit sample | Monthly |
| Reviews held for failed, backed-out and emergency changes | [100%] | Review records | Monthly |
| RFCs returned as incomplete | Below [10%] | Change records | Quarterly |
11. Records and evidence
| Record | Kept in | Owner | Retention |
|---|
| Request for change with assessment, approval and result | Ticketing tool | Change manager | [3 years] |
| CAB agenda and minutes | Document management system | Change manager | [3 years] |
| Emergency change decisions and reviews | Ticketing tool | Change manager | [3 years] |
| Change calendar and blackout list | Ticketing tool or calendar | Change manager | [1 year] |
| Standard change catalogue and its history | Document management system | Process owner | Life of the entry plus [3 years] |
| Monthly change report | Document management system | Change manager | [3 years] |
| Field | Entry |
|---|
| RFC number and date raised | |
| Requester and change owner | |
| Title and description of the change | |
| Reason and expected benefit | |
| Type (standard, normal, emergency) | |
| Services and configuration items affected | |
| Proposed date, window and duration | |
| Implementation steps and implementer | |
| Test evidence | |
| Backout plan, trigger and time to execute | |
| Risk: likelihood, impact, level | |
| Security and privacy assessment | |
| Communication plan | |
| Approval: name, role, decision, date, conditions | |
| Result and date implemented | |
| Review notes and CMDB updated (yes, no) | |
Annexure B: Change calendar
| Date and window | RFC number | Change title | Services affected | Type and risk | Owner | Status |
|---|
| [date, 22:00 to 02:00] | [CHG-0001] | [Database version upgrade] | [Customer platform] | [Normal, medium] | [Name] | [Approved] |
| [date range] | Blackout | [Month-end close] | [All finance services] | Not applicable | [Change manager] | [Published] |
| | | | | | |
| | | | | | |
Annexure C: Standard change catalogue entry
| Field | Entry |
|---|
| Name and reference | [Add user to a group, STD-001] |
| Trigger and who may request | |
| Systems and CIs affected | |
| Procedure steps | |
| Checks after the change | |
| Risk rating and reasons | |
| Approved by and date | |
| Review date | |
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 SM14 |
| | | | | |
| | | | | |
12. 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.
13. 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.
14. 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.1 | Change management |
| 8.2.6 | Configuration management |
| 8.1 | Operational planning and control |
| 8.5.3 | Release and deployment management |