Confidentiality Configuration is not working for Policy table

[MuraliKChintha]

Hi All, 

I was trying out the Confidentiality configuration functionality in GRC. It is working for the OOB tables for which confidentiality is already configured(for the records that gets created when confidentiality property is enabled.). But when I try to create a new Confidentiality record for policies, the functionality is not working. I have created the 3 fields required for confidentiality.

Any help will be appreciated! 

Thank you

[Hema Padala]

Hi Murali,

As per out of the box configuration, Policy table does not have confidentiality feature. We can not achieve confidentiality feature just by creating 3 fields as OOTB does not allow this Policy table.

But, we can customize this Confidentiality feature for Policy table if your client or partner is agree to make customizations without affecting OOTB behavior.

1. Create 3 fields called "Confidential", "Allowed Users" and "Allowed Groups" (Some fields are optional as per your requirement).

2. Create a Module (URL based) under "sn_grc_confidentiality_configuration" table. This is to display only confidential policy records when Confidential field is checked and who are present on those confidential records.

 Note: Use below under Arguments fields under Link Type tab while you are creating a module. 

sn_compliance_policy_list.do?
sysparm_fixed_query=u_is_confidential=true^EQ^u_confidential_usersDYNAMIC90d1921e5f510100a9ad2572f2b477fe^ORu_confidential_user_groupDYNAMICd6435e965f510100a9ad2572f2b47744

3. Write a Before Query Business Rule on Policy table to display confidential records to the appropriate users. Please refer the attached text file for the code to put in Before Query Business Rule.

Please leave your comments here if you have any further questions.

[MuraliKChintha · Accepted solution]

Hi @Hema Padala,

The first two points in your answer are correct but it requires additional configuration. Client scripts, Business rules and ACLs have to be created after creating a record in the Confidential configuration table.

Client scripts(reference): (these should be duplicated for the desired table)

https://<instance-name>.service-now.com/sys_script_client_list.do?sysparm_query=table%3Dsn_complianc...

Business rules:

https://<instance-name>.service-now.com/sys_script_list.do?sysparm_query=name%3DSet%20scratchpad%20values%5EORnameLIKEnotify%5Ecollection%3Dsn_compliance_policy_exception&sysparm_view=

ACLs:

• A new table.none read ACL has to be created with the following script in the advanced section.
  • Script: answer = (gs.hasRole('sn_grc.confidential_user') || ) && new sn_grc.GRCSecurityManager().canReadConfidentialRecord (current);
• An extra condition has to be added in all the read ACLs: 
  • Condition: new sn_grc.GRCSecurityManager().shouldCheckExistingACL(current) && <existing ACL conditions>
• An extra condition has to be added to the Delete ACLs
  • Condition: current.canRead()

UI Actions:

• All the UI actions should be updated with a condition
  • Condition: current.canRead()

Notifications: (create a new Event for the notification)
https://<instance-name>.service-now.com/nav_to.do?uri=sysevent_email_action.do?sys_id=fb2f965bc7b330...

References:
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1497382

[ab_2511]

Hi @MuraliKChintha ,

I’m uncertain why there’s a need to keep policies confidential, given that they don’t contain any sensitive data such as financial or confidential information.

Customizing this approach could potentially lead to future confusion. For instance, a Control Owner can view a Control and its associated Control Objective, but if they can’t access the Policy of that Control Objective, they might assume there’s no association between the Control Objective and any policy.

Regards,

Aakash

[MuraliKChintha]

@ab_2511 I am still working on a POC and weighing the pros and cons. This is a good point to consider. Thank you