Need-to-know Principle Implementation

[David Skowronek]

Table of Contents:

• Introduction
• Overview of ServiceNow data security capabilities
• How data security capabilities work together
• Limitations of Security Data Filters and ACLs
• Designing the need-to-know principle
• Implementation recommendations
• Practical example of implementation
• Summary and key take-aways

Introduction

This article has been updated to reflect the capabilities and best practices available with the ServiceNow Zurich release.

In today’s data-driven world, it is crucial to protect sensitive information while still enabling the right people to do their jobs effectively. The need-to-know principle, which is the practice of granting individuals access only to the data and functionalities they require, is an important security concept that helps ensure privacy and compliance.

Organizations often adopt this principle to meet regulatory requirements such as the General Data Protection Regulation (GDPR), Health Insurance Portability and Accountability Act (HIPAA), or the Digital Operational Resilience Act (DORA). These frameworks lay out rules on how data should be accessed, stored, and shared, encouraging clear security controls.

Another reason is building customer trust. When users know their data is handled securely, they have more confidence in an organization’s services. Lastly, internal policies and best practices also motivate the use of the need-to-know principle. By limiting access to only what employees truly need, companies can lower the risks of unauthorized changes, accidental disclosures, and general security threats within their ServiceNow environments.

However, organizations should approach need-to-know implementations with extreme caution. When need-to-know measures aren’t balanced properly, teams can lose access to essential data (causing business delays), while a poor implementation can degrade platform performance and increase maintenance overhead.

More importantly, even a “good” implementation introduces ongoing cost: it typically reduces upgradability (more upgrade conflicts and regression testing), weakens manageability (more rules to maintain, troubleshoot, and govern), and can impact performance (especially for list queries and high-volume users). For this reason, companies should implement need-to-know controls only when there is a very strong business reason - for example, a clear regulatory, contractual, or risk-based requirement that cannot be met with simpler, standard controls.

In this article, we will cover the following:

• Overview of ServiceNow data security capabilities that support the need-to-know principle
• How data security capabilities work together when a user attempts to access a record
• Limitations of Security Data Filters and Deny-unless / Allow-If ACLs, allowing partial data access under certain conditions
• Designing the need-to-know principle, including key considerations for planning access and associated risks
• Implementation recommendations to minimize performance, manageability and upgradability impact
• Practical example of implementation, leveraging Security Data Filters and Deny-unless ACLs

Next chapter: Overview of ServiceNow data security capabilities

[Shaji_Kalidasan]

Dear David,

Greetings,

Couldn't have said it any better or agreed more.

Thank you.

Sincerely,

Shaji Kalidasan

[SaschaWildgrube]

Thanks for that summary, David.

What we can take from it is: make sure you really need it before you go down that path and if you do, make sure you do things right.

Here is some specific guidance on how exactly to identify and document the requirements:

https://www.wildgrube.com/download/A%20mature%20Development%20and%20Deployment%20Process.pdf

Check out chapter "Persona Access Matrix" (page 105).

And for those who do not want to start an implementation from scratch but consider to build on top of a field tested app: Check out DataSilos:

https://www.wildgrube.com/servicenow-datasilos

Enjoy!

[Goran WitchDoc]

Wouldn't encryption be a way to make sure the data is secure from a need-to-know principle? Or that area is just to big to fit in here as well?

[David Skowronek]

Hi, @Goran WitchDoc . No, the column-level encryption is not designed for this purpose, and cannot be used:

- You need to have an encryption context assigned to the ticket, and the encryption context must be linked to a role; users having the role can see the data. As the record visibility usually depends on multiple attributes, and they changes, you would need billions of encryption contexts and roles to handle all possible combinations.

- The CLE encrypts the data, and because the data are encrypted in the database, you cannot filter / search based on such encrypted attributes

- The CLE supports only few data types

In general, CLE may be used if you have a single attribute, e.g. custom "Secret information" with data type String (4000) and you would like to encrypt it and ensure only few people can see it. Single attribute, never used for filters, with a static silo (static list of users independent on the record content).

[Goran WitchDoc]

