Ownership of Policies & Admin Roles

[Gene Manuel3]

I understand that the sn_grc roles are changing in Orlando (per this post https://community.servicenow.com/community?id=community_blog&sys_id=7d07e198db4b0cdc5ed4a851ca961994)

The question I have is based on the following scenario. I have two different groups that are using the Attestation piece to manage Controls. Each group has their own Policies, Policy Statements, etc. However, both are asking to have the sn_compliance.admin roles added so they can fully manage their Policies & Controls. Giving them that role opens up the possibility of them accessing each other's Controls.  We don't yet have a Policy and Compliance process owner or someone that will be overseeing the entire Policy and Compliance module (we are early into implementing this company wide).

Is there a way we can give groups the ability to manage their own Policies?  Am I going about this the right way?

[Community Alums · Accepted solution]

Hey Gene

Providing admin is not going to solve your problem - check here the roles for P&C - the role sn_compliance.admin in addition to the inherited permissions, the compliance admin can delete authority documents, citations, policies, control objectives, and controls. 

So your main concern is sharing data i.e. "visible and editable" between the groups and want to limit the access? So you want a role to be able to create/edit/read authority documents, citations, control objectives, and controls but only for their group?

The first thing cross my mind was to have a kind of power user (a user with limited manager permissions). 

Lets call this intermediate role as group_manager. So what can do the group manager?

• Bringing some functionalities from the manager - "create authority documents, citations, control objectives, and controls" but limited for only for their group. 
• It will contain the sn_compliance.user (Contains the reader role in sn_grc scopes. In addition to the inherited permissions, the compliance reader can be assigned indicators templates, indicators, and issues.)
• Which will inherit the sn_compliance.reader. (Contains the reader and user roles in sn_grc scopes, and the reader role in the Policy and Compliance Management application. In addition to the inherited permissions, the compliance user can be assigned controls and create policies, and has read-only access to the Risk Management application and modules.)

In order to limit the read access, you need to create a new user READ operation ACL for the table Controls and Policies to only allow read records if logged user is part of the same group as the control.owner (probably we need to find the right field to be our SoT) and inactivate the out of the box ones.

I think this is what you are looking for. Let me know your thoughts

[Gene Manuel3]

Awesome thanks for the response Rafael!!! This is inline with what the team is looking for.