Entities and Configuration Items

[chucka1369]

It is my understanding that entities can be related to a Configuration Item (CI), such as a Service, Application, individual Server, etc (basically anything in the CMDB)

In Nigels case the CI is the Pegasus Service Offering, and the Risk Statement is the same for each Risk Nigel wants to add.

This is the information provided by the Service Now expert in our organization:

I don’t believe this is the correct approach. I believe that each Risk record relates to a unique combination of Entity and Risk Statement and therefore we should not be providing a workaround, and instead we need to look at why there are in effect duplicate Risks.

The challenge is that Pegasus has multiple suppliers and there is a support risk statement related to 2 of the suppliers.  These are not duplicate risks but risks against the same CIs for different suppliers.  Each would need to be tracked separately.  

Also, should entities and CIs be identical?

What is the best way to make this happen?  We have quite a few cases such as this.

[eriksandber]

I would separate three concepts that are getting conflated here: the governed object, the risk taxonomy, and the actual risk exposure.

That distinction changes the answer.

1. An Entity and a CI should not be treated as conceptually identical

A CMDB CI represents an operational or architectural object: a Service Offering, Business Application, server, service, and so on.

An IRM Entity establishes the governance scope against which risks, controls, assessments, ownership, and evidence are managed.

ServiceNow can generate Entities from CMDB records through Entity Types and Entity Filters, so there may appropriately be a one-to-one relationship between an Entity and its underlying CI.

But I would not interpret that to mean:

every CI should become an Entity

or

the Entity framework should simply duplicate the CMDB.

The better question is:

At what level does the enterprise need to govern risk and control accountability?

If Pegasus Service Offering is the level at which risk ownership, controls, assessments, and reporting are governed, then Pegasus can remain the Entity even though many CIs and relationships sit underneath it.

2. A Risk Statement is the taxonomy. A Risk record is the exposure.

This is particularly important in your example.

The statement that every Risk must represent a unique Entity + Risk Statement combination reflects the older, more restrictive behavior, but it is not universally true in current IRM.

ServiceNow now supports multiple Risks associated with the same Entity and Risk Statement combination.

The key behavior is the Inherit from risk statement option.

When inheritance is used, the traditional one Risk per Entity + Risk Statement model applies.

When it is not used, the Risk Statement can act as the enterprise taxonomy while multiple distinct Risk records represent localized exposures underneath it.

That sounds much closer to the scenario you are describing.

In other words:

Risk Statement = standardized enterprise risk taxonomy

Entity = governance scope

Risk = the actual exposure requiring ownership, assessment, treatment, and monitoring

Two Risks do not become duplicates simply because they reference the same Entity and Risk Statement if the underlying exposures are materially different.

3. The supplier difference is the important architectural clue

If Pegasus depends on Supplier A and Supplier B, and each supplier creates a different support exposure, I would not create duplicate Pegasus Entities merely to force uniqueness into the risk model.

I would ask:

What is actually causing the exposure to differ?

If Supplier A and Supplier B have different likelihood, impact, contractual obligations, resilience characteristics, control effectiveness, treatment plans, or ownership, then there are legitimately two risk exposures even though:

the governed Service Offering is the same

and

the enterprise Risk Statement is the same.

That is exactly where separating taxonomy from exposure becomes important.

4. If Third-party Risk Management is in scope, model the supplier relationship there

I would also avoid forcing a third-party relationship into the CMDB or Entity model simply to distinguish the Risks.

ServiceNow TPRM provides a more appropriate construct for this.

A third party represents the supplier, while an engagement represents the business relationship through which that third party provides a service or product and creates potential exposure.

Current ServiceNow TPRM also allows Risks and Risk Statements to be associated with third parties and engagements.

So if the real distinction is:

Pegasus + Supplier A relationship

versus

Pegasus + Supplier B relationship

I would preserve Pegasus as the governed service context and use the third-party/engagement model to represent the supplier-specific exposure rather than manufacturing additional CMDB or Entity records.

That gives you a cleaner architecture:

CMDB/CSDM → what is being operated

IRM Entity → what is being governed

Risk Statement → how the exposure is classified

Risk → the specific exposure being assessed and treated

Third party / Engagement → which external relationship contributes to that exposure

5. I would design the model around the governance question, not record uniqueness

The key questions I would ask are:

What object are we governing?

What enterprise risk taxonomy applies?

What makes this exposure materially distinct?

Who owns the exposure?

What controls and evidence apply?

Does a third-party relationship create the differentiation?

If the answers show that Supplier A and Supplier B create independently assessable and treatable exposures against the same Pegasus Service Offering, I would expect separate Risk records rather than duplicate Entities or duplicate Risk Statements.

My architectural rule would be:

Do not change the governance boundary merely to manufacture uniqueness in the data model. Model the governance scope once, preserve the enterprise risk taxonomy, and create separate Risk records where the actual exposures are independently owned, assessed, treated, or monitored.

That keeps CMDB/CSDM, IRM, and TPRM doing different jobs while allowing the relationships between them to tell the complete risk story.