Best Practice for Restricting Sensitive Data in ServiceNow Catalog Requests and Incidents

[adityapitani]

Hi Community,

I am looking for best practices for handling sensitive information (PII/confidential data) within ServiceNow Catalog Requests and Incident Management.

We have a requirement where only specific support groups should be able to view certain sensitive fields and attachments, while other users should still be able to access the request or incident record without seeing the confidential information.

Some options we are evaluating are:

Field-level ACLs with role/group-based access.
Storing sensitive information in a separate restricted table linked to the request/incident.
External document/template approach (e.g., storing sensitive information outside ServiceNow and linking it back to the record).
Other out-of-box capabilities such as IRM, CWM, Data Policies, Dynamic Visibility, etc.

A few challenges we are considering:

Attachments containing sensitive information.
Ticket reassignment between multiple support groups.
Reporting and audit requirements.
Preventing exposure through exports, reports, list views, or APIs.
Minimizing customizations and maintaining upgrade safety.

For organizations that have implemented similar requirements:

What approach did you choose?
Were field-level ACLs sufficient?
How did you secure attachments?
Is there any recommended out-of-box ServiceNow capability for this scenario?
What would you consider the most maintainable and governance-friendly solution?

Appreciate any guidance, lessons learned, or architecture recommendations.

Thank you.

[Luiz Lucena]

Hi @adityapitani 

We are on same boat here. 

The very first thing to do is evaluate the plugin Explicit Roles. This is the first recommendation from ServiceNow.

That plugin itself already adds a security layer, for example, masking sensitive and personal information in the user table for users with role snc_internal. This role is automatically added to your entire active users. 
Test thoroughly in lower environment, including your service catalog, variables, variable sets, etc.

For CMDB_CI table, I'm adding field level ACLs, which in turns cascade to the child tables. For those tables where the field are not on the parent table, I'm adding a separate ACL for them. 

Instead of having these fields opened to all ITIL users, I'm narrowing down to a role more specific to what they need to do for work, like the asset role for example. For us, instead of having 600 users with access to those fields, by using the asset role, only 147 users. 

Hope that helps.

[Its_Azar]

Hi there @adityapitani 

The field-level ACLs are a good start, but they're usually not enough for highly sensitive data.

A common approach is to store sensitive information (and sensitive attachments) in a separate restricted table linked to the Incident or Request, protected by role-based ACLs. This provides better control over forms, reports, exports, APIs, and integrations.