Update Entity/Control Owners based on "Source" data updates

[jsuttonCDW]

Hi All,

I am running across a deadend for answering a question regarding the updating/maintenance of Entity owners (thus Control and Risk Owners) when the Entity Source is updated.

Use Case:

There is a Configuration Management process in place to maintain correctness of information, one attribute which is the Owned By field. We have targeted this field for our Owned By on the Entity Type Filter for that Entity Type, thus the Entities are created with that CIs Owned By. While maintaining the CIs and updating these attributes, it does not seem to trigger an update to applicable Entities, which then does not update the associated Controls and Risks. 

The trouble I am having with this then is what is best practice recommendations for maintaining this data, and what then is the benefit of identifying an Owned By field on a related record if this just imposes maintenance for the Risk team. 

Does anyone have any suggestions as to why this is design in such a way and how to create an efficiency of updating associate Entities > Controls/Risks?

[Phil Swann · Accepted solution]

Because you can always override the ownership, it would not be right for the source record to override your manual decision.

It can be frustrating but there are ways to configure this specifically to how you want.

e.g. some kind of sync BR/ flow designer

or what I have built in the past is UI actions to go and get the new owner, and then go and cascade the owner down to the items in state of Draft for example..

also need to consider the behaviour of the Respondents field; this relies on you making the change in the form.. and also the owner and the respondents can often be different. 

But also, remember that an entity can be scoped by more than one type filter; so the ownership could be defined differently for different scopes; and this presents a different challenge that is not easily solved.

As it is the filter that defines the owner at point of creation, and not thereafter - this is something you really need to decide, and I do not think anything that SN would provide in baseline config is ever going to fit everyone so they have left this part of the system open for you to decide... 

But I would say be very clear on rules if you are planning to automate this. Be very clear on how these different interactions actually work because it is likely to present some overlapping/conflicting behaviours when you scale up. 

[Jan Spurlin]

@Phil Swann - his answer is correct, in the baseline it does not cascade updates based on a change in the source record. We teach this in the GRC Fundamentals and Risk and Compliance Implementation class. 

Here some thoughts on why the cascading updates for entity owner name don't happen:

• The original owner pulled from the source table is a suggestion. A starting point that the Compliance or Risk Manager may want to override at the entity, control or risk level.
• • Usually the Compliance and Risk teams do not manage the source records. In the implementation course we suggest that the owners of these source records (usually the CMDB owner or Foundation data owner or the Master Data Mgmt team/person) be included on the Implementation team. Maybe if they know how you are using data under their control, then they MIGHT tell you when they change how the data you are using to build entities.
  • • This goes beyond the owner.  if you are pulling data from a specific CMDB class and the CMDB owner decides to use a different class for that type of device, then your entity filter won't produce the entities you need.  Close communication is essential. And if the customer is in the process of deploying Discovery, this is a real possibility.
  • One option is to add a fields to indicate that the owner has been overridden, by who, when and why.
  • The override field can then be used in conjunction with some of Phil's ideas about automation.
• it is also possible to run a scheduled report that compares the original source table value to the entity owner and allow the managers to make choices on what to do.  However, if the owner has been overridden on the risk or control records comparing the source and the entity record don't go far enough.

And don't forget there needs to be a process to catch when risk and control owners need to be updated because the person has left the company or moved to a job that no longer includes these responsibilities. I think i saw a post in the community where someone created manual indicators and sent them to all risk and control owners asking for confirmation that the owner was still accurate. I'm sure there are other ways to approach this too.

Hope this helps.

Jan

[jsuttonCDW]

I appreciate the responses, and quite frankly the downstream impacts are definitely not lost on me. Part of the "protection" we have used in other areas is that push/pull from either the Entity to Controls/Risks or from the Control/Risk getting it from the Entity. Similar to what Risk Statement to Risk offers for Scoring (Update Risks or Revert to Risk Statement) and Test Template to Test Plan (Update All or Revert to Template) I have enabled a True/False check on the lower records to be set to True if there were changes made from the original setting. Then if that is True, it skips those records in an Update All scenario, or when you are trying to revert, but your on the record, so you uncheck it and it allows the update.

I really like the suggestion from @Jan Spurlin on a scheduled report. If we include this as part of the repeatable process that is usually an easy thing to adopt, and it is getting folks the right information to be able to make it easier than searching and doing, the comparison report is a fantastic idea.

Any suggestions on how to create this scheduled report? I have used metrics in the past (onChange) to notate in scheduled reports when something has be updated, so thinking this would be a similar use case. But happy to hear from others.

Thanks!

[Michael Oosten1]

Hi,

Two years later and we're using San Diego. I noticed this new check-box: Auto-update owner. So, it seems to be available now out-of-the-box, although undocumented. I'm guessing this makes sure the Entity owner field gets updates when the source record's owner (i.e. Company -> Business Owner) gets update. However, that doesn't seem to work. I've executed the scheduled job: GRC Profile Generation, but no change. Does anyone know which job should do the actual update?

The GRC Profile Generation job does create new Entities when the source gets more records, but it won't update the Name field, which I was hoping for.

Thanks!