Need-to-know Principle Implementation, part 2: Overview of ServiceNow data security capabilities

[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

Overview of ServiceNow Data Security Capabilities

There are five platform-wide solutions that can help secure data:

• Multi-instance architecture
• Domain Separation
• Security Data Filters
• Deny-unless ACLs
• Allow-if ACLs

Note: Data filtration is no longer available for activation on new instances, while existing customers may still use it.

Multi-instance Architecture

Multi-instance architecture provides physical data segregation across multiple ServiceNow instances or external systems. It is particularly useful for storing highly sensitive data, such as personal information, in a separate environment. In this setup, you can fetch the necessary data into ServiceNow via Remote tables, ensuring the information remains in memory only and is never permanently stored in the ServiceNow database.

This approach suits scenarios where you merely need to display sensitive data (e.g., personal details) from an external system without involving it in automated workflows or storing it within ServiceNow. By segregating data physically, you can maintain stricter controls over who has access to it and reduce the risk of unauthorized exposure.

Domain Separation

Domain Separation provides logical data segregation within a single ServiceNow database by dividing data into separate silos (Domains). It was originally designed for Managed Service Providers (MSPs) that need strict boundaries between different client environments.

However, Domain Separation introduces significant complexities for most enterprises, such as cross-domain visibility challenges, cumbersome administration, and specialized skill requirements. It is strongly discouraged in typical enterprise scenarios. Instead, organizations should leverage the other solutions discussed in this article - such as Security Data Filters or ACL-based configurations - to achieve secure data segmentation without the overhead and limitations of Domain Separation.

If Domain Separation is absolutely necessary for your MSP use case, it should be the first plugin enabled on a newly provisioned instance to avoid conflicts and ensure proper configuration from the start.

Security Data Filters

Security Data Filters are a platform feature that helps you restrict which records a user can retrieve, no matter how the data is accessed. The key idea is simple: the filter is applied before the database query is executed, so restricted records are never returned by the query in the first place.

In practice, Security Data Filters act as an additional “record visibility gate” on top of your existing security model. Access Control rules (ACLs) remain important, but Security Data Filters help ensure that out-of-scope records do not appear in the result set at all.

A key limitation is that Security Data Filters operate very close to the query engine. This means a poor design can create broad side effects: missing records in lists and reports, unexpected integration results, and measurable performance impact (slower queries and page loads).

Data Filtration

Data Filtration provides application-layer data segregation on top of your existing Access Control rules (ACLs). It selectively denies access to tables and records that do not match certain subject attributes, which an administrator defines (for example, a user’s role or group membership).

Starting with the Yokohama release, Data Filtration has been prepared for future deprecation: it is hidden and no longer available for activation on new instances, while existing customers may still encounter it in legacy implementations. Security Data Filters are the successor feature and should be used for new designs. Therefore, this article does not use Data Filtration as an implementation option.

Deny-unless ACLs

Deny-unless ACLs provide application-layer data segregation and were introduced in the Xanadu release as an extension of the pre-Xanadu ACL model. Unlike pre-Xanadu ACLs and Allow-if ACLs, where access is granted if ANY matching ACL condition is met, Deny-unless ACLs deny access unless ALL defined Deny-unless ACLs (and all their criteria) are satisfied.

This reversed logic can offer more granular control, but it also requires careful planning to avoid unintentionally blocking users from data they need. When used correctly, Deny-unless ACLs can help ensure that only the right individuals have access to sensitive information.

Allow-if ACLs

Allow-if ACLs provide application-layer data segregation and were introduced in the Xanadu release. As part of this release, all existing ACLs were automatically converted to Allow-if ACLs without any impact on functionality. Their behavior matches that of pre-Xanadu ACLs, meaning that if ANY matching ACL condition is satisfied, access is granted.

This straightforward approach works well for most use cases, as it maintains the familiar access logic that many administrators are already comfortable with.

Summary

In addition to the five security solutions discussed, certain ServiceNow products - such as Strategic Portfolio Management - offer their own built-in data segmentation features. However, because these solutions are product-specific, they are not covered in this article.

IMPORTANT: before-query Business Rules are not a reliable solution for enforcing data security, as they can be bypassed and do not provide the same level of control as the security measures outlined above.

Next chapter: How data security capabilities work together

[Bruno De Graeve]

hi @David Skowronek , it would be great if would go a bit deeper in providing the WHY or share an example. For instance, BQBR can be used but should be accompanied by an ACL. The reason why BQBR should not be used stand-alone is that via reporting, you can get access to data that is not intended. I remember you have a nice example where you can see ticket data, via an m2m cmdb-task table.
For the Deny-Unless ACLs; which would be a great example where we demonstrate more granular control ? Maybe explain that the detailed examples are provided by the other articles.

Last but not least, would it be an idea to highlight the Access Analyzer ? That's a great diagnostic tool to check and verify why you or somebody else have access or not to certain data.