Change Management Policy
A change management policy establishes the governance framework controlling modifications to IT systems, infrastructure, and services. The policy defines how changes are categorised, who holds authority to approve them, what documentation each change requires, and how emergency situations alter standard requirements. Organisations implement this framework to balance operational agility against stability, ensuring that changes deliver intended benefits without causing unplanned disruption.
- Change
- Any addition, modification, or removal of IT infrastructure, systems, applications, configurations, or documentation that could affect service delivery.
- Change Advisory Board
- A cross-functional body that assesses, prioritises, and authorises changes based on risk, impact, and resource requirements.
- Change authority
- The individual or body empowered to approve a specific change based on its category, risk level, and organisational impact.
- Change window
- A scheduled period during which changes may be implemented, selected to minimise service disruption.
- Back-out plan
- A documented procedure to reverse a change and restore the previous state if implementation fails or causes unacceptable impact.
Policy scope
The change management policy governs all modifications to production IT environments from the moment a change is proposed until post-implementation review concludes. Coverage extends to hardware, software, network configurations, cloud resources, security controls, and documentation that describes system operation. A firmware update to network switches, a new software deployment, a firewall rule modification, and an update to disaster recovery procedures all constitute changes subject to this policy.
The policy applies regardless of change origin. Changes initiated by IT staff, requested by business functions, mandated by vendors, or required for security remediation follow identical governance principles adjusted for urgency and risk. Third-party service providers implementing changes on behalf of the organisation operate under contractual obligations to comply with this policy or demonstrate equivalent controls.
Certain modifications fall outside change management scope. Routine operational activities that do not alter system configuration, such as user password resets, standard access provisioning, and scheduled maintenance within pre-approved parameters, proceed through operational procedures without individual change approval. The boundary between routine operations and governed changes requires clear definition; when uncertainty exists, the activity should be treated as a change.
Change categories
Changes divide into three categories based on risk profile, complexity, and approval requirements. Category assignment occurs during initial change assessment and determines the governance pathway the change follows. Miscategorisation undermines the framework; conservative assessment protects service stability while appropriate categorisation prevents governance overhead from impeding routine improvements.
Standard changes
A standard change follows a pre-approved, documented procedure for a well-understood modification with established risk profile. Standard changes have been implemented successfully multiple times, produce predictable outcomes, and carry low risk when executed correctly. The approval for standard changes occurs once during procedure establishment rather than for each instance.
Qualification for standard change status requires documented procedure, demonstrated success through at least three prior implementations, established rollback capability, and assessment confirming low inherent risk. Examples include workstation software updates within approved versions, new user provisioning following established templates, and scheduled certificate renewals. A change that has never been implemented cannot qualify as standard regardless of apparent simplicity.
Standard changes proceed without individual Change Advisory Board review. The implementer verifies that the change matches standard change criteria, confirms current documentation validity, and logs the change for tracking purposes. Deviations from documented procedure convert the change to normal category requiring full assessment.
Normal changes
A normal change requires individual assessment and approval through the standard change process. Normal changes encompass the majority of modifications that do not qualify as standard and do not meet emergency criteria. Risk levels within normal changes range from minor configuration updates to substantial infrastructure modifications.
Normal changes proceed through request, assessment, approval, implementation, and review phases. The Change Advisory Board or delegated authority evaluates each change based on documented risk assessment, implementation plan, testing evidence, and back-out procedures. Approval authorises implementation within a specified change window.
Risk-based sub-categorisation within normal changes enables proportionate governance. Low-risk normal changes with limited scope and well-understood impact may receive delegated approval from IT management without full CAB review. High-risk normal changes affecting critical systems, multiple services, or large user populations require CAB assessment and formal approval. The organisation defines risk thresholds and delegation authorities appropriate to its scale and risk tolerance.
Emergency changes
An emergency change addresses an active incident, imminent security threat, or situation where delay would cause harm exceeding the risks of expedited implementation. Emergency changes bypass standard assessment and approval timelines while maintaining essential controls and documentation.
Emergency classification requires genuine urgency. The change must address a situation where standard timelines would result in unacceptable business impact, security exposure, or safety risk. Convenience, poor planning, and project deadline pressure do not constitute emergency justification. Misuse of emergency classification to circumvent governance undermines the framework and will be addressed through policy enforcement.
Emergency changes receive retrospective review within 5 business days of implementation. This review assesses whether emergency classification was appropriate, evaluates implementation effectiveness, identifies any process improvements, and ensures documentation completeness. Patterns of emergency changes affecting the same systems indicate underlying problems requiring root cause analysis.
Change approval authority
Approval authority varies by change category, risk level, and organisational impact. The approval matrix establishes clear accountability while enabling timely decision-making. Escalation paths ensure that changes exceeding delegated authority reach appropriate decision-makers.
| Change category | Risk level | Approval authority | Escalation |
|---|---|---|---|
| Standard | Pre-assessed low | Implementation team lead | IT Manager if criteria questioned |
| Normal | Low | IT Manager | Change Advisory Board |
| Normal | Medium | Change Advisory Board | IT Director |
| Normal | High | Change Advisory Board with IT Director endorsement | Executive leadership |
| Normal | Critical systems | Change Advisory Board with IT Director approval | Chief Operating Officer |
| Emergency | Any | IT Director or designated deputy | CEO if IT Director unavailable |
The Change Advisory Board convenes according to a defined schedule, with provisions for extraordinary sessions when urgent normal changes require assessment outside regular meetings. Quorum requirements ensure representative participation; decisions require attendance from IT operations, security, and affected business function representatives.
Approval authority delegation enables operational efficiency while maintaining accountability. IT Directors may delegate emergency approval authority to senior IT staff for periods of absence, with delegation documented and communicated to relevant parties. Delegated authority carries identical accountability to direct authority.
Risk assessment
Every normal and emergency change undergoes risk assessment to inform approval decisions and implementation planning. Risk assessment evaluates the likelihood of implementation failure, the impact of potential failure, and the consequences of not implementing the change. Assessment outputs guide approval decisions, implementation timing, and resource allocation.
Risk factors
Change risk derives from multiple factors that combine to determine overall risk level. Technical complexity indicates the difficulty of successful implementation and the expertise required. Scope measures how many systems, services, or users the change affects. Reversibility assesses how readily the change can be undone if problems emerge. Timing considers whether the change occurs during critical business periods or alongside other changes that could create compound risk.
Dependencies amplify risk. A change requiring coordinated modifications across multiple systems carries higher risk than an isolated change. Changes depending on external parties, such as vendor support or partner system modifications, introduce uncertainty outside organisational control. Risk assessment must identify dependencies and evaluate their reliability.
Risk classification
Risk classification provides consistent categorisation enabling appropriate governance. Classification combines impact and likelihood assessments into an overall risk level that determines approval requirements and implementation constraints.
| Impact if change fails | Likelihood of failure | Risk classification |
|---|---|---|
| Single non-critical system affected | Low with proven procedure | Low |
| Single critical system or multiple non-critical | Low to medium | Medium |
| Multiple critical systems or organisation-wide impact | Any | High |
| Any system | High due to complexity or novelty | Medium to High |
| Safety or regulatory implications | Any | High minimum |
Risk classification informs but does not solely determine approval requirements. Context matters; a medium-risk change during a critical operational period may warrant heightened scrutiny, while the same change during quiet periods proceeds normally.
Change windows
Change windows define periods during which implementations may occur. Window scheduling balances the need for changes against service availability requirements. Different system categories and change types operate within different window constraints.
Standard change windows
The organisation defines regular change windows aligned with operational patterns. For many organisations, weekday evenings between 18:00 and 22:00 local time and weekend mornings provide suitable windows with reduced user impact and staff availability for implementation and monitoring. Window definitions consider global operations; organisations with 24-hour operations or geographically distributed users require careful window analysis.
Critical systems may have more restrictive windows. Financial systems approaching month-end close, programme systems during reporting periods, and any system during peak operational periods warrant temporary window restrictions or prohibition. The change calendar maintains awareness of restricted periods.
Change freezes
Change freezes prohibit non-emergency changes during defined periods when stability takes absolute priority. Year-end financial close, major donor reporting deadlines, emergency response activations, and organisational events requiring maximum system availability justify change freezes. Freeze periods are declared in advance with sufficient notice for change scheduling adjustment.
Emergency changes may proceed during freeze periods through elevated approval requirements. The emergency approval authority must explicitly confirm that the change cannot wait until freeze conclusion and that the risk of inaction exceeds implementation risk during the sensitive period.
Documentation requirements
Change documentation creates accountability, enables review, and supports future reference. Documentation requirements scale with change risk and complexity; standard changes require minimal documentation while high-risk changes demand comprehensive records.
Change request content
Every normal and emergency change requires a change request record containing essential information for assessment and approval. Request completeness determines whether assessment can proceed; incomplete requests return to originators for remediation before review.
| Element | Standard change | Normal change | Emergency change |
|---|---|---|---|
| Change description | Reference to standard procedure | Full description of modification | Concise description |
| Justification | Not required | Business case or incident reference | Incident reference required |
| Risk assessment | Pre-assessed in procedure | Individual assessment required | Abbreviated assessment |
| Implementation plan | Reference to standard procedure | Detailed steps with timing | Outline plan, detail post-implementation |
| Testing evidence | Not required | Required for medium and high risk | Documented post-implementation |
| Back-out plan | Included in standard procedure | Required for all | Required, may be abbreviated |
| Approval record | Self-certified against criteria | CAB or delegated authority | Emergency authority |
| Implementation record | Completion confirmation | Detailed implementation log | Contemporaneous notes, formal record within 24 hours |
| Post-implementation review | Not required | Required for high risk | Required for all |
Record retention
Change records persist for reference, audit, and trend analysis. Active change records remain accessible in the change management system until implementation completes and review concludes. Completed change records transfer to archive storage with 7-year retention aligned with audit and regulatory requirements.
Documentation quality affects future reference value. Records should enable someone unfamiliar with the specific change to understand what was modified, why, and how. Technical accuracy matters; vague descriptions like “updated system configuration” provide no value compared to “modified firewall rule FW-2847 to permit inbound HTTPS from partner IP range 203.0.113.0/24”.
Roles and responsibilities
Change management involves multiple roles with distinct responsibilities. Clear role definition prevents gaps in accountability and duplication of effort. Individuals may hold multiple roles for different changes, but role separation requirements apply to high-risk changes.
The change requester initiates the change process by submitting a request with required documentation. The requester need not be the implementer; business function representatives may request changes that IT staff implement. Requesters bear responsibility for accurate description, valid justification, and appropriate prioritisation relative to other demands on implementation resources.
The change owner maintains accountability for the change from request through post-implementation review. For IT-initiated changes, the owner is typically the technical lead responsible for the affected system. For business-requested changes, ownership may rest with the requesting function or transfer to IT depending on organisational convention. Owners ensure documentation completeness, coordinate resources, and accept accountability for outcomes.
The change implementer executes the approved change according to the documented plan. Implementers must possess appropriate technical skills and access rights. For high-risk changes, implementers should be distinct from the individuals who developed and tested the change, providing independent verification of procedure clarity.
The Change Advisory Board assesses normal changes, provides approval or rejection decisions, and monitors change outcomes. CAB composition includes IT operations, IT security, and business function representation appropriate to the changes under review. A CAB chair facilitates meetings, manages agendas, and ensures decision documentation.
The change manager coordinates the overall change management process, maintains the change calendar, monitors compliance with policy requirements, and reports on change management effectiveness. In smaller organisations, change management responsibilities may integrate into broader IT management roles rather than constituting a dedicated position.
Emergency change provisions
Emergency changes operate under modified requirements that enable rapid response while maintaining essential controls. Emergency provisions exist for genuine emergencies; routine use indicates process failure or cultural problems requiring separate attention.
Emergency activation
Emergency change status activates when standard timelines would result in unacceptable harm. Specific activation criteria include active security incidents requiring immediate remediation, system failures causing current service disruption, safety risks requiring immediate mitigation, and regulatory deadlines that cannot be met through normal timelines due to unforeseen circumstances.
The individual proposing emergency classification contacts the emergency approval authority with a concise statement of the situation, proposed change, and consequences of delay. The authority confirms or denies emergency classification. Denied classifications revert to normal change process; if the requester believes denial is incorrect, escalation to the next authority level is permitted.
Emergency implementation
Approved emergency changes proceed immediately with abbreviated documentation. The implementer maintains contemporaneous notes during implementation sufficient to reconstruct actions taken. Formal documentation completes within 24 hours of implementation conclusion.
Emergency changes require back-out capability despite compressed timelines. The approval authority confirms back-out feasibility before authorising implementation. If back-out is impossible, this risk requires explicit acceptance as part of emergency approval.
Emergency review
All emergency changes undergo retrospective review within 5 business days. The review assesses emergency classification appropriateness, implementation effectiveness, any service impact during or after implementation, documentation completeness, and whether the situation suggests systematic improvements to prevent future emergencies.
Review findings feed into continuous improvement. Repeated emergency changes to specific systems suggest architectural weaknesses requiring investment. Patterns of emergency classification for predictable situations indicate planning or prioritisation failures. Emergency classification abuse indicates cultural or enforcement issues requiring management attention.
Compliance and exceptions
Policy compliance enables change management to fulfil its protective function. Compliance monitoring identifies deviations requiring correction and patterns suggesting systemic issues. Enforcement maintains framework integrity while recognising that rigid application can impede legitimate organisational needs.
Compliance monitoring
The change manager monitors compliance through change record review, implementation verification, and periodic audit. Metrics including change success rate, emergency change frequency, documentation completeness, and policy deviation rate provide visibility into change management health.
Unauthorized changes, those implemented without required approval, represent serious policy violations. Detection occurs through configuration monitoring, audit comparison, and incident investigation. Unauthorized change discovery triggers investigation into cause, assessment of impact, determination of whether the change should remain or be reversed, and appropriate accountability measures.
Policy exceptions
Exceptional circumstances occasionally justify deviation from standard requirements. Policy exceptions differ from emergency changes; emergencies address urgent situations through expedited process, while exceptions modify requirements themselves. Exception approval rests with IT Director or above, requires documented justification, applies to specific changes rather than ongoing deviation, and undergoes review to determine whether policy revision is warranted.
Exceptions do not authorise circumventing controls that exist for regulatory compliance, security protection, or safety purposes. Some policy elements are non-negotiable regardless of business pressure.