Need-to-know Principle Implementation, part 6: Implementation recommendations

[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

Implementation recommendations

This chapter provides technical recommendations for implementing the need-to-know principle using Security Data Filters and Deny-unless / Allow-if ACLs, with a focus on reducing the risks outlined in earlier chapters. The content assumes a strong technical foundation and is aimed at implementers (developers) with hands-on platform experience.

Before looking at practical examples on how to implement the need-to-know principles, let’s first look at the key features, how they work and some of the best practices for their implementation.

Security Data Filters

As described earlier, Security Data Filters enhance database queries by adding additional conditions at execution time. Because they operate at the database layer, an incorrect design can have a significant impact on performance, usability, and overall platform stability. The following best practices help reduce these risks.

Design with all user types in mind

Always consider all users and access paths that interact with the protected table - not only fulfillers.

For example, applying a Security Data Filter to the Incident table that restricts visibility to “assigned to me or my groups” may unintentionally prevent an end user from seeing an Incident they submitted. Security Data Filters apply globally, including to portals, reports, exports, and APIs.

Before enabling a filter, explicitly validate how it affects:

• end users,
• fulfillers,
• reporting users,
• integrations and background processes.

Avoid expensive operators

Do not use CONTAINS, LIKE, or similar non-index-friendly operators in Security Data Filters. These operators typically prevent efficient index usage and can significantly degrade query performance, especially on high-volume tables.

Prefer exact matches or indexed comparisons whenever possible.

Do not try to solve every scenario with Security Data Filters

Security Data Filters are best suited for simple, high-impact conditions. Follow an 80/20 approach:

• Use Security Data Filters to cover the “easy” 80% of scenarios that can be expressed with simple, performant conditions.
• Handle the remaining “complex” 20% using Deny-unless / Allow-if ACLs, where more advanced logic is unavoidable.

Avoid building large, complex filters with many conditions. Keep filters readable, predictable, and easy to reason about.

Analyze the generated SQL and indexing strategy

Always analyze the final query produced by Security Data Filters, for example by using Debug SQL. Ensure that:

• filter conditions align with existing indexes,
• frequently used access paths are covered by appropriate indexes,
• composite (multi-column) indexes are added where justified.

You can often derive the most important queries from:

• application menu filters,
• reference qualifiers,
• commonly used reports and dashboards.

Test with production-like data volumes

Never validate Security Data Filters only on small datasets. Always test with large data volumes, ideally in a full clone of the production instance. This is the only reliable way to assess the real performance impact when filters are applied to every record in a table.

Always pair Security Data Filters with ACLs

Security Data Filters do not replace ACLs. Always create corresponding Deny-unless / Allow-if ACLs that enforce the same business logic. This ensures:

• consistent behavior across all access paths,
• protection against indirect access scenarios,
• clearer separation of responsibilities between database-level filtering and application-level authorization.

Limit the number of filtered tables

Apply Security Data Filters only to tables where they are strictly necessary. Each additional protected table increases:

• query overhead,
• testing effort,
• upgrade and troubleshooting complexity.

Avoid enabling Security Data Filters “just in case.” Start with the smallest possible scope and expand only when there is a proven need.

Deny-unless ACLs

While Security Data Filters are evaluated once per database query (potentially returning many records), ACLs are evaluated per record. This difference is critical from a performance perspective. If a list view displays:

• 20 records per page, ACL conditions are evaluated 20 times.
• 100 records per page, ACL conditions are evaluated 100 times.

When multiple Deny-unless ACLs apply to the same record, all of them must be evaluated successfully for access to be granted. As a result, poorly designed ACL logic can quickly multiply database activity and degrade performance.

Understand the baseline query cost

Even without custom ACL logic, loading records already generates a significant number of SQL queries. For example, in a personal ServiceNow instance:

• Loading 20 Incident records generated 29 SQL queries
• Loading 50 Incident records generated 56 SQL queries
• Loading 100 Incident records generated 73 SQL queries

For simplicity, you can assume that the number of SQL queries roughly scales with the number of records displayed. In other words, loading 100 records often means roughly 100 queries. Any additional SQL query introduced by ACL logic multiplies this baseline cost.

Be aware of hidden SQL queries

Additional SQL queries are not always obvious at first glance. They can be triggered by:

• Security attribute conditions
• Dynamic filters
• Script conditions
• Dot-walking in record-level or field-level ACLs

For this reason, every Deny-unless ACL must be reviewed carefully with a performance mindset. Always assume that seemingly simple logic may translate into additional database calls.

Limit list sizes deliberately

To reduce performance impact:

• Limit maximum list size to 50 or 100 records.
• Set 20 records per page as the default.

In practice, a single, well-optimized SQL query inside a Deny-unless ACL - combined with a list size of 50 records - rarely causes noticeable performance degradation for end users.

Combine Deny-unless ACLs with Security Data Filters

Whenever possible, use Security Data Filters to pre-filter the record set before Deny-unless ACLs are evaluated.

This has two important benefits:

• Closing edge cases: Security Data Filters enforce record visibility directly at the database level, reducing scenarios where ACLs alone allow partial visibility (for example, aggregated queries).
• Improving user experience: By preventing out-of-scope records from being returned at all, users no longer see the message “Number of rows removed from this list by security constraints”.

From a design perspective, this means:

• Use Security Data Filters to eliminate records users should never see.
• Use Deny-unless ACLs to validate business reasons for accessing records that are already in scope.
• Keep Allow-if ACLs focused on baseline permissions.

This layered approach not only improves security and manageability, but also results in cleaner lists, faster rendering, and a more predictable user experience.

Next chapter: Practical example of implementation