Best Practices for Entity Types - Particularly when retiring and reactivating Entities

[ChristopherS131]

I'm looking for guidance and best practices for managing Entity Types, particularly when entities are retired and later reactivated.

My organization uses Entity Types that can have dozens of associated controls/risks (sometimes 40+). Over time, hundreds of entities have been created in advance of being assessed. Because these unassessed entities remain at their inherent risk scores, they are skewing our overall risk heat map and reporting.

The proposed solution is to retire and inactivate unassessed entities and reactivate them when they are ready to be assessed. My concern is how this impacts Entity Type inheritance and synchronization, particularly since my organization has made changes to Entity Types in the past by both adding and removing controls objectives/risk statements from them.

What I've observed:

• Changes made to an Entity Type are not reflected in inactive entities. When an entity is reactivated, it does not appear to automatically pick up changes made to its Entity Type while inactive.
• Removing and re-adding the Entity Type will add any controls/risks the entity is missing
• Conversely, removing and re-adding the Entity Type fails to consistently retire controls/risks that were removed from the Entity Type:
  • Sometimes a control is retired but the corresponding risk remains active.
  • Sometimes a risk is retired but the corresponding control remains active.
  • In both cases above, neither the controls nor the risks were added directly to the entity; the controls were originally inherited from the Entity Type.
• Overall, the results seem inconsistent and difficult to predict.

I've been unable to find clear ServiceNow documentation on recommended practices for Entity Type lifecycle management. Specifically, I'm trying to understand:

1. Is it considered a best practice to retire and later reactivate entities, or is there a better approach for entities that won't be assessed for some time?
2. Are Entity Types intended to remain relatively static once entities have been created from them, or are ongoing modifications expected?
3. Is there a recommended process to ensure reactivated entities properly reflect changes made to their Entity Type while inactive?
4. Are there practical limits or recommendations regarding the number of controls/risk statements associated with a single Entity Type?

I'd appreciate any lessons learned, real-world experience, or links to documentation that would assist with my question.

[Matthias Ferstl]

Hi.

TL,DR: You seem to use risks and entites not in a way they are meant to. If you have unassessed entites you shouldnt have it as an entity at all.

Seems like you use retirement in a way it was never meant for.

Retirement is (e.g.) if you HAD a server, that is not used anymore or a building that was sold. But still you want to know if there were GRC processes int the last years (in the time you used it) in an audit.

Its not meant for "i dont want to assess it now, but maybe later". Same goes for controls and risks.

A good example for a retired entity that "comes back": A device is inactive for over a year for some reason. But after 2 years you decide to reactivate the device. You dont want 2 different entites (one before retirement, one after). So the system checks if there already is an entity and reactivates the "old" one.

• Changes made to an Entity Type are not reflected in inactive entities. When an entity is reactivated, it does not appear to automatically pick up changes made to its Entity Type while inactive.

I dont know what changes you mean, but changes regarding adding or removing controls only apply to active (or reactivated) entites. Could take up to an hour until changes are made.

• Removing and re-adding the Entity Type will add any controls/risks the entity is missing

See above. If the entity is not retired, it could take up to an hr.

• Conversely, removing and re-adding the Entity Type fails to consistently retire controls/risks that were removed from the Entity Type:

Check if the control is also added by other entity types. But you should (seriously) stop to use Entity Types as a "trigger".

• Sometimes a control is retired but the corresponding risk remains active.
• Sometimes a risk is retired but the corresponding control remains active.
• In both cases above, neither the controls nor the risks were added directly to the entity; the controls were originally inherited from the Entity Type.

Depending on the Entity Type and so on, you should check if Risks and Controls are only contributed by one Entity Type or others. Its nor the link between controls and risks, that define if it has to retire, but the link between Risk Statement/ Control Objective and Entity Type.

I've been unable to find clear ServiceNow documentation on recommended practices for Entity Type lifecycle management. Specifically, I'm trying to understand:

They are not meant to have an "lifecycle". Either they are active (and crete entites and their controls or risks) or they arent. But they are not meant as triggers for assessments.

• Is it considered a best practice to retire and later reactivate entities, or is there a better approach for entities that won't be assessed for some time?

No and no. If you need to retire entites to get a better risk score, you didn't get "risk".
Either the entity exists (and keeps existing) or it doesnt. If you assess a building only every 2 years, the building and the risks still exist between the assessments.
But if you need to: Deactivate the Type, wait, check if the entity retires. Wait more and check if controls and risks are retired.

Keep in mind that changes are cascading. If you deactivate a type you might deactivate hundrets of entites and thousands of risks / controls, and therefore trigger a lot of recalculations (compliance- / risk score and so on). This is why some things are done by scheduled jobs, events and a lot of other asynch processes. Better you check one day after you made changes.

• Are Entity Types intended to remain relatively static once entities have been created from them, or are ongoing modifications expected?

You can modify them, but they are not an object that is meant to be dynamic. A change can be: You noticed that even EOL CIs are considered as active entity, so you refine the filter to avoid 500 EOL Servers get checked for "Configuration governance". Or you add a new risk statement or control objective. But this is more a kind of PDCA-Change instead of a "today i want to assess Control XY, so I add it as control objective and remove it afterwards".

• Is there a recommended process to ensure reactivated entities properly reflect changes made to their Entity Type while inactive?

Patience

• Are there practical limits or recommendations regarding the number of controls/risk statements associated with a single Entity Type?

Not as far as i know, but depending on the number of entites that are creted by the filter you should keep in mind, that 200 Controls and 10 Risks on an Entity Type will create 210 objects that want to be assessed. Now let the filter apply to 500 servers.

"Good Luck" 😉

- Its better to rollout entites / controls / risks one after another to avoid "stockpiling" unassessed entites IF you want to assess them. instead of 20k assessments at oncce, try to roll out entites/controls/risks in "phases".

- If you have entites that never will be assessed, refine your filter.

- If you have to many entites, check the targets of assessments. (e.g. Instead of assessing every client, assess their configuration once (if they use the same config)).

Kind regards

[Mathew Hillyard]

Echoing the reply by @Matthias Ferstl, you don't create Entities (well, you can manually create them and there are sometimes circumstances where you may have to, but it's not the general everyday practice we are talking about). You create Entity types and define the Entity filter that returns the records you wish to assess.

If you have unused Entities, your Entity filters are not specific enough. This may be a quick fix or may be impossible to fix because your foundational supporting data isn't good/complete enough. Have a read of the Docs site page on Entity scoping for more information: https://www.servicenow.com/docs/r/governance-risk-compliance/grc-common-functions/c_Scoping.html

By all means retire Entities you no longer need, but it may be quicker and easier in the long run to redefine your entity filters - which are actually dynamic, and each time a new record is created that meets an Entity filter, an Entity will be created as well as Controls/Risks from any Control Objectives/Risk Statements associated with that Entity type.

As also mentioned a scheduled job controls Entity sync and this may take up to an hour to run. The only thing I know of that can speed things up is when you update the filter condition on an Entity filter and save - a related link "Update entities from filters" appears, which prompts the re-sync. But either way, the advice above is sound; for lots of changes give the GRC engine time to complete its work. If you are still not seeing the sync happen, perhaps your instance has been customised.

I hope this helps!
Mat