Confidential records
Summarize
Summary of Confidential Records
ServiceNow’s Governance, Risk, and Compliance (GRC) applications allow customers to mark sensitive records as confidential to control access effectively. By enabling therecord level confidentialityproperty, only authorized users or groups can view or modify these confidential records, enhancing data security and compliance.
Show less
This feature applies to multiple GRC modules including Audit Management, Policy and Compliance Management, Risk Management, and GRC Core, starting from the San Diego release.
Key Features
- Enable Record Level Confidentiality: This property is off by default and once enabled cannot be turned off. It activates confidentiality controls and makes the GRC Confidential Records module visible in the application navigator.
- Confidentiality Tab: When marking a record as confidential, the Confidentiality tab lets authorized users specify Allowed Users and Allowed Groups who can access the record. The user enabling confidentiality is auto-added to the Allowed Users list.
- User Roles: Access requires either existing GRC roles or the dedicated
sngrc.confidentialuserrole for users without standard GRC roles. Notifications are sent to users and groups upon assignment, detailing role requirements. - Auto-Populated Access Lists: Specific user and group fields relevant to each GRC table (e.g., Assigned To, Approvers, Reviewers) are auto-populated into the Allowed Users and Allowed Groups lists to streamline configuration.
- Unmarking Confidentiality: Removing confidentiality clears allowed user/group lists and access reverts to standard ACLs.
- Configuration Management: Confidentiality settings for tables can be managed centrally via the
sngrcconfidentialityconfigurationtable (starting with Utah release), enabling updates to default allowed users and groups. - Inheritance: Confidentiality can be configured to inherit from parent to related child records, ensuring consistent access control across related data.
- Additional Setup: Enabling confidentiality requires updating client scripts and access control lists (ACLs) for the relevant tables and forms. Workspace forms also support confidentiality controls.
Tables Supported
Confidentiality is supported on various key GRC tables such as Audit Task, Engagement, Evidence Request Task, Issue, Observation, Policy Exception, Remediation Task, Risk Events, and Operational Sustainability Management tables, among others. Each table auto-populates specific user and group fields to simplify access control configuration.
Practical Impact for ServiceNow Customers
- Enhanced Security: Ensures sensitive GRC records are only accessible to authorized personnel, protecting confidential information.
- Role-Based Access: Access control integrates with existing GRC roles and a dedicated confidential user role, supporting flexible and secure user management.
- Audit and Compliance: Enables organizations to meet compliance requirements by restricting and clearly managing access to sensitive records.
- Configurability: Customers can tailor which users and groups have confidential access, adjust default auto-populated lists, and apply confidentiality inheritance to maintain consistent data protection.
- Notifications: Automated email notifications inform users and groups of their access and role requirements, improving communication and compliance.
Next Steps
- Enable the Enable record level confidentiality property in GRC Properties to activate the feature.
- Configure confidentiality settings on relevant GRC tables and forms, including required client script and ACL updates.
- Use the Confidentiality tab on records to mark them as confidential and manage allowed users and groups.
- Assign the
sngrc.confidentialuserrole to users without standard GRC roles who need confidential access. - Leverage the confidentiality configuration table to customize auto-populated user and group lists.
- Consider setting up confidentiality inheritance for related records to ensure consistent access control.
You can mark sensitive GRC records as confidential. You can then make sure that the right people have access to these records.
You can mark sensitive GRC records as confidential by setting the confidential option for a record. By doing this action, you can ensure that only certain users or users from specific user groups can access these confidential records.
Confidentiality property
The confidential records in GRC are listed under the GRC Confidential module. The GRC confidential records module is displayed in the application navigator only when you enable the Enable record level confidentiality property.
Starting with San Diego, the GRC Confidential Records module is available for the Audit Management, GRC core, Policy and Compliance Management, and Risk Management applications.
Unmarking confidentiality on the record
When you unmark confidentiality on a record, allowed users and groups on that record will be removed and all the users will get access to the record based on ACL.
User roles that are required to access the confidential records
Users with the GRC confidential user (sn_grc.confidential_user) role can access the confidential records. This role is for the users who are not GRC users but who want to access the GRC confidential records.
Users who have access and who are named in the record continue to have access to the record with the existing GRC role.
- You're a risk user and you were given access to a risk record earlier. Now, you're part of the allowed users list for the same record. Therefore, even if you don't have the sn_grc.confidential_user role, you can access the record because you had access to this record earlier and your name is now listed on the allowed users list.
- Your name is listed on the record, but you don't have the sn_grc.confidential_user role. You must have the sn_grc.confidential_user role first to access the record.
When a record is marked as confidential, an email notification is sent out to the users and the user group members informing them about the assignment and the roles that are required to access the record. Every user that is listed in the Allowed users and Allowed groups list gets an email notification about the assignment of the record.
Confidentiality tab on the form
- Confidential option: Enabling the Confidential option on the Confidentiality tab displays the Allowed users and Allowed groups lists as shown in the following figure. Note:A user with write access to the record can enable the Confidential option.
Figure 1. Confidentiality field on a form - Allowed users list: When a record is marked as confidential, only the users in the
Allowed users list have access to the record. A user who is listed in the Allowed users
list should either have read access to the record or have the sn_grc.confidential_user
role to access the confidential records.
The logged-in user who enables the Confidential option gets auto-populated in the Allowed users list. The user who enables the Confidential option on the tab is auto-appended to the Allowed users list by default. Those users with write access to the record can unlock and update the Allowed users list.
Note:There are no restrictions on which users can be added to the Allowed users list. A user who doesn't have the GRC role should have the sn_grc.confidential_user role to access the record. An email notification is also sent to the user about the role requirement. - Allowed groups list: When a record is marked as confidential, only the users that are listed in the Allowed groups list have access to the record. Those users with write access to the record can unlock and update the
Allowed groups list. Note:Confidential records are visible to the users who are listed in the Allowed users or Allowed groups list. By default, the administrators can also view the confidential records. If you do not want the administrators to view the confidential records, follow the steps mentioned in KB1497382.
| Table label | Table name | Application scope | Users that get auto-populated in the allowed users list | Groups that get auto-populated in the allowed groups list |
|---|---|---|---|---|
| Audit task | sn_audit_task | GRC: Audit Management | Assigned To, Engineering lead, Engineering auditors, Engineering approvers | Not applicable |
| Engagement | sn_audit_engagement | GRC: Audit Management | Auditors, Approvers, Engagement lead | Not applicable |
| Evidence request task | sn_grc_advanced_evidence_response | GRC: Advanced Core | Requester, Assigned To, Approvers, Watchlist, Requested on behalf of | Assignment Group |
| Issue | sn_grc_issue | GRC: Profiles | Assigned to, Issue Manager, Opened by | Issue Manager Group,Assignment Group |
| Observation | sn_audit_advanced_observation | GRC: Advanced audit | Owner, Respondent, Peer Reviewer, Reviewer, Watch list Users, Engagement lead, Engineering auditor, Engineering approver | Assignment Group |
| Policy exception | sn_compliance_policy_exception | GRC: Policy and Conformance Management | Requester, Approver, Watch list | Approval Group |
| Remediation task | sn_grc_task | GRC: Profiles | Assigned to, Watch list, Issue Manager, Issue Assigned To | Not applicable |
| Risk events | sn_risk_advanced_event | GRC: Advanced Risk | Current logged in user, Owner, Approver | Owning group, Approval groups |
| Disclosure | sn_esg_disclosure | Operational Sustainability Management | Logged in user, reviewer, assigned to | Not applicable |
| Material topic | sn_esg_material_topic | Operational Sustainability Management | Logged in user, reviewer | Not applicable |
| Metrics | sn_grc_metric | Operational Sustainability Management | Logged in user, enterprise owner, data owner | Enterprise owner group, data owner group |
| Metric definitions | sn_grc_metric_definition | Operational Sustainability Management | Logged in user, enterprise owner, data owner | Enterprise owner group, data owner group |
| Composite metric definitions | sn_grc_composite_metric_definition | Operational Sustainability Management | Logged in user, enterprise owner | Enterprise owner group |
Starting with Utah, confidential configuration for all the default confidentiality enabled GRC tables except sn_esg_material_topic, sn_grc_metric, sn_grc_metric_definition, sn_grc_composite_metric_definition, are shipped to sn_grc_confidentiality_configuration table. You can update and remove the user and group fields that are auto-populated into allowed users and groups of a record from this configuration.
To know more about the confidentiality feature, see KB1218856.
To enable confidentiality in your GRC tables, you must perform additional configuration, such as updating the client scripts and updating access control lists (ACLs). After you update the configuration for a specific ServiceNow platform table, the confidentiality functionality can be used on those table's forms.