Issue Workflow / Remediation Task only created by a user with Compliance Manager Role?

[Jamie Jackson]

I'm curious what the rational was for only allowing the role of Compliance Manager to create Remediation Tasks on an Issue?

It was seem like the Control Owner (user role) would have access to that as well. And as the Issue Owner steps through the state flows, if they are in the Respond or Review state, does the Compliance Manager receive a notification to request a Remediation task get created when they respond with Remediate? I don't see anywhere that is set and other than spelling it out in work notes, I'm not understanding how a Compliance Mgr would know to do that.

I'm a missing something?

[Shiva Thomas · Accepted solution]

Hi Jamie,

It would depend of your internal processes. When a Control is not compliant, and an issue is generated, the first thing to do is to investigate the issue to assess its criticality and decide what to do with it: Accept or Remediate.

Should Issue's assessment be done by the Control's Owner? In that case, yes, you're right, he should be also be able to create remediation tasks. In that case, you could grant him/her the Compliance Manager role (easier), or change the ACL to allow the Control's Owner to have the same right (harder).

What if the Control's Owner should not be the one who have decision authority about Issues? In that case someone else, typically a Compliance Officer, should assess the criticality and decide acceptance or remediation.

Here is a real life example... You have a Control, assigned to your Database Administrator (the Control's Owner), that check that your Oracle server is kept up to date. For months, the control is a simple manual Indicator, or a GRC Attestation, asking the DBA to confirm that the server fully up-to-date. Every month the DBA confirms manually that the control is Compliant, but in reality it's not the case. During an external audit, the author find that the DBA lied and the server has not been patched in the past year.
To avoid running again into that situation, you decide to automate the Indicator (Oracle version release date is less than 4 months old). Now, if the Control go to a Non-Compliant status because of the script return false, should the DBA be allowed to set the Issue as acceptable and continue to ignore the updates? I don't think so. So, the Compliance Officer (role Compliance Manager or Compliance Admin) have to review the issue with the DBA. The CO then creates a remediation task for the DBA, requesting a software upgrade, and possibly take disciplinary action.

As you can see, it's probably best if Controls are not assigned to the same individuals who have the responsibility of managing Issues. Once the Issue is managed (at the Compliance Officer/Manager higher-level), then the remediation tasks can be assigned to relevant assignees. This enforce Segregation of Duties, a fundamental best practice in GRC and SecOps.

About Notifications on the Issue's table… out-of-the-box there are two: "Notify issue assigned to" and "Notify issue closed". They both are send to Issue's  Assignee. I would suggest that you configure some "Assignment Rules" to define the default assignment group or assignee, and to create a new notification for "Notify issue assigned to group".

∴
Best regards from Switzerland
Shiva :¬,

If this reply assisted you, please consider marking it 👍Helpful or ✅Correct.
This enables other customers to learn from your thread.

[Asif9]

Hi Shiva,

what role should the respective Assignee should possess. is that a compliance user??