[Video tutorial] Controls: Attestations, Indicators and Control Tests explained

[Eric Feron]

17 minutes to clarify and disambiguate once and for all the concepts and terminology around Controls, Attestations and Tests.

These are so important to make the best of ServiceNow's GRC solution.This video tutorial is essential before GRC Fundamentals training, after training, before implementation and even if you feel that you mastered it all already.

Guest speakers:

Scott Ferguson, Director, Outbound Product Management, Risk, ServiceNow.

Jan Spurlin: Senior Implementation Trainer, TACO, ServiceNow.

Video contents:

00:01 Introductions

00:42 Why do we need to talk about Controls: Attestations, Indicators, Tests.

02:03 Refreshers: Maturity journey, The get-started tutorials series

02:39 The five-step life-cycle of a Control: Owners, Attestations, Indicators, Tests.

05:02 How it works in ServiceNow: Attestations (Draft, Attest, Review, Monitor. Retire)

06:31 Indicators (Monitor)

08:38 Test

10:30 Common mistakes: just don't do this!

14:16 Please do this right now

16:42 Conclusions

Download the PDF version of the slides:

[darren_halliday]

I agree with the comments about developing maturity over time.  That is to start simple and increase scope and depth of monitoring.  As with Governance, in my opinion, the key is continuous improvement.  To try and obtain scope and depth immediately might be a shock to the organisation and may not succeed.

I also think that a combination of manual and automated Indicators is kind of desirable.  If I am a Control Owner, I would welcome the implementation of automated indictors to build efficiencies in my Control monitoring.  However, I would also welcome the second line checks of a manual Indicator to provide some human oversight and to possibly identify any gaps/inconsistencies in the data that may not be picked through an automated Indicator.

[Eric Feron]

Thank you for this Darren,

we need to continue advising newcomers that GRC gets better over time and it is important to start small to establish robust foundations and clock-in early successes.

Ben Forrest's latest tutorial "Become a GRC athlete" drives the point home once again.

