How to change an entity filter in a safe manner

[rogerburns]

We have been using GRC (IRM) to perform risk assessments for about a year.  We have been maturing our capability and adding new entity types.  However, with existing entity types, we have had a problem where we made a change to the entity filter and it cascaded changes to active entities, and retired the controls and related records.

We would like to move from one entity type to start using another with a similar, but different filter, and no longer use the initial one.  What would be the recommendation on how to proceed?  We would continue to attest entities with a different set of control objectives.

Initially we thought that we could remove the entity filters from the entity type, but that may retire the entities again and we do not want to go through the pain of recovery again.

Thanks!

[Mehernosh Amrol]

Hi Roger,

As long as the Entity Filter is pulling from the same table, the Entity will remain the same.  An Entity can belong to Multiple Entity Types.  For Example, if I create Entity Types of USA Offices and pull from cmn_locations using the filter on Country is USA, I can create another Entity Type of California Offices and say State is California. Los Angeles will be in BOTH.  If you change the filter on USA offices and say the state is not California, Los Angeles will no longer be an Entity under USA Offices but will remain in California Offices and in the All Entities. Any Controls related to the USA Offices Entity type will also retire unless they also belong to California Entity Types.

If you have a PDI or a lower environment, try it out there :).

[Sebastien Fix · Accepted solution]

Keeping in mind that an Entity is just a copy of another record SysId, and that two Entities with same name can refer to two different SysIds:

As long as the original record SysId is the same, ServiceNow does not create duplicated Controls/Risks if an Entity is found on multiple Entity Types (Via Entity Filters looking up Records). There can therefore be multiple Entity<->Control Objectives relationships but still only one Control.

As long as there is at least one Entity<->CO relationship existing, the Control will not be affected if the Entity goes out of Entity Types due to Entity Filter changes. 

For your case:

1. create the new Entity Type ("ABC v2") based on the new Entity Filter. Make sure all the Entities are part of the Entity Type (it can be take few minutes for the job to complete). 

2. "Retire" the old Entity Type ("ABC") (make it Inactive rather than Delete is my advice)

- If "ABC v2" has more Entities than "ABC", more controls will exists

- If "ABC v2" has fewer Entities than "ABC", the controls related to the "fewer" entities will be set to Retire

- If "ABC v2" and "ABC" have the same number of Entities, no changes

On that same note: I recommend you to change a line in the "Cascade Changes" Business Rules (one for Risk and one for Controls). If any change occurs to a Risk Statement or Control Objective, all the Risks/Controls are returned to Draft. This makes sense theoritically (if the definition of a Control change, then the control test results may no longer be valid) but is overkill in most real-life scenarios where you may want to fix a typo...

[rogerburns]

Thanks for the help.  We had a situation where thousands of controls were set to Draft, and we had to remark out this line to avoid this in the future.  It required a fix script that pulled previous values from the audit logs and fix all the downstream controls, attestations, etc.  I can understand why you might want to move a control to Draft if you had a few of them to force a review, but that doesn't scale well.