Skip to content
Notifications
Clear all

How do you handle 'accept risk' approvals without losing track of them?

3 Posts
3 Users
0 Reactions
1 Views
(@benchmark_bob_43)
Estimable Member
Joined: 3 months ago
Posts: 90
Topic starter   [#6343]

Alright, so I’ve been poking at ServiceNow GRC for a few months now, trying to wrangle its risk module into something that doesn’t make me want to scream into a log file. The whole “accept risk” workflow seems like a black hole for accountability if you don’t rig it right.

My current setup uses a custom business rule to auto-create a quarterly review task for any accepted risk, but it feels… clunky. The approval vanishes into the ether after it’s signed off, and good luck remembering to check that dashboard widget six months later when the risk owner changes.

Here’s the basic trigger I’m using to spawn a follow-up:

```javascript
// Business Rule: After 'Accept Risk' approval
// Table: sn_grc_risk_response
// When: After, Update

if (current.state.changesTo('accepted') && current.risk_acceptance_approved == true) {
var reviewTask = new GlideRecord('task');
reviewTask.initialize();
reviewTask.short_description = 'Quarterly Review - Accepted Risk: ' + current.risk.getDisplayValue();
reviewTask.description = 'Scheduled follow-up for accepted risk. Original response: ' + current.number;
reviewTask.assigned_to = current.risk.owned_by;
reviewTask.due_date = new GlideDateTime().addMonths(3); // 3-month review cycle
reviewTask.insert();
}
```

But this is just creating more tasks in the void. My questions for the room:

* How are you **enforcing** that these reviews actually happen? Just hoping assigned users check their queue?
* Are you tying the original risk record to the review task in a way that’s queryable for audit trails? I’ve seen some ugly JOINs in reports…
* Has anyone built a dashboard that actually surfaces *stale* accepted risks (e.g., accepted > 1 year ago, no review in last 90 days)?

I’m half-convinced I need to bolt on a custom metric to the risk table and a scheduled job to flag aging acceptances, but I’d rather not reinvent the wheel if someone’s already benchmarked a better approach.

benchmarks or bust



   
Quote
(@amyc)
Estimable Member
Joined: 1 week ago
Posts: 86
 

That quarterly review task approach is a solid start, but I hear you on the clunkiness. It's easy for those tasks to become background noise themselves.

Instead of just auto-creating a task, we've had success tying it to our standard risk review cadence in the calendar. We added a date field for "Next risk acceptance review" on the accepted risk record itself, then built a scheduled report that goes to all risk owners listing anything due in the next 30 days. It lives in their normal operational reporting, so it doesn't require checking a special widget.

Have you considered using the risk's inherent review cycle? You could modify your rule to set the due date based on the risk's own next scheduled assessment date, which might sync better with existing processes.



   
ReplyQuote
(@emmab5)
Eminent Member
Joined: 1 week ago
Posts: 33
 

Oh, I like the idea of using an existing review cycle. That makes it feel less like an extra chore.

But what happens when there isn't a set assessment date for the risk? Do you just default to a standard quarterly or yearly date?

Setting a "Next review" field directly on the risk record seems way cleaner than my pile of tasks. Gonna have to try that.



   
ReplyQuote