Multiple indicators for a control?

[KrithikaV]

1. When would one configure multiple indicators(more than one) for a control? 

2. If there are two indicators and one has status: PASSED and the other has status: FAILED, how is the compliance calculator for this control?

Thanks in advance,

Krithika

[Community Alums · Accepted solution]

Hi @KrithikaV ,

We tend to use Multiple indicators in a situation when you have multiple Targets to achieve .

Let's understand this way, i have one target to check run on a specific shedule and check for certain thing and another will check for a different thing, then i should have 2 indicator templates to be added to teh control objective record.

For Example:

Now, once you run these indicators, Indicator tasks will be created for each indicators and will be assigned to the control owner.

The Basic type of indicator is used to query other tables within ServiceNow. Let's say for example you're looking on TableA to see if there's any records in that table that match the name of the control you're currently looking at...the question becomes then what? If you do find results then is that a good or bad thing? The passed/failed field is used to determine whether the indicator should pass/fail if results are found based on what type of search/query you're creating. You might want results in some cases and therefore it should pass, and in other cases if you find any results then that's not a good sign and therefore you can set the Passed/Failed field to failed. 

When you fail an indicator Task, it sets the Control to "Non-Compliant" and create an Issue Task. 

The Issue Task needs to be worked on. The idea is that you need to Remediate or Accept  the reason why its not compliant (in order words fix or accept the issue). If you Remediate and Close the issue, the control will change to compliant. However if you Accept and Close the issue, the control stays at non-compliant.

The "failing" indicator task was closed, it likely created an "issue" for the control. Navigate back to the control and look at the issue related list. You should see an open issue. The issue has to be closed in order for the control's status to be updated.

[Community Alums · Accepted solution]

Hi @KrithikaV ,

We tend to use Multiple indicators in a situation when you have multiple Targets to achieve .

Let's understand this way, i have one target to check run on a specific shedule and check for certain thing and another will check for a different thing, then i should have 2 indicator templates to be added to teh control objective record.

For Example:

Now, once you run these indicators, Indicator tasks will be created for each indicators and will be assigned to the control owner.

The Basic type of indicator is used to query other tables within ServiceNow. Let's say for example you're looking on TableA to see if there's any records in that table that match the name of the control you're currently looking at...the question becomes then what? If you do find results then is that a good or bad thing? The passed/failed field is used to determine whether the indicator should pass/fail if results are found based on what type of search/query you're creating. You might want results in some cases and therefore it should pass, and in other cases if you find any results then that's not a good sign and therefore you can set the Passed/Failed field to failed. 

When you fail an indicator Task, it sets the Control to "Non-Compliant" and create an Issue Task. 

The Issue Task needs to be worked on. The idea is that you need to Remediate or Accept  the reason why its not compliant (in order words fix or accept the issue). If you Remediate and Close the issue, the control will change to compliant. However if you Accept and Close the issue, the control stays at non-compliant.

The "failing" indicator task was closed, it likely created an "issue" for the control. Navigate back to the control and look at the issue related list. You should see an open issue. The issue has to be closed in order for the control's status to be updated.

[Phil Swann · Accepted solution]

Check out Issue Source on the Issue. 

There is also a property sn_grc.auto_indicator_issue_closure which defaults to false, you might want to set this to true. 

Issue Source on an issue is trying to consolidate the compliance failures; so if the attestation fails and indicator fails, then an attestation pass cannot close the issue, if there is still an indicator failure. 

If you have an indicator failure, and an indicator pass - it shouldn't matter, as the issue source is still active on that issue, until ALL indicators pass, this source will remain. 

The only time, is whether you manage that issue manually and what I say "work the issue", as this manual activity can remediate the issue and set the control to compliant. But, if/when the indicator(s) run again - if they fail, will create a new issue. The important thing is to make sure you are addressing the root cause. 

Regarding 1. When might you have two for the same? Potentially, as per my community video a while ago on Indicators- I explained that indicators can be used to check both sides of the same coin. 

Maybe, you want to check for the good stuff, and if there is no good stuff then it fails. (Incidents managed in accordance with SLA)

Maybe, you want to check for the bad stuff, and if there is no bad stuff, it passes. (Incidents breaching SLA...)

But, what if you have no incidents? Is the fact that your application does not generate any incidents, e.g. its stable, a BAD thing because there is no good data? So you can also use thresholds etc to set some boundaries. 

My suggestion is, if you are struggling for these use cases, probably its not something to focus on right now. I would focus on getting the organisation working in a way that allows them to demonstrate their internal compliance and recognise the behaviours and process limits, on a single basis before expanding. Maybe walk, then a gentle jog... 

Hope this helps!