Hi Rohit,
Your proposed workflow is on the right track and covers the two outcomes that matter most: either the unauthorized CI change is accepted with proper approval and evidence, or it is rolled back with proper documentation.
The main recommendation is: use the unauthorized change record as the control/audit record, and use tasks or child remediation changes for the review and rollback activities.
ServiceNow already has an OOB unauthorized change concept. When an unplanned CI change is detected and there is no matching active Change, ServiceNow can create an Emergency type Change with the Unauthorized flag selected. The CI and changed field details are populated, and notifications can go to the Change assignment group and CI stakeholders.
The process I normally recommend is:
1. Unauthorized CI change is detected ( this will be the trigger)
2. ServiceNow creates or associates an Unauthorized Change record.
Keep this record as the audit record. It should capture:
- affected CI
- changed fields
- old value / new value, where available
- discovery/source system
- detected date/time
- person/team/source responsible, if known
- whether there was an approved Change covering it
3. Assign the Unauthorized Change to Change Management / CAG for triage.
The first step should be triage, not automatic approval. CAG should confirm:
- Is this a real change or a false positive?
- Is the CI in scope?
- Was there an approved Change that should have covered it?
- Is there service/customer/business impact?
- Does the change need rollback or can it be accepted after the fact?
4. Notify CI Owner / Managed by / Service Owner.
This is important. The approver group may own governance, but the CI owner usually knows whether the change is technically acceptable.
5. Create a review task.
A Change Task for CAG or Change Management is fine. I would use it as a Post Implementation Review / Unauthorized Change Review task.
The task should include:
- what changed
- when it changed
- who/what made the change
- impacted CI/service
- risk/impact assessment
- decision required: accept or rollback
6. Decision path: accepted after the fact
If the change is acceptable:
- document the justification
- capture CI owner/service owner approval
- capture Change Manager/CAG approval
- confirm no further remediation is required
- close the Unauthorized Change with a closure code such as Accepted / Approved after implementation
I would avoid making this look like a normal planned successful change. Keep the audit trail clear that it was unauthorized but accepted after review.
7. Decision path: rejected / rollback required
If rejected:
- create a rollback/remediation task
- assign it to the CI owning support group or implementation team
- include exact rollback instructions and expected previous CI state
- require evidence after rollback
- validate rollback through Discovery, audit history, or CI owner confirmation
I would usually assign rollback to the owning support group rather than only the individual who made the change. The person/team responsible can still be captured in work notes, assigned to, or a custom “implemented by” field.
8. Rollback itself should be controlled.
This is a key point. If the rollback is technically a change to production, it may also need to be handled through the same Unauthorized Change record or through a related Emergency/Normal remediation Change, depending on your organization’s policy.
I would not allow an uncontrolled rollback just because the original change was unauthorized.
9. Close only after validation.
Close the Unauthorized Change only when:
- accepted after review, or
- rollback/remediation is completed and validated, or
- false positive is confirmed and documented
10. Reporting/KPIs
Build reports for:
- unauthorized changes by CI class
- unauthorized changes by business service
- unauthorized changes by assignment group/source
- accepted vs rejected unauthorized changes
- rollback required count
- repeat CI offenders
- repeat team/source offenders
- time to review
- time to remediate
- unauthorized changes without owner response
A refined workflow would look like this:
1. Unauthorized CI change is detected.
2. Unauthorized Change is created or associated.
3. CAG triage task is created.
4. CI owner or service owner is notified.
5. CAG and CI owner review impact.
6. Decision is made to accept after the fact or require rollback.
7. If accepted, document the reason, capture approval, and close as accepted unauthorized change.
8. If rejected, create rollback or remediation task.
9. Validate rollback.
10. Notify CAG and CI owner.
11. Close the Unauthorized Change with evidence.
One thing I would tune carefully is scope. If you generate unauthorized changes for every minor CI attribute update, the process can become noisy very quickly. In practice, I would start with critical CI classes and meaningful attributes only, then expand once false positives are under control.
Also note that OOB unauthorized change detection has some conditions, such as checking whether the CI is in the allowed classes and whether it is already associated with an active Change. In some configurations, this is focused on CIs that are part of application services. So it is worth validating whether your detection source and CI scope match your expected coverage.
Overall, your process is good. I would just make sure the process clearly separates:
- Detection
- Triage
- Approval/acceptance after the fact
- Rollback/remediation
- Validation
- Audit closure
That separation makes the workflow much easier to defend in CAB, audit, and operational reviews.
References:
- Unauthorized change request:
https://www.servicenow.com/docs/r/it-service-management/change-management/unauthorized-change-reques...
- Unauthorized change properties:
https://www.servicenow.com/docs/r/it-service-management/change-management/unauthorized-change-proper...
Thank you,
Vikram Karety
Octigo Solutions INC
