Need-to-know Principle Implementation, part 7: Practical example of 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

Practical example of implementation

This chapter focuses on showcasing a possible implementation of the need-to-know principle, and covers the following points:

• Defining the silo
• Defining cross-silo exceptions
• Implementing Security Data Filters and Deny-unless ACLs
• Protecting the foundation data and CMDB

Defining the Silo

Defining the attribute used to represent a silo is the most important design decision in a need-to-know implementation. This choice directly influences not only the security model itself, but also performance, usability, and long-term maintainability.

As explained earlier, silos should be as large as possible while still meeting the security objective. Silos that are too small increase the risk of business disruption, such as invisible tickets, missing references, and excessive cross-silo exceptions. For this reason, attributes such as assignment group are generally not recommended for defining silos.

The need-to-know principle is most often requested in large enterprises that consist of several largely independent companies or divisions. In such environments, organization-related attributes are commonly considered for silo definition.

Typical candidates include:

• company,
• division,
• department,
• organizational unit.

When choosing between these options, one factor is critical: stability over time.

A security model is not built for the next year only. Organizational structures change frequently and sometimes abruptly. Departments and organizational units are often restructured, merged, or split, which makes them poor candidates for long-term security boundaries.

In practice, Company or a large, stable division is usually the best choice. These attributes tend to change infrequently, and when they do, changes are often limited to renaming rather than structural redefinition.

Equally important is that the silo attribute is explicit and single-valued. Every user should belong to exactly one silo by default, defined by a single attribute such as a reference or choice field. Avoid deriving silos through complex logic or combinations of attributes.

Checklist for a good silo attribute

A well-chosen silo attribute should meet the following criteria:

• The silo is large enough to avoid business issues described earlier in this article (such as invisible records or excessive exceptions).
• The silo attribute is stable over time.
• The silo attribute can be used across all in-scope processes.
• The silo is clearly defined by a single attribute, ideally a choice list or reference field.
• Every user has exactly one silo by default, without requiring additional logic.
• The vast majority of users remain within their own silo and do not require cross-silo exceptions.
• Only a small number of users require cross-silo access, and the number of exceptions per user is low (ideally fewer than five).

Defining cross-silo exceptions

Let’s assume, based on the previous section, that Company has been selected as the attribute defining the silo. As explained earlier in this article, an effective mechanism for cross-silo exceptions is essential for any global need-to-know implementation.

Cross-silo access is inherently dynamic. A user always belongs to one primary company but may also require visibility into one or more additional companies. From a technical perspective, this means that both Security Data Filters and Deny-unless ACLs must support dynamic evaluation of a user’s allowed silos.

Dynamic evaluation of allowed silos

In ServiceNow, dynamic filters are commonly used to resolve such scenarios. A well-known example is “One of My Groups”, which returns a comma-separated list of groups the logged-in user belongs to.

In a company-based silo model, your Security Data Filters and Deny-unless ACLs would typically use a condition similar to:

Company IS (DYNAMIC) One of My Companies

Here, “One of My Companies”  is a custom dynamic filter that returns:

• the user’s primary company, and
• all additional companies for which the user has an approved cross-silo exception.

Performance considerations

As discussed earlier, every Security Data Filter must be underpinned by Deny-unless ACLs. For ACLs, performance is critical, because each ACL is evaluated for every record displayed.

For this reason, the dynamic filter “One of My Companies” must be implemented in a way that:

• returns all allowed companies using a single, highly optimized query, and
• avoids additional per-record or per-condition database lookups.

Achieving this requires a custom implementation. While this introduces customization, such customization is expected - and unavoidable - when implementing a global need-to-know principle.

Recommended data model for exceptions

A practical and scalable approach is to introduce a custom many-to-many table between:

• User (sys_user), and
• Company (core_company).

This table should represent all companies a user is allowed to see.

Key implementation points:

• The many-to-many table should be visible as a related list on the User record.
• A Business Rule should automatically insert the user’s primary company (from User.Company) into the many-to-many table.
• If the user’s primary company changes, the Business Rule should remove the old entry and add the new one.
• Cross-silo exceptions are managed by adding additional companies to this table.

Because the primary company is always present, retrieving the full list of allowed companies for a user can be done using a single query, which is ideal for both Security Data Filters and Deny-unless ACLs.

Auditability and governance

While this data model is technically sufficient, it may not be adequate from an audit and governance perspective. By itself, it does not explain why an exception was granted, who approved it, or how long it should remain active.

To address this, it is recommended to manage cross-silo exceptions through a Catalog Item, including:

• a defined approval flow,
• automated provisioning and de-provisioning logic.

For traceability, extend the many-to-many table with an additional reference field to the Requested Item (sc_req_item) that granted the exception. This provides a clear audit trail linking each exception to its approval and request context.

Optional recommendation: time-bound exceptions

As an optional improvement, consider making cross-silo exceptions time-bound. Temporary access reduces long-term risk and helps keep the exception set small and manageable. Automation flows can revoke access automatically when an approval expires, preventing silent accumulation of privileges over time.

Final step: dynamic filter implementation

With this model in place, you can now implement the custom dynamic filter “One of My Companies”, which returns a comma-separated list of sys_id values for all companies the user is allowed to see.

This dynamic filter becomes the single source of truth for:

• Security Data Filters, and
• Deny-unless ACLs,

ensuring consistent behavior, predictable performance, and transparent exception handling.

Implementing Security Data Filters and Deny-unless ACLs

Before implementing Security Data Filters or Deny-unless ACLs, it is critical to precisely define your business logic. As emphasized earlier in this article, you must consider all stakeholders that interact with the process or table you intend to protect.

Typical stakeholders include:

• End users, who should be able to see tickets they submitted
• Fulfillers or business stakeholders, who should typically remain within their own silo
• Fulfillers or business stakeholders with extended visibility, who are allowed to access additional silos
• Power users, who usually need unrestricted visibility
• Admins and system accounts, which should typically see all records

The goal of this analysis is to determine which stakeholders security restrictions should apply to. In most cases, restrictions should apply only to fulfillers or business stakeholders. End users usually interact with data through portals such as Employee Center and do not have backend access. Power users, administrators, and system accounts should typically be excluded from need-to-know restrictions to avoid operational and support issues.

These assumptions and exclusions should be made explicit early in the design. Clearly documenting which roles are restricted, which are excluded, and why, prevents misunderstandings later and avoids security logic becoming implicit or “tribal knowledge.”

Using Security Attributes to scope enforcement

The most efficient way to control when security restrictions apply is by using Security Attributes (sys_security_attribute).

For example, when protecting the Incident table, you might implement the following approach:

• Create a custom role, for example itil_power_user, and assign it to all fulfillers and business stakeholders who require unrestricted visibility.
• Create a custom Security Attribute, for example ApplyDataSegmentationIncident, with the following configuration:
• Type: compound
• Is dynamic: true
• Condition:
• Has admin role is false, and
• Role is itil or business_stakeholder, and
• Role is not itil_power_user, and
• Interactive session is true

This configuration ensures that the Security Attribute evaluates to true only for interactive users with operational roles, while excluding administrators and power users.

You can then reuse this Security Attribute consistently in:

• Security Data Filters, and
• Deny-unless ACLs,

together with the custom dynamic filter “One of My Companies” described earlier.

Using the same object to define when security applies (Security Attribute) and the same object to define what access is allowed (Dynamic Filter) significantly improves consistency, readability, and long-term manageability of the solution. It also makes future changes easier, as adjustments to scope or access logic are centralized.

Validate edge cases early

Even a well-structured design can expose edge cases that must be evaluated carefully. Common examples include:

• Watch lists: Can users be added to the watch list of a ticket belonging to another company, and should that imply visibility?
• Dual-role users: Fulfillers can also be end users. If they submit requests, how is the silo determined? Is it derived from the user record, or from a service offering or other context? Incorrect assumptions can make tickets invisible to the fulfiller.
• Approvals: Can users approve records (for example, Change Requests) that belong to another company or silo?

These scenarios should be discussed and documented explicitly. If an edge case is intentionally not supported, that decision should be clear and agreed upon by business stakeholders.

When Security Data Filters are not sufficient

In some cases, business logic becomes too complex to be fully implemented using Security Data Filters. As discussed earlier, filters must remain highly optimized, and not all scenarios can be expressed efficiently at the database-query level.

In such situations, it is acceptable - and often recommended - to apply Security Data Filters only partially, following the 80/20 approach, and handle the remaining complexity using Deny-unless ACLs.

There are also cases where Security Data Filters cannot be used at all, and Deny-unless ACLs become the only viable option.

Re-evaluate before going “ACL-only”

If your design requires that all logic is implemented exclusively through Deny-unless ACLs, this is a strong signal to pause and reassess:

• Is the business logic clearly defined and consistently applied?
• Is the chosen silo attribute still appropriate?
• Is there a strong and explicit business reason to accept the resulting performance, manageability, and upgrade risks?

An ACL-only solution for a global need-to-know implementation almost always leads to higher complexity, reduced performance, and long-term maintenance challenges.

Protecting foundation data and the CMDB

While it is reasonable to restrict access to entire ticket records using Security Data Filters or record-level Deny-unless ACLs, applying the same approach to foundation data or the CMDB requires special caution - and in many cases, may not be necessary at all.

A single record, such as an Incident, typically contains multiple references - to users, services, configuration items, and other foundational data. If you cannot guarantee that all referenced records always belong to the same silo (for example, Company), strict record-level restrictions can severely disrupt business processes. Users may be able to see a ticket but not the information required to understand or resolve it.

In the case of the CMDB, the impact can be even greater. Configuration Items are inherently interconnected and often shared across services and organizations. Hiding entire CI records can break dependency chains and make impact analysis and troubleshooting extremely difficult.

For this reason, before designing any access restrictions for foundation data or the CMDB, you should first explicitly assess whether these data sets need to be protected at all. In many implementations, the primary sensitivity lies in the ticket content itself, not in the referenced services or configuration items. Applying need-to-know controls indiscriminately to foundation data often introduces more risk than it mitigates.

If protection of foundation data or CMDB records is required, do not hide entire records using Security Data Filters or record-level Deny-unless ACLs. At a minimum, the display value of each record should remain visible. In addition, key operational attributes - such as Support group, Managed by, or similar ownership fields - should also be visible so users know who to contact when access to additional details is restricted.

Recommended ACL pattern for foundation data and CMDB

A safer and more predictable approach is to restrict attributes, not records.

You can implement this pattern as follows:

• Create a single Deny-unless ACL for the read operation that applies to all attributes of the table (<table_name>.*).
• In the conditions of this ACL, use the custom dynamic filter “One of My Companies” described earlier. This keeps the business logic centralized and consistent with the ticket-level implementation.

This ACL establishes a secure default: unless a more specific field-level ACL explicitly allows access, the attribute is hidden. Because this is a single ACL applied to all attributes, it is evaluated only once per record, minimizing performance impact.

Next, explicitly allow visibility for selected attributes that should always be visible, such as Name, Support group, or Managed by:

• Create a Deny-unless ACL for the read operation on each selected attribute (for example, <table_name>.name).
• In these ACLs, reuse the same role-based conditions that are already present in the corresponding Allow-if ACLs.
• Because ACLs based on roles are cached by the platform, this approach does not introduce additional SQL queries.

This layered model ensures that:

• sensitive details are protected when required,
• essential context remains available,
• and users are not faced with broken or empty references.

Next chapter: Summary and key take-aways