Unauthorized Change Detection Strategies

MZC · ‎01-04-2022

Implementing Unauthorized Change Detection activity with ServiceNow. Does ServiceNow track, document and/or publish any customer experience or strategy white papers, from customer real-world implementation of this activity? What are key elements in being able to implement this activity from a technical perspective using Rome version of ServiceNow and with ServiceNow Discovery, Service Mapping functionality in place, along with an active Change Module? What are the key elements which need to be aligned for an initial implementation of the function.

Daniel Borkowi1 · ‎01-06-2022

Hi,

the OOTB implementation is a good start, but have lot of gaps. It checks only CI which are assigned to a Application Service.

Gaps:

It only works with Service Mapping.
New discovered (inserted) CIs are not detected as unauthorized Change, because naturally they are not attached to Application Services.
As Ed mentioned, it's only on class level. You can not decide which fields should be observed or not, e.g. change of free space of disks is not relevant. It seems there is a learning algorithm in the backend to remove such noises, but I guess this will take long time, to have this stable and only real unauthorized changes will be detected.
Also removed change relevant relationships will not be detected as unauthorized Change.

What we did in the past is, that we built such logic on our own. So we created some Configuration class where you configure which classes and fields and which relationships are change relevant. In a Business Rule which runs on every update of CI by discovery, we checked if a matching class and field is changed the Change Requests will be checked. If there is no authorized Change, we flagged these CIs or created a unauthorized change (dependend on Customer requirements). Also we ensured, that if everything is done on the right way, a CI of a change relevant class will never be created by discovery, because the CI sleeve was created by Change Request Workflow before discovery can detect it. So every new CIs in a change relevant Class without such a Change Request will be detected as unauthorized Change.

I hope these gaps will be closed in future, so that OOTB Unauthorized Change Detection needs no additional custom implementation.

Greets,

Daniel

View solution in original post

alhalljr · ‎06-03-2022

I was looking into this opportunity but I am challenged with best way to log a unauthorized change manually. My challenge is the process and supporting event and config abilities is not currently in place, but I am informed of unauthorized changes but do not see a method to mark a change as such (I am guessing it is a custom field, but would rather use the current table discussed in the automated method). Has anyone dealt with this?

stevenswink · ‎03-27-2025

I would need to dig into the pedigree of the field, but certainly as of the Washington DC release there is an OOB column called "unauthorized" on the change_request table. On our instances it was created in 2019, so it's been around for awhile.
(you can probably file this one in the "WUTB" folder (Water Under the Bridge).

Graham K · ‎01-26-2023

I would be keen to know if anyone has found a satisfactory way of combining Unauthorized Change Detection with Dynamic CI Groups. As we know, an Application Service built on CMDB Group does not created a Mapped Application Service which I believe (TBC) is why Unauthorized Change Detection does not get triggered for changes to the CIs in the CMDB Group.