Change Management Policy
Purpose
Most outages and security failures are introduced by a change, not by an attacker. This policy governs how changes are made to applications, infrastructure, configurations, integrations, and processes where they could affect security, availability, integrity, or a commitment we have made to a customer.
Change types
Changes fall into four categories:
- Standard — pre-approved, low-risk, and repeatable, following an established procedure.
- Normal — assessed, reviewed, and approved before deployment.
- Emergency — implemented quickly to contain an active risk, such as a security fix or incident mitigation, with review carried out after the fact.
- Rollback — reversing a previous change that has caused a problem or failed validation.
Required change information
Every material change is documented with:
- Purpose
- Scope
- Affected systems
- Risk assessment
- Test plan
- Rollback plan
- Owner
- Reviewer or approver
- Deployment window
- Validation steps
Review and approval
Changes are reviewed by the appropriate technical and business owners, with the depth of review scaled to the risk. The higher the risk, the more senior the approval required and the wider the group that must be told in advance, including the customer, where the change affects their systems or their users.
Deployment validation
A change is not finished when it is deployed. The owner confirms the system behaves as expected, watches errors and logs for the period following release, verifies that security controls are still in force, and records the evidence that closes the change.
Emergency changes
Emergency changes may bypass the normal sequence in order to reduce an active risk quickly. They cannot bypass the record. Each one is documented, reviewed, and brought back into the standard process once the immediate risk has passed.
Evidence maintained
- Change ticket
- Approval record
- Test evidence
- Deployment logs
- Rollback plan
- Validation result
- Post-change review