I would disagree there, saying that you cant use encryption to handle certain requirements from e.g. GDPR etc. I also wouldn't look it from the view of how many data types it supports and more instead looks at for the data types it supports, how much does it cover of what is actually requires. And it's not only CLE, we got Edge as well. 

I would turn the question around. If it isn't for protecting sensitive information, what is the usage of encryption?

[SaschaWildgrube]

Encryption is a means to counter a series of attack vectors: Access elevation, intrusion and theft of physical assets, intrusion and theft on network and software level, etc.

Encryption is NOT capable in any form or shape to resolve line-of-sight restriction requirements (e.g. GDPR, contractual obligation, legal obligations, etc.) - as there will ALWAYS be people who have access and other who have not at the same time and these lines-of-sight restrictions need to be way more flexible than any secret key distribution and delegation can ever handle.

So choose the right tool for the right problem to solve.  

[Goran WitchDoc]

@SaschaWildgrube 

So if have a business requirement where some people needs to know the social security number that is embedded in a text in a string field and others shouldn't see it, how do I setup that with methods above? I'm not saying encryption is always the way to go, but I wouldn't put it as blank "NOT capable in any form" as you do.

[SaschaWildgrube]

1. You may have a GDPR-based obligation to encrypt social security numbers no matter what - so field level encryption may have to be applied to be GDPR-compliant

2. You will need to set up a e.g. a role based ACL to allow access to that particular encrypted field

That is a role based access control - that is users with that role can see more than users without the role.

I am referring to are line-of-sight restriction requirements:

That is a case where users with the exact same role assignment (same personas in that sense) may only see a subset of all incidents, CIs, tasks, whatever in a single table.

E.g. German fulfillers can only see incidents of German customers, Swiss fulfillers can only see incidents of Swiss customers - BUT sometimes individual tickets have to cross borders to be handled by specific teams or competence centers etc.

For the latter case, encryption cannot be the answer.

[Bruno De Graeve]

hi @David Skowronek 
First of all I want to share my compliments for writing this insightful document. When I was reading it some items and ideas popped-up which might or not be related and could be incorporated in your article.
Apply the "need-to-know" principle starts by defining the right permission groups and fine-grained role assignment. Unfortunately, for historical reasons, the "itil"-role has been used everywhere in our product while it is in my eyes a role that can easily break things and allows to fetch too much data you're supposed to see. As customer, you should step away from using the "itil" role. In 96% of the use cases it's possible and you can make use of combinations of fine-grained roles like sn_incident_write, sn_cmdb_read (both ITSM and CMDB areas released fine-grained roles.
Many customers have way too-many users with the "admin" role. Build a proper governance model and reduce the amount of admins.

In Prod, why would you need the impersonation ? Remove it as it opens doors and untracked actions.
Have you considered to apply Zero Touch Access (part of Vault).
When you clone your Prod instance to the subprods, have a governance model in place that defines which data can be copied over and which one should only remain in Prod.

Consider to apply the REST API ACL and grant only your integration users access to the Table APIs.

Load only the data you really need in your instance and have a blocking and deletion concept in place. Your DB keeps small, speedy and you don't risk to need pay more for additional storage.
I always learned to consider to combine BQBR with ACLs. It gives the opportunity to filter out data before it comes back to the client and enhances the UX by removing the message "Due to Security Constraints, x messages have been ...."
Using BQBR might speed up data retrieval as it reduces the payload and client-side filtering. But agreed, only using BQBR is not sufficient to protect your data.
Restrict the number of people that can make modifications to ACLs and regularly report and review on the customized ACLs.
Check the upgrade logs. Sometimes ACLs are changed, added or removed but due to customer customizations, they're ignored.

Some thoughts from my side 😉
regards, bruno

[David Skowronek]

Thanks for your comments, @Bruno De Graeve . Regarding the group and permission concept, this is the next article that is on my plan. No time plan for this yet, but soon 🙂

[Maik Skoddow]

Hi @David Skowronek 
the Data Filtration plugin has been set to "future deprecation" in the Yokohoma release and is now considered as "legacy".

[Daniel AC]

I just had a read-through of these articles. This is a truly excellent series of articles David and the recent updates will really help loads of customers and partners. Nice one!