GRC- Attestations that have reset to draft based on making a change to the Control

[Meehan76]

After making a change to some control objectives (classification), it has set the controls back in to draft state. How can I move these in bulk back to review and monitor state and keep frequency the same from the initial attestation date?\

Thanks 

[Khang1]

From my implementation experience, you cannot bulk move control workflow by default, which I think is a bit of a miss from the product. You have to move each control individually from Draft to Attest > Review > Monitor. 

We had to use the 'Import Set' functionality to bulk change the status field in ServiceNow. You need admin access to perform such action and have to map table/fields carefully to not mess with other data or creating duplicate records (which we did by mistake...). 

Now, we have developed a 'workaround' to let normal GRC admin perform bulk control move. We created custom 'UI Actions' to mimic the functionality of the Monitor button in the form. Then check the 'List Choice' option for that UI Action (see pic #1 below). MAKE SURE you don't update the baseline 'Monitor' UI Action; create a copy of it and enable 'List Choice'. 

What this does it when you are in the list view of the Control table, you can select multiple controls and the option to 'Move to Monitor' (or whatever name you choose for the UI Action) will be available at the bottom of the list. See pic #2 below. DISCLAIMER, this is not ServiceNow official solution, we developed it ourselves to fit our need as our company attestation process is a bit different than what the baseline product offers.

[Community Alums]

I wouldn't do that, you are creating flaws/liabilities in your process. How can you ensure that the controls are in accordance with the control objectives if you are giving the chance to avoid the attestation, even if you set up for "admin" only? If your user is an "Admin", you can execute scripts so you don't have the need to add an additional list item giving chance to someone clicking it by mistake. Every time you need to change something, try to do it with a script and avoid any customisations at this level. Mistakes happen 🙂

[Khang1]

Mentioned 'GRC Admin' access (sn_grc.admin), not overall system admin access. We give GRC admin access to business team the manage controls. We don't want them to write scripts as they are not IT.

As I said, the baseline process doesn't quite fit for our company process. We have a quarterly attestation process for all control. Therefore, we don't need to attest everytime some minor thing change in the control.

Also,we built a bit of additional fields to the control record that doesn't need attestation if changed. For example, our SOX control would have a field to indicate if external audit rely on the control for certain year, and that field would change every year for hundred of our controls. That field doesn't need to be attest as it's not impacting control objective.

Also, want to mention something quick and not mean to offend anyone here. There is NO such thing as correct process in GRC. Every company will do it differently. SNOW has been a great product for us and has good baseline process, but that doesn't mean that the perfect process everyone should follow. Don't get me wrong, if you can use process out of the box, it's great, less cost to implement. We happen to be a big company with thousands of control owners and controls. We can't just change our process to fit SNOW, and probably the same for a lot of companies. I think it's more beneficial to understand why someone need certain features and offer all possible solutions, vs saying something is wrong for not following SNOW baseline process.

[Community Alums]

Your SOX approach is an excellent idea, love it! Yes, agree. That's the beauty of GRC, there is no wrong or right here. I just highlighted that could lead to human error but its all depends of your organisational needs. In the end we just need to ensure we try to follow SN best practise at all means. Well done Khang, great job