--- sourceDocument: Australia Governance, Risk, and Compliance sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/governance-risk-compliance Release : - australia ft:locale : - en-US ft:publication_title : - Australia Governance, Risk, and Compliance ft:clusterId : - grc bundleId : - grc workflow : - Technology --- # Confidential records # Confidential records {#ariaid-title1} * Release version: Australia * * Updated March 12, 2026 * * ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 5 minutes to read Summarize ![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete. ## Summary of Confidential records The Confidential records feature in ServiceNow Governance, Risk, and Compliance (GRC) allows you to mark sensitive GRC records as confidential, restricting access to authorized users and groups. This ensures that only designated personnel can view or modify these sensitive records, enhancing data security within your GRC processes. Show full answer Show less Confidentiality is controlled by enabling the **Enable record level confidentiality** property under GRC properties at the record level. Once enabled, this property cannot be disabled. The confidential records become accessible through the **GRC Confidential** module, which appears in the application navigator only when confidentiality is activated. ## Key Features * **Confidential Option on Records:** Users with write access can mark a record as confidential via the Confidentiality tab on the form. Enabling this option activates Allowed users and Allowed groups lists that control access. * **Allowed Users and Groups:** Only users and groups listed in these fields can access the confidential record. The user marking the record confidential is auto-added to the Allowed users list by default. * **User Roles for Access:** * The `sngrc.confidentialuser` role is required for users without other GRC roles to access confidential records. * Users already having access to a record and listed as allowed retain access without the confidentialuser role. * Email notifications are sent to allowed users and groups informing them about confidentiality and role requirements. * **Unmarking Confidentiality:** Removing the confidential flag removes the allowed users/groups restrictions, reverting access controls to standard ACLs. * **Supported Tables:** Confidentiality is supported on key GRC tables such as Audit Task, Engagement, Evidence Request Task, Issue, Observation, Policy Exception, Remediation Task, Risk Events, and several Operational Sustainability Management tables. * **Configuration:** * Additional configuration is required to enable confidentiality on GRC tables, including updating client scripts and ACLs. * Confidentiality inheritance can be configured so that related child records automatically inherit confidentiality from parent records. * From the Utah release, default confidential configurations for most GRC tables are stored in the `sngrcconfidentialityconfiguration` table, allowing customization of auto-populated allowed users and groups. * **Administrator Access:** By default, administrators can view confidential records; this can be restricted by following documented steps. ## Key Outcomes * Enhanced security for sensitive GRC data by restricting access to authorized users and groups only. * Clear management of confidential records through dedicated modules and form tabs, improving governance and compliance controls. * Automated notifications to users about confidential record assignments and role requirements ensure transparency. * Flexibility to configure confidentiality on various GRC tables and to manage inheritance, aligning with organizational policies. * Ability to control administrator visibility on confidential records to meet specific security needs. 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 {#confidential-records__section_dp1_v44_psb} A new option Enable record level confidentiality is available under GRC properties at the record level to enable confidentiality. Important: The Enable record level confidentiality property is turned off by default. When it is enabled, it can't be turned off again. 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 {#confidential-records__section_ow3_xpk_zvb} 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 {#confidential-records__section_x4z_dcv_wsb} 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. Consider the following examples for different roles: * 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. {#confidential-records__ul_yrq_gqr_xsb} 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-records__section_amx_5xw_gsb} The Confidentiality tab on the form displays the following lists and options: * 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](https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1497382). {#confidential-records__ul_k5w_cyg_zsb}Users who don't have the GRC user role but are listed in the Allowed users list or Allowed groups list can be assigned with the sn_grc.confidential_user role to access the confidential records. Confidentiality is supported on the following tables.{#confidential-records__table_lvr_wjz_1tb__entry__5} | 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 | [Table 1. Tables on which confidentiality is supported] {#confidential-records__table_lvr_wjz_1tb} 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](https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1218856). [Configure confidentiality in your GRC tables](https://servicenow-prod.fluidtopics.net/1GtJqtLdcAaG2yop~~4cdQ "You can create a confidentiality configuration record in your GRC tables.") 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. For information on how to enable confidentiality in your GRC tables, see [KB1497382](https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1497382). Note: You must log in to Now Support to view the Knowledge Base articles. You can also enable Confidentiality on a form in the workspace view as shown in the following figure.Figure 2. Confidentiality in the workspace view * **[Create a confidential record](https://servicenow-prod.fluidtopics.net/8pE5nS6A4Gm5gpGPRw0RSw)** Create a record and mark it as confidential so that you can make sure that only the users with a specific role can access it. * **[Configure confidentiality in GRC tables](https://servicenow-prod.fluidtopics.net/1GtJqtLdcAaG2yop~~4cdQ)** You can create a confidentiality configuration record in your GRC tables. * **[Configuring confidential inheritance in your tables](https://servicenow-prod.fluidtopics.net/5vmxbGduGvmAv1R~WB4Emw)** You can set up confidentiality inheritance in the tables that are already configured in the confidentiality configuration module. In the GRC application, whenever a parent record is marked or unmarked as confidential, its related table records are also marked or unmarked as confidential.