Unauthorized changes on CIs: who decides retain vs. rollback, and who clears the flag?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 hours ago
Hi all,
We're designing our process for handling unauthorized changes detected on CIs, and I'd like the Community's view on how responsibilities should be split. I'm not asking how to clear the Unauthorized checkbox. I'm asking who should own each decision, and in what order.
(Also posted in the ITSM and CMDB forums. Posting here too, since detecting unauthorized changes on CIs often involves ITOM and Discovery data.)
Our setup
- When an unauthorized change is detected on a CI, a change record is created with Unauthorized = true (Emergency type).
- We populate the Support Group field on cmdb_ci. Our intention is for that CI's support group (mostly technical/operations staff) to investigate and decide whether the change should be retained or rolled back.
- These staff don't normally hold the change_manager role.
- I recently learned that a user with change_manager can convert an unauthorized change into an emergency change model.
Diagram 1 – Original flow
The Support Group received a task that followed our existing Emergency CHG approval workflow, then approved (keep) or rejected (roll back).
Diagram 1 – Original flow
Diagram 2 – Current flow
We replaced the approval task with a direct "accept / retain or roll back" decision by the Support Group. Rollback tasks go to the person's own Support Group (if a person caused it) or to the Change Implementer's Support Group (if automation caused it), with a fallback Unauthorized Change Support Group. Retained changes close the CHG, and rolled-back changes cancel it.
Diagram 2 – Current flow
Diagram 3 – Proposed revision
The main change is that accepting a change that has already been made and clearing its Unauthorized flag become two separate decisions. The yellow boxes are the points I'm unsure about.
Diagram 3 – Proposed revision (yellow = open questions)
My questions
- Should the support group's decision be only a technical recommendation, with a separate Change Manager giving formal approval and handling any reclassification?
- When should an unauthorized change be converted to an emergency change? Is deciding to keep it enough reason to convert, or should it stay recorded as unauthorized even after it's accepted?
- Would you grant change_manager to technical support group members for this, or keep that role separate? What permission or governance issues would granting it create?
- If the roles stay separate, where should the handoff to Change Management happen? Who owns the change record, and who owns the investigation and rollback tasks?
- For rollback, should we use the original record or a linked remediation change? And what closure outcome should replace the automatic "Cancel CHG" in our flow?
- How do you keep unauthorized-change reporting accurate after a record is reclassified?
Example: the support group investigates and says, "This change is technically acceptable; keep it." What should happen next? Who approves it, who changes any flags or the model, and which state should the record move to?
I'd appreciate a recommended sequence of steps and owners for both the retain path and the rollback path, or a pointer to how you've handled this in your own instance.
Thanks,
Rohit
