Changes

A planned change has a summary, affected service, risk level, scheduled start and end, and rollback plan. The Change Manager prepares those details before review. The change advisory reviewer records a decision, date and reason against the change. A team can then tell whether the work is still a draft, in review, approved, implementing, verified, rolled back or rejected.

The change workflow routes a raised change into review and records the advisory decision row. Implementation has its own evidence: the deployment record holds environment, version, deployment time and outcome. Rollback checks can capture expected and actual results at a checkpoint. These records let the team discuss the decision and its execution separately.

• Preparation. State the service affected, risk, work window and rollback plan before seeking a decision.
• Review. Record the advisory decision and reason on the change; the reviewer is named on that row.
• Execution. Track implementation and deployment outcome, including a rolled-back or failed result when needed.

Agree which changes require a CAB Reviewer, how the risk values are used, and who can approve work within a scheduled window. A low risk adjustment and a high risk service interruption should not inherit the same assumptions. The rollback plan needs enough detail for the implementation team to act if the deployment fails. Decide who checks the service after the work and where the actual result is recorded.

The schedule shows approved and implementing changes with their start and end. Review overlapping windows for the same service before authorizing the work. A decision of defer calls for another review date and a reason; it is not an approval to implement.

An incident investigation identifies a change needed on a shared service. The Change Manager writes a summary, selects the risk level, chooses a start and end time, and writes the rollback plan. The change moves into review. The CAB Reviewer examines the service impact and records an approve, reject or defer decision with a reason. Check that the implementing team can see the decision before work begins.

For an approved change, the Change Manager records a pending deployment as implementation starts. The deployment outcome is updated after the release and the relevant rollback checks are filled in. If the work is rolled back, keep that outcome visible. Verification should use the service’s actual observed condition, not a successful deployment label alone.

• Changes In Review — Proposed work waiting for a change decision.
• Change Schedule — Approved and implementing work with start and end times.
• Pending CAB Decisions — Advisory rows that still need a reviewer decision.

Follow change control from preparation to verification, and use incident response to see why the change was requested.