Risk Response Tasks and Controls. What is the philosophy of ServiceNow ?

[udryf]

Introduction :

In the ServiceNow documentation, we can find this sentence :
When the risk mitigation task is in the Draft or Work In Progress state, you can either create more risk-mitigating controls for the risk or add existing controls from the library.

https://docs.servicenow.com/fr-FR/bundle/sandiego-governance-risk-compliance/page/product/grc-workspace-risk/concept/risk-response.html

Our case :

Two teams are using ServiceNow GRC (Entreprise Risk and Internal control system, IT Risk). The vocabulary seems to be different (terms "measure" and "control") so we have some difficulties to progress in our implementation.

We have a risk and decided to mitigate it. A risk response task has been created. In this task, we communicate a "plan" to reduce the risk. How can we deal if 2 or 3 entities are concerned and have the responsabilities to reduce this risk ? Actually we don't want to create several risks because only one parent entity has the responsability for the risk.

my proposal : using the "controls" tab to generate several controls for these entities. Then we will have a risk response task with several controls, one or more for each entity.

other teams proposal : adapting ServiceNow GRC to create multiple risk response tasks to address a "risk response task" to each child entity.

What is ServiceNow's idea at this stage of the process? How do we need to work to meet the ServiceNow philosophy?

Does the term "measure" correspond to the "plan" in the risk response task or does the term "measure" correspond to the control in the control tab, which can be linked to a control objective (from ISO 27001 for example)?

Thank you in advance for your insight on this topic, so I can point my colleagues in the right direction.

Regards,
Fabrice

[Roy Verrips]

Dear @udryf 

What you ask is a good question and one related to common misconceptions or incorrect Risk methodologies and usage of terms. 

What it seems to me you are describing in the two groups you mention are different definitions of what a Risk is.   Here is a blog post that may be helpful in identifying the differences Risks 

When you say "We have a risk and decide to mitigate it." and then create a "Plan" you are mixing terms. 

I believe what you have there is an Issue or Finding (against a risk) - The plan would be to remediate or mitigate the Finding, not the Risk itself.  The Risk will still exist once the plan completes, but that "measure" or "risk level" will adjust accordingly.   

I would suggest you look to engage a consulting firm with experience in implementing Risk solutions to assist with the process discussion.  Once your two teams are on "the same page" of what a Risk is, you will see the ServiceNow "Philosophy" will make a lot more sense.

One thing that is worth knowing is that most "traditional" Risk solutions have a top-down approach, starting with the Risk, then identifying controls and applying those controls to applications / devices.   ServiceNow works better when you start from the "bottom up", i.e. identify your entities (groups of applications / devices / services) and then apply control objects against the Entities, which in turn will create controls which in turn will link back to your risks. 

Hope that is helpful!

Roy

[udryf]

Thank you @Roy Verrips  for your advices. 

Yes, you're right when you say that we are mixing terms. The problem is that we have two different stakeholders. I'm sure they think the same thing but don't use the same vocabulary. And both are right  🙂 ..... 

I agree with you and believe that ServiceNow's approach is a good one, and that in our case we are still in a too traditional approach.

I will pass on your suggestion to my two stakeholders and we will see if we can move forward.

Thanks again for your input and have a nice day.
Fabrice