Automatically generate controls when relating an entity type to a risk statement

[MAKR]

Hi Community,

I currently have an issue with the risk mangement

Here is the situation (DEV-Instance):
- I created a risk statement and related it to a control objective, which is active and creates controls automatically
- I related an entity type to that risk statement
- a risk per entity in the entity type was created.

So far so good.

What I furthermore expected:
- automatically relate the entity type to the control objective (due to the control obj - risk statement- relationship)
- therefore automatically generate a control per entity
- automatically relate the control to the risk

Unfortunately that was not part of the outcome. That means there would be a lot of manual work to be done to create these releationships (currently 1000+ risk statements and more than 1 control objective per risk statement)
1. Relate the entity type to the all control objective
2. Relate all controls to the risk.

I can't believe that this is the way ServiceNow wants us to go. I tried to find a workflow, flow, business rule or script include that performs the expected actions ... but I was not lucky at all.

Is there really no implementation automating these actions? If so, why?!

I hope anyone can help me out.
Many thanks in advance.

Cheers
Mathias

[Phil Swann · Accepted solution]

Hey well thanks for watching glad it was in some way helpful and sorry it seems I missed the point a little!

So I do not think that GRC will do what you want straight OOTB but it could be possible. Let me explain why I think it does what it does, and not what you want... 

The generation of the Risk::Control mapping is automatic and only matched on Entity; so it assumes the relevant Control or Risk exists in order to map. What you are asking for is to scope the Controls based on the scoping of Risk... the system does not KNOW that you have that control in place and it might not be relevant for the respective Entity.

e.g. 

the Risk: Loss of Integrity could be scoped to both Critical and Non-Critical Apps... , let's say that Slack is non-critical, but MS Teams is critical... so you have the same Risk for both of these applications.

You might have a Control in place to "Validate Integrity"; which would be mapped to the Risk above (using Control Objective::Risk Statement (CO::RS)) mapping).

BUT as this Validate Integrity is manually intensive, you only scope if for Critical Apps. Therefore you would have a Control for MS Teams but not Slack.

When you look at the Risk for MS Teams you see it has a Control against it, but the Risk for Slack does not... If the system took this CO::RS mapping as the guiding light for Entity Scoping too, you could end up with high volumes of Controls which are not really relevant or would ever really be implemented.

Is there any way you can organise your Risk Statements and Control Objectives using Risk Framework and Policies, to ensure that the scoping is appropriate? And thus, you can benefit from the automation? If you are just trying to avoid the initial scoping exercise due to overhead, it should be set & forget- so once its done, you can focus on other activities, such as managing the processes (Attest & Assess). Rather than scoping Entity Type to content, you can scope it to the document and cascade to the content. This can provide greater clarity over what is in scope and why.

If this doesn't work (why not?), it could be possible to introduce some additional logic - as we have the triggers coming in from the initial CO::RS mapping, and other Generate Links methods.. but I would challenge that requirement and really exercise caution because my worry for you would be that it could easily get out of hand, or rather out of control 😛 

CO::RS mapping is relatively new in the GRC apps, it used to be that you always had to map Control to Risk at the item level and never at the statement level, so its a much needed enhancement which I think is very well received. Maybe it does need what you require, but you should consider a System Property to allow you to turn it off! Some of the biggest challenge implementing GRC and driving adoption is around the fact it can generate significant volume when let loose and has to be reined in so you need to be able to apply scoping in an appropriate way.. 

Hope this helps and appreciate the discussion! 

[MAKR]

Hey Phil,

I get your point and agree regarding the amount of "not applicable" controls, esp. in the IT-risk context. Nevertheless, I still think the functionality should be implemented: Especially in customer situations, the initial setup might be very comprehensive, depending on how mature customer's risk management process and documentation currently is. Focussing on company risks and common policies (e.g. clear desk, onboarding, home office etc.) usually all departments are in scope and should implement the same controls. I really like your idea of having a sys-prop. that lets the admin decide to enabled/disabled the functionality.

Thanks a lot for the background knowledge and letting me know that there is currently only the way of customizing.

Cheers
Mathias