Change Management Rollback: What to Do After a Failed Change Implementation
During a change management process, the Change Advisory Board (CAB) has approved a change to update a critical database server. After implementation, a rollback is necessary due to unforeseen performance issues. What should the change manager do next?
Quick Answer
Executing the rollback plan and then scheduling a post-implementation review is the correct response because the rollback plan was already built into the original change request and approved by the CAB as part of that same package; it's a pre-authorized contingency, not a new action that requires fresh approval before it can be used. When unforeseen performance issues appear after implementation, the priority is restoring service stability as quickly as possible, and executing a plan that's already been reviewed and approved is the fastest safe path to that outcome, since re-submitting a new change request for the rollback itself would introduce delay while the problem is actively affecting the system. Once stability is restored, scheduling a post-implementation review captures what went wrong, why the pre-implementation testing didn't catch the issue, and what should change about the process going forward, closing the loop and feeding lessons learned back into future change planning, which is a core part of ITIL-aligned change management. Treating rollback as something that needs a brand-new approval cycle would misunderstand how contingency planning works within change management: the contingency is decided in advance precisely so it can be executed without delay when needed. When a question describes a failed change with a pre-approved rollback plan, look for the answer that executes that plan immediately and follows up with a review, rather than one that seeks new approval first.
⚠ Common exam trap
The trap here is that candidates mistakenly think any rollback requires a new change request, but the rollback plan is already part of the approved change, so immediate execution is permitted without further CAB approval.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Execute the rollback plan and schedule a post-implementation review
The change was already approved by the CAB, and the rollback plan is a pre-approved contingency within the original change request. Executing the rollback immediately restores service stability, and scheduling a post-implementation review (PIR) captures lessons learned and ensures compliance with the change management policy. This aligns with ITIL best practices, where rollback is part of the implementation plan and does not require a new change request.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Execute the rollback plan and schedule a post-implementation review
Why this is correct
The rollback plan is the pre-approved reversal path, so executing it restores the database to its last known-good state and limits disruption. Scheduling a post-implementation review then captures why performance issues arose, feeding lessons back into future change assessments.
- ✗
Leave the server in its current state and escalate to the CAB for a decision
Why it's wrong here
Leaving the server degraded prolongs the outage and breaches the rollback plan, which already authorises restoring the previous state. Escalation suits situations where no pre-approved backout exists or the failure's cause is unknown, so the CAB must decide whether to roll back, fix forward, or accept the risk.
- ✗
Patch the server with the latest updates to resolve the performance issue
Why it's wrong here
Patching introduces further unapproved changes to a production system already exhibiting performance problems, compounding risk instead of restoring the known-good state. Patching is the right action under a separate, approved change request when the goal is remediating a specific vulnerability or defect, not reversing a failed implementation.
- ✗
Submit a new change request for the rollback and await CAB approval
Why it's wrong here
The approved change already includes a documented backout plan, so requiring fresh CAB approval to invoke it delays restoration of service while the database remains impaired. A new change request is warranted when the rollback itself falls outside the original approval, such as restoring from backup beyond the agreed window.
Go deeper
Related to this question
About these practice questions
This SSCP question is part of Courseiva's 971-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on SSCP
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. After a patch is deployed to a critical server, the system becomes unstable. The change management plan includes a rollback procedure. What should be done FIRST?
hard- A.Create a new change request for the rollback
- B.Conduct a post-implementation review
- ✓ C.Execute the rollback procedure
- D.Notify the Change Advisory Board
Why C: When a patch deployment causes system instability, the immediate priority is to restore service stability by executing the pre-approved rollback procedure. The change management plan already includes this procedure, so no new approvals are needed; acting quickly minimizes downtime and risk.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SSCP practice question is part of Courseiva's free ISC2 certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SSCP exam.