Regarding Indicators, we are working on a dedicated tutorial to go through that topic. Stay tuned (best is to subscribe to the "Policy, Compliance & Risk forum for new customers": updates will be posted there.

[SanjivMeher]

@Eric Feron 

I think there should be a detailed session on how to use manual indicators.

I am confused with, who created the manual indicator templates. 

Indicator template indicators. But what is the use of creating indicator tasks from it?

[Eric Feron]

Hi Sanjiv,

I hear you, in fact we all hear you 🙂

Indicators are next on the list. The tutorial will be published here (make sure you subscribe).

In the meantime, please check out this thread. I hope it helps.

Thank you for your patience.

[Maros Takac1]

@Eric Feron 

If you look at Slide 16 in your Governance, Risk, and Compliance use case guide, you`ll find an example of an attestation that is used to collect evidence for a corresponding control to ensure it is being followed. In the "Controls: Attestations, Indicators and Control Tests explained" video, your recommendation is not to edit the attestation and not to use it in place of indicators. Apparently, an attestation is just a declaration by a control owner that they have a method to enforce the control. Why was an attestation used instead of a manual indicator in Slide 16? Is it by mistake or intentional ? Would you be able to look into it and provide some clarification ? 

Many thanks

Maros

[Eric Feron]

@Maros Takac great question. Let me loop in the experts.

EF

[SanjivMeher]

@Eric Feron I also believe, an organization should either use attestation or indicators.

Both does the same thing. Collecting evidence. 

From a control owner's perspective, if we use attestation only for confirming if control is in place, then why do we give them option to attach evidence in the attestation?

If we are attaching evidence in attestation, why do we create indicators.

If we create indicators, why do we need attestation, because indicators are already taking care of it.

As a control owner, if we give them both the options, he will definitely get confused.

[Maros Takac1]

Sanjiv,

we don`t see anything wrong with collecting evidence for two different tasks. With an attestation, you collect evidence to confirm that a control is in place/implemented. E.g. "Manage Changes control objective", I`d expect a control owner to upload a change management policy and some additional evidence to prove that we have a way/method to manage changes in our organization. However, this evidence does NOT confirm that we are being complaint. This is where indicators come in. With an indicator, we actually check to see whether a corresponding control is being adhered to/followed.

Please note that the above is only our own interpretation of the role of attestations and indicators as we are currently awaiting clarification from ServiceNow due to the fact that We are seeing conflicting recommendations in their communication material ( Slide 16 grc-useguide ).

Cheers

maros

[SanjivMeher]

It took me time to understand that.

Attestation is only for declaration by the control owner to the reviewer that they have mechanism in place to provide evidence for this control, and this is done while onboarding a new control or attest a non-compliant control.

Now, the control is in monitor state and an indicator task is created. It is pretty difficult to find out for which control the task is created. Why are the indicator tasks not listed under controls?

Who is suppose to mark the task as completed? 

Is it the control owner or the reviewer? 

If the control owner is suppose to mark it completed, why do we provide the Pass/Fail option also to the control owner. It should be with the reviewer to decide if the task has the right evidence and then the reviewer should mark it Pass or Fail.

What is the use of Value field on the indicator task and why is it mandatory. There is no helptext about what to enter in that field.

[Maros Takac1]

Now, the control is in monitor state and an indicator task is created. It is pretty difficult to find out for which control the task is created. Why are the indicator tasks not listed under controls?

You can easily accomplish this by creating a new related list/relationship. Obviously, SNOW cant add every single related list to every form, it is up to you to decide what else should be shown on each relevant form. so if you need to show Indicator Tasks on the control form, go ahead and create a new relationship.

Who is supposed to mark the task as completed? Is it the control owner or the reviewer? 

I`d say a control owner but even a control owner may want to delegate it to someone else. let me give you an example.

we have a control objective "Every employee must wear an identification badge in the office". I go ahead and create a new entity type listing all Offices and make each office manager an entity owner who would be cascaded down to a control level as a control owner as well. I also set up a new manual indicator which would create a task for each control owner -> office manager to report on how well this control is being adhered to. In practice: walk around the office, check to see whether EVERY employee wears a badge, note down your observation and then mark your task either Pass or Fail. In my opinion, Pass would mean that everyone had a badge, Fail would mean that some did not have a badge. Most importantly, there is nothing to stop an office manager from lying about their findings, they may never walk around the office, they may never do any checks, they may just routinely mark each task assigned to them as Pass. This is where your "review" comes in in the form of Audit. That is where you need to use the 3rd component, Audit Management to verify that whatever evidence was provided through Indicator Tasks actually reflects reality ! Trust but verify...

What is the use of Value field on the indicator task and why is it mandatory. There is no helptext about what to enter in that field.

depends on what you are measuring and it does not have to be mandatory where it is not applicable. In my example above, I would not make it mandatory... what would be the benefit ? maybe capture a number of employees without a badge ? I think it would make more sense to make it mandatory for metric-like threshold based indicators. "If X number of incidents raised against an application or some other CI", only then mark a control as non-compliant. now, what if we don`t store this type of information in SNOW, what if incident management is done through some other system and SNOW is only used for GRC ? a very likely scenario... in that case, you would want to get that value: a number of incidents for an application from your Incident management tool and copy it into the VALUE field of your indicator task to then decide on Pass/Fail, using your set threshold..

Hope it makes sense ?

Cheers

maros

[Eric Feron]

@Maros Takac it seems that Scott's presentation is correct, although the White paper is not wrong. We are looking to get the white paper revisited: we are headed for a discussion between experts... 🙂

I will share more when I have more to share. 

[SanjivMeher]

Are you saying there should be a control test for every control? And then failure create a remediation task. Isn't that too complicated for a customer to follow? There is an attestation, indicator task , issue, remediation task.

Also there is a scheduled job 'Control attestation nightly run', which move the controls back to attest based on control frequency.

I think the frequency field in control confuses the user. Because there is a frequency in indicator too.

Why do we need frequency in control, if the frequency is controlled based on indicator?

[Maros Takac1]

regarding your first point, I dont think it is too much. Nobody says that you need to create a control test for every single control. Furthermore, you would have different groups undertaking different tasks. For instance, test templates/plans, control test would be handled by internal/external auditors; whereas indicator templates/indicators would be created/managed by control owners or some compliance actors..

regarding your second point, I believe there should be an option to disable it. Essentially, what it is saying is: every year/month/whatever option you choose, tell us that your control is still in place/implemented even though you are already measuring it through indicators.

[SanjivMeher]

Thank you Maros. During the implementation, Did you create both attestation and indicator together and released your module or did you do it in phased manner?

For ex, I am planning to first build the attestation part and release it.

And then indicators can be created in phase 2 or on the fly while controls are live. What would you suggest?

[Maros Takac1]

To be honest, We first created and used attestations in place of indicators, which is something this particular video is warning against. So with that in mind, my suggestion would be to use attestations if you are looking for a control owner`s declaration that their control is in place/implemented. Furthermore, When you create your controls by linking entities to your control objectives, I suppose you want to do more than just check whether or not those controls are in place...?, you want to measure whether they are being followed right ? if yes, go ahead and set up Indicators. it is completely fine using both if your answer to my two points above is yes. 

[Maros Takac1]

@Eric Feron thank you and hope to hear from you soon

[Eric Feron]

Here is the current list of "get started" tutorials for new customers:

For Policy, Compliance and Risk:

• Prepare to implement Policy, Compliance and Risk
• Implement Policy, Compliance and Risk
• Find the right partner for your implementation
• What training is right for you?
• Profiles (Entities) for Governance, Risk and Compliance: why you need them and how to set them up.
• UCF - Why and how.
• Entities (fka Profiles) in a few words: All places, people and things that...
• Entity Scoping: how GRC Community experts do it.
• Controls: Attestations, Indicators and Control Tests.
• IT compliance.
• Become a GRC athlete.
• GRC implementation checklist.

For Vendor Risk Management:

• Get started with Vendor Risk Management - Product demo.
• Find the right partner for your implementation
• What training is right for you?
• Solve IT Vendor Risk.
• The Vendor Portal in 5 minutes: What it does, how to use it.

[SanjivMeher]

@Eric Feron @Maros Takac Does control test works for manual indicators?

[Eric Feron]

Hi Sanjiv, yes.

• Indicators are simply a "feature" of Controls.
• Indicators can be Basic, Manual, Automatic and Scripted. 

Stay tuned, we are putting together a tutorial on Indicators that will bring the whole story together from that angle.

[SanjivMeher]

@Eric Feron Do you have similar video for Risk Lifecycle?

[Eric Feron]

Hi Sanjiv, unfortunately we do not (yet).

It is on the list for future episodes of the "get started with GRC" series.

Thank you for your patience.

E

[amurana2]

Hi, Eric,

The 2nd LD (Risk & Compliance Team) uses Compliance Mgmt. app. (Attestation and Indicator), and if the 2nd LD (Risk & Compliance Team) wants to use Control Testing (TOD/TOE), they have to use Audit Mgmt. app. as a hybrid approach.  Is it correct?  Because our 2nd LD does SOC2, ISO27001, PCI, FISMA, PCI, GDPR, CCPA, and other compliance, and our 3rd LD (IA) does SOX.  Thank you for the comments.  

[AnneMarie Ferna]

Sanjiv

Control Tests are related to a Control Objective (as Test Template) and apply to all related entities (Controls as a Test Plan). You then select either all or a subset of the test plans that you want to run and they are generated as Control Tests in audit.

I hope that helps there's a video we just finished on that.

[AnneMarie Ferna]

Correct, Control Testing is run part of Audit only, but they are set up on the Compliance side (Test Template > Test Plan > Control Test).

Audit is a verification of testing you've been doing all along, e.g. collecting SOX compliance data via indicators. Audit is look backward to say "how compliant were we in Q1 for these controls" and marking the result via the Control Test. across ALL the authorities you mentioned.

I hope that helps. 

[Eric Feron]

Thank you for this Anne Marie!