A change management policy should help the organisation make security-impacting changes deliberately without turning every routine update into an unnecessary approval meeting. It defines how changes are classified, assessed, approved, tested, implemented, recorded, and reviewed.
Short answer: build the policy around change scope, security impact, ownership, approval, testing, separation of duties, rollback, emergency handling, and evidence. The policy should support the controls that protect availability, confidentiality, integrity, access, logging, and recovery.
Define what counts as a change
Include changes to:
- Production applications, infrastructure, cloud services, and configurations.
- Identity, access, authentication, and security policies.
- Logging, monitoring, alerting, and retention settings.
- Network rules, encryption, keys, secrets, and integrations.
- Backup, recovery, and continuity arrangements.
- Suppliers, data flows, and material processing arrangements.
Define the boundary between a change, routine operational task, incident action, emergency fix, and project delivery. If the policy treats every small correction identically, teams may bypass it.
Use risk-based change categories
| Change type | Expected governance |
|---|---|
| Standard, low-risk, repeatable | Pre-approved procedure, defined checks, recorded execution |
| Normal, security-impacting | Impact assessment, owner, approval, test, implementation record |
| High-risk or production-disruptive | Higher approval, communication, rollback, monitoring, and validation |
| Emergency | Rapid authorised decision, reason, minimum checks, follow-up review |
The categories should be understandable to the people who request and implement changes. Define examples and escalation rules.
Connect changes to security controls
For each material change, ask:
- Which assets, systems, data, identities, or suppliers are affected?
- Which security controls or policy requirements may change?
- Could logging, monitoring, access, encryption, backup, or recovery be weakened?
- What evidence needs to be captured before and after the change?
- Which owner approves the security impact?
The policy traceability model helps connect a change to the relevant control, policy, procedure, and evidence.
Require a useful change record
Capture:
- Request, reason, and business outcome.
- Scope, systems, environments, and dependencies.
- Security and service impact.
- Risk and affected control outcomes.
- Implementer and approver.
- Test plan and expected result.
- Implementation window and communication.
- Rollback or recovery plan.
- Evidence before and after.
- Validation result and follow-up review.
The record should help someone understand what changed, why it changed, who approved it, and whether the security outcome remained acceptable.
Include testing and rollback
Testing should match the risk. A configuration change may need a peer review and test environment. A production authentication change may need service-owner testing, monitoring, and a prepared rollback.
Define when a change cannot proceed without:
- A tested rollback or recovery path.
- A maintenance window.
- A communication plan.
- A second reviewer or approver.
- A backup or export of the current state.
- Post-change monitoring and validation.
Rollback is not always possible. If the change is hard to reverse, require stronger evidence and explicit approval.
Handle emergency changes without removing governance
Emergency work may need to move quickly, but it should not become invisible. The policy should define:
- Who can authorise the emergency change.
- What minimum information and checks are required.
- How the change is recorded during the incident.
- What evidence is preserved.
- When the change is reviewed after the emergency.
- How temporary changes are removed or converted into approved permanent changes.
Link emergency changes to the incident record when they are part of containment or recovery. The incident action review guidance gives a similar approval and validation model for AI-assisted actions.
Monitor exceptions and failed changes
Review failed, unauthorised, emergency, and repeatedly delayed changes. Patterns may reveal:
- Inadequate testing.
- Unclear ownership.
- A change category that does not fit the workflow.
- Security controls that are fragile or poorly understood.
- Repeated policy exceptions.
- Documentation that no longer matches the system.
Turn material findings into controlled improvement actions rather than simply adding more approval steps.
Where Framework Pro fits
Framework Pro can help draft a tailored change management policy from business context and selected controls. The organisation still defines its change categories, tools, owners, approval authority, testing, implementation, evidence, and review. A policy draft does not prove that change records are complete or that controls were preserved.
Frequently asked questions
What should a change management policy cover?
It should cover change scope, categories, security impact, ownership, approval, testing, implementation, rollback, emergency changes, evidence, validation, and post-change review.
Does every change need security approval?
No. Use risk-based categories. Routine standard changes can use pre-approved procedures, while security-impacting or high-risk changes need deeper review.
How do changes support security controls?
The process identifies affected control outcomes, requires appropriate tests and approvals, preserves evidence, and validates that the intended security state remains in place after implementation.
How should emergency changes be handled?
Allow rapid authorised action with minimum checks, preserve the record, and require a follow-up review that confirms the change, risk, evidence, and cleanup.
What evidence should a change produce?
The request, impact assessment, approval, test result, implementation record, before-and-after state where relevant, rollback plan, monitoring, and validation result.