Roles required for Policy Ownership, Issue Ownership and Remediation

ajaymandal
Tera Contributor

Hi All,

 

What role is required for Owner in Policy to review and approve the policy? 

What role is required for Issue (Assigned to) in Policy?

What role is required for Remediation Task (Assigned to) in Policy?

 

Please suggest the best practice to set this up. So that anyone in {My company} can be assigned as the owner of the policy. 

1 ACCEPTED SOLUTION

TharaS657398130
Giga Guru

In ServiceNow GRC, there isn’t a strict OOB “one role per field” setup for Policy Owner, Issue, or Remediation Task — access is mostly controlled through GRC roles + user criteria + ACLs/workflows.

For Policy Owner (review/approve), users typically need roles like sn_compliance.user (or sn_risk.user) to access GRC records, and approval capability is usually driven by the workflow/approval configuration, not just a role. So if someone is set as the owner and included in the approval flow, they can review/approve as long as they have basic GRC access.

For Issue (Assigned to) and Remediation Task (Assigned to), the assigned users generally need at least sn_grc.user / sn_risk.user / sn_compliance.user (depending on your module) so they can view and update the records assigned to them.

Best practice

If you want anyone in your company to be a Policy Owner:

  • Give all relevant users a base GRC role (like sn_compliance.user)
  • Use User Criteria (instead of roles alone) to control who can read/write/approve policies
  • Configure the policy workflow/approval to use the Owner field dynamically
  • Ensure ACLs allow the owner/assigned user to edit their own records

👉 In short:
Don’t rely only on roles per field — use a combination of basic GRC access role + user criteria + workflow-based approvals so ownership and assignments remain flexible.

View solution in original post

1 REPLY 1

TharaS657398130
Giga Guru

In ServiceNow GRC, there isn’t a strict OOB “one role per field” setup for Policy Owner, Issue, or Remediation Task — access is mostly controlled through GRC roles + user criteria + ACLs/workflows.

For Policy Owner (review/approve), users typically need roles like sn_compliance.user (or sn_risk.user) to access GRC records, and approval capability is usually driven by the workflow/approval configuration, not just a role. So if someone is set as the owner and included in the approval flow, they can review/approve as long as they have basic GRC access.

For Issue (Assigned to) and Remediation Task (Assigned to), the assigned users generally need at least sn_grc.user / sn_risk.user / sn_compliance.user (depending on your module) so they can view and update the records assigned to them.

Best practice

If you want anyone in your company to be a Policy Owner:

  • Give all relevant users a base GRC role (like sn_compliance.user)
  • Use User Criteria (instead of roles alone) to control who can read/write/approve policies
  • Configure the policy workflow/approval to use the Owner field dynamically
  • Ensure ACLs allow the owner/assigned user to edit their own records

👉 In short:
Don’t rely only on roles per field — use a combination of basic GRC access role + user criteria + workflow-based approvals so ownership and assignments remain flexible.