How do you handle confidential data, such as SSNs, on task-based tables like Incident?

[andrew_lawlor]

How do you handle confidential data, such as SSNs, on task-based tables like Incident? Specifically, how do you manage access to confidential fields when multiple teams might need to access the data?

I've had some customer requests for maintaining confidential information - so I wanted to seek the feedback of community members before designing anything.

Thanks,

Andrew

[Uncle Rob]

Access controls AND encryption

With Access Controls, you're most concerned with restricting read rights to that field for everyone but a very specific role.   But that's only scratching the surface.   That you have SSNs in your instance at all is a risk.   What if your instance gets hacked?

For that reason you should explore encryption as an option.   That will ensure the data is encrypted both in-flight and at rest.   ServiceNow recently announced the release of its Edge Encryption product, but that appears to be fairly limited to me as it doesn't appear to handle variable encryption (which will be essential if you have SSN's as part of a Self Service experience).   If you only deal with SSN's   in the full non-catalog interface then Edge Encryption might be suitable for you.

Encryption on ServiceNow is a complex beast, but you owe it to the humans you interact with if you're going to put their confidential information on a cloud platform.   I'd suggest reading my two part blog series on engaging Encryption vendors in the ServiceNow space.

Encryption: How not to get $#%&ed

Encryption: How not to get $#%&ed Part 2

[Mike Allen]

If it were me, I would add a new field for the confidential data using Encrypted Fields: Encryption Support - ServiceNow Wiki

Then give the encryption context to a specific role and have the role given to the people who need it.   Anyone without that role won't even know the field exists.

[Manuchao]

your wiki link not working