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
How data security capabilities work together
In this chapter, we will focus on three core security methods introduced earlier:
- Security Data Filters
- Deny-unless ACLs
- Allow-if ACLs
These methods can work together to enforce a strong need-to-know model. Here is how the process typically unfolds when a user attempts to access a record:
- Query execution with Security Data Filters
- If one or more matching Security Data Filters exist for the target table, the platform enhances the database query with additional conditions from the filter definition.
- Only the filtered result set is returned for further security evaluation.
- Deny-unless ACL Check
- If one or more Deny-unless ACLs exist for this record, all of them must match for the user to proceed.
- If any Deny-unless ACL fails to match, access is denied, and the process stops.
- If no Deny-unless ACLs apply, or if they all match, the process continues.
- Allow-if ACL Check
- If an Allow-if ACL condition is satisfied, access is granted.
- If no Allow-if ACL condition is met, access is denied.
By combining these methods, you can ensure that users only gain access to the data they legitimately need, without risking overexposure or unnecessary restrictions.
Example: A Military Base
Imagine a military base. As you approach it, you may see multiple signs: “Authorized personnel only,” “Restricted area,” and similar warnings. Before you can enter the base, you must pass a security checkpoint where guards validate whether you are allowed to proceed. Once you pass the checkpoint, you enter the base, which usually consists of multiple buildings. Each building has its own key.
A key to enter a building represents an Allow-if ACL: you are permitted to access that building.
But having a key is not always enough. Do you also have a valid reason to enter? Aren’t you coming at night when you usually work only during the day? That is the job of guards at a security checkpoint - Deny-unless ACLs: they verify the reason for access and block entry unless the conditions are met.
And what about Security Data Filters? Those are the signs and barriers you see before you even reach the checkpoint. They restrict who is allowed to approach the checkpoint at all, filtering out most people before any detailed validation happens.
In the past, you often had only one option: customizing the (Allow-if) ACLs to perform all three functions: filter people without access, validate the reason for entry, and validate the “key.”
With Security Data Filters and Deny-unless ACLs, you can build a layered security model that greatly limits - or even avoids - customizing baseline Allow-if ACLs.
By placing these layers around the base, you ensure that only people who are expected to approach the gate (Security Data Filters), who have a valid reason to enter (Deny-unless ACLs), and who have the right key (baseline Allow-if ACLs) are granted access. This creates a more flexible, yet secure environment that mirrors the need-to-know principle described in this article.
This approach has several advantages:
- Fewer customizations: You keep the core ServiceNow ACL logic intact.
- Centralized control: You can apply consistent record access rules in a small number of places.
- Reduced upgrade risk: ServiceNow typically does not ship Security Data Filters by default, and record-level Deny-unless ACLs are rarely used out of the box, so your customizations are less likely to conflict with baseline behavior during upgrades.
Next chapter: Limitations of Security Data Filters and ACLs
