Trick 1: "The owner of a change is the IT staff member who implements it." True or False?
FALSE — and this is a classic exam trick.
The owner is the department or person who needs the change — not the person who implements it. Example: if Shipping needs a software upgrade, Shipping owns the process. IT is the implementer.
The owner manages the process, receives updates, and performs acceptance testing. They almost never do the technical work. The exam will try to conflate "doing the change" with "owning the change."
The owner is the department or person who needs the change — not the person who implements it. Example: if Shipping needs a software upgrade, Shipping owns the process. IT is the implementer.
The owner manages the process, receives updates, and performs acceptance testing. They almost never do the technical work. The exam will try to conflate "doing the change" with "owning the change."
Trick 2: "Impact analysis only evaluates the risks OF making a change." True or False?
FALSE — impact analysis must evaluate BOTH directions.
A complete impact analysis evaluates:
1. Risks of making the change — fix might fail, might break something, might corrupt data
2. Risks of NOT making the change — security vulnerability remains unpatched, unsupported software, application instability
The exam may present a scenario where NOT changing is actually the higher risk. A CCB must weigh both sides.
A complete impact analysis evaluates:
1. Risks of making the change — fix might fail, might break something, might corrupt data
2. Risks of NOT making the change — security vulnerability remains unpatched, unsupported software, application instability
The exam may present a scenario where NOT changing is actually the higher risk. A CCB must weigh both sides.
Trick 3: A company is applying its monthly routine OS patches. Do they still need a change management process?
Yes — but the process can be streamlined.
Routine, pre-approved changes often fall under a "standard change" category. These still require documentation and notification, but may not need full CCB review each time.
The key principle is: no change should be made without some form of process. "It's routine" is never a reason to skip documentation. The exam will test whether you know that even routine changes need a process — just possibly a lighter one.
Routine, pre-approved changes often fall under a "standard change" category. These still require documentation and notification, but may not need full CCB review each time.
The key principle is: no change should be made without some form of process. "It's routine" is never a reason to skip documentation. The exam will test whether you know that even routine changes need a process — just possibly a lighter one.
Trick 4: "A sandbox environment guarantees there will be no surprises when a change is deployed to production." True or False?
FALSE — sandboxes reduce risk but cannot eliminate all surprises.
Prof. Messer explicitly notes: "A sandbox can't consider every possibility." Sandboxes typically can't replicate:
- Full production load (14 simultaneous printers vs. 1 in testing)
- All real-world data edge cases
- Timing issues under production traffic
- Real user behavior
The sandbox significantly reduces risk — but the backout plan is still essential because production will always have variables the sandbox didn't have.
Prof. Messer explicitly notes: "A sandbox can't consider every possibility." Sandboxes typically can't replicate:
- Full production load (14 simultaneous printers vs. 1 in testing)
- All real-world data edge cases
- Timing issues under production traffic
- Real user behavior
The sandbox significantly reduces risk — but the backout plan is still essential because production will always have variables the sandbox didn't have.
Trick 5: The maintenance window should always be during business hours for maximum visibility and coordination. True or False?
FALSE — business hours are usually the WORST time.
During business hours, all users are on the system. Any downtime has maximum impact. Most changes should happen overnight, on weekends, or during off-peak hours.
The exception: if the change requires user testing that can only happen with users present (e.g., a UI change that needs real users to validate), then a business-hours window with a clearly communicated outage notice may be appropriate. But as a rule, overnight is preferred.
During business hours, all users are on the system. Any downtime has maximum impact. Most changes should happen overnight, on weekends, or during off-peak hours.
The exception: if the change requires user testing that can only happen with users present (e.g., a UI change that needs real users to validate), then a business-hours window with a clearly communicated outage notice may be appropriate. But as a rule, overnight is preferred.
Performance Task: You are the IT Manager for a hospital. A critical medical records system has a vendor-released security patch that addresses a remotely exploitable vulnerability. However, the patch has not been tested in your environment, the maintenance window isn't for 12 days, and applying the patch requires a 2-hour outage. Design your change management response.
Model Answer:
1. Invoke emergency change procedure. A remotely exploitable vulnerability in a medical records system is a critical risk. Most change management frameworks include an emergency change track for exactly this situation. You don't wait 12 days for a critical security patch.
2. Accelerated impact analysis. Document the risk of NOT patching (remote exploit, patient data breach, HIPAA violation, potential ransomware entry point) vs. the risk of patching (2-hour outage, untested patch). The risk of NOT patching almost certainly outweighs the outage.
3. Rapid sandbox test. Request emergency lab time. Test the patch in a cloned environment. Look specifically for integration issues with clinical systems. 24-48 hours of testing beats zero.
4. Prepare a solid backout plan. Full database backup before patching. Documented rollback procedure. Vendor support on standby during the window.
5. Schedule emergency maintenance window. Coordinate with hospital operations: 2 AM on a weeknight when patient census is lowest. Notify all stakeholders — clinical staff, pharmacy, lab, admissions — 24 hours in advance.
6. Document everything. Emergency changes are the most audit-prone. Document the risk justification, who approved, who implemented, what was tested, and what the outcome was.
1. Invoke emergency change procedure. A remotely exploitable vulnerability in a medical records system is a critical risk. Most change management frameworks include an emergency change track for exactly this situation. You don't wait 12 days for a critical security patch.
2. Accelerated impact analysis. Document the risk of NOT patching (remote exploit, patient data breach, HIPAA violation, potential ransomware entry point) vs. the risk of patching (2-hour outage, untested patch). The risk of NOT patching almost certainly outweighs the outage.
3. Rapid sandbox test. Request emergency lab time. Test the patch in a cloned environment. Look specifically for integration issues with clinical systems. 24-48 hours of testing beats zero.
4. Prepare a solid backout plan. Full database backup before patching. Documented rollback procedure. Vendor support on standby during the window.
5. Schedule emergency maintenance window. Coordinate with hospital operations: 2 AM on a weeknight when patient census is lowest. Notify all stakeholders — clinical staff, pharmacy, lab, admissions — 24 hours in advance.
6. Document everything. Emergency changes are the most audit-prone. Document the risk justification, who approved, who implemented, what was tested, and what the outcome was.