Need-to-know Principle Implementation, part 5: Designing the need-to-know principle

[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

Designing the need-to-know principle

When consulting on the implementation of the need-to-know principle, the most common requirement sounds like this:

Users should see only those records they need to perform their duties.

Nothing more - just a single sentence. This requirement is very vague, and in many cases it allows a simple answer: no additional action is needed. The out-of-the-box ServiceNow security model, based on roles, already fulfills it. Users working with ITSM records can access ITSM data but not, for example, HRSD data. From this perspective, the requirement is technically met.

As discussions continue, customers often refine the requirement:

Yes, that is true, but we do not want people to see all tickets. They should see only their tickets and their data. They should stay within their service scope.

This is where the real challenge begins. What exactly is “my scope” or “my service” that a user should be restricted to? For end users, this question is usually easy to answer. For fulfillers (agents who work on tickets, such as Service Desk or resolver group members), it is often extremely difficult - or even impossible. “My scope” or “my service” typically varies per person and changes over time. It is also influenced by external factors, such as tickets assigned from another team or records that reference data the user would not normally be allowed to see.

Customers trying to implement the need-to-know principle often translate “my scope” or “my service” into a very strict rule:

Tickets assigned to me or to groups I am a member of.

This is a big leap - from a vague requirement directly to one of the most restrictive interpretations.

Let’s validate whether the “assigned to me or my groups” approach works in practice, using ITSM as an example:

• As part of a process, you create a new Incident task for another team. Based on this rule, the Incident task becomes invisible immediately after saving it. As a result, you may need to extend visibility to related Incident tasks.
• As part of your service, you support an application, while the database, operating system, or network is managed by other teams. If another team creates a Change for a Configuration Item your service depends on, that Change would not be visible to you - even if it has an immediate impact. Should you see only Changes that directly reference your managed Configuration Items, or also those that indirectly affect your service?
• Another team assigns you an Incident related to a Configuration Item that is not managed by any group you belong to. The security model prevents you from seeing details of that Configuration Item. Should you be able to see all data referenced by tickets assigned to you? This scope changes with every new assignment and update.

These are only a few examples, but they illustrate how fluid and context-dependent “my scope” or “my service” really is. In practice, it is almost impossible to define it fully and consistently.

The only scenario where “my scope” or “my service” can be defined in a strict and stable way is when a team delivers an end-to-end service, does not depend on other services, and never collaborates with other teams. This model works well in domains such as HRSD and CSM, where access can be cleanly segmented using case types. In contrast, it is uncommon in ITSM, where cross-team collaboration and shared ownership are the norm - and where the need-to-know principle is most frequently requested.

Know your requirements

As shown in the previous chapter, work on implementing the need-to-know principle often starts with a very vague requirement. This requirement is then quickly translated into a solution that appears easy and obvious - at least at first glance.

Before you start designing and implementing a large-scale solution that affects most or all fulfillers, take a step back and ask a few critical questions:

• Why are you doing this? Is there a clear and specific reason, or is the request based on a generic, single-sentence policy that applies to all systems?
• Does your current implementation already meet the stated policy? Answer this without inventing or assuming additional requirements.
• Can the desired outcome be achieved with a targeted solution instead of a global one?

A common trigger for global need-to-know initiatives is a security or compliance incident. For example, someone notices a ticket containing potentially sensitive information and reports it to corporate security or the workers council. As a reaction, the ServiceNow team is instructed to implement strict need-to-know controls to prevent similar situations in the future.

The key question at this point is whether a global implementation is really necessary, or whether a targeted solution would be more effective. Consider the following example.

Some IT fulfillers started browsing tickets assigned to other teams and discovered that certain incidents contained screenshots of driving licenses and other personal documents. These attachments were added by end users who requested access restoration and uploaded proof of identity through the Employee Center - even though a warning clearly stated that such documents should not be attached.

The fulfillers reported this to the workers council and corporate security, which then tasked the ServiceNow team with implementing the need-to-know principle.

What actually happened in this scenario?

• Fulfillers accessed tickets assigned to other groups and services.
• End users uploaded attachments that should not have been uploaded, even though the information was relevant to the service requested.

The immediate reaction is often to restrict all fulfillers to seeing only tickets assigned to their own groups. While this response may seem logical, it does not necessarily address the root cause.

In this case, there is a specific service, access restoration, that sometimes requires proof of identity. This naturally leads to the handling of personal or sensitive information. The real problem is not broad ticket visibility, but the lack of a mechanism to identify and protect tickets that contain sensitive data.

Within ITSM, such tickets typically represent only a small fraction of the overall ticket volume. For this reason, applying a targeted solution to these cases is usually more effective and far less risky than implementing a global restriction for all fulfillers.

Examples of targeted solutions include:

• Implementing a custom string field, such as “Confidential information”, with visibility restricted to the ticket creator and assignment group using Deny-unless ACLs. This field can be populated through Record Producers or by Service Desk agents when sensitive data is required.
• Implementing a custom checkbox, such as “Restricted visibility”, which—when set to true—limits visibility of the entire record to the ticket creator and assignment group using Deny-unless ACLs. This flag can be managed manually or determined automatically using GenAI to assess ticket content.

With such approaches, you can address the actual root cause while avoiding the complexity, performance impact, and operational risk of a global need-to-know implementation. Always try to identify a targeted solution first before considering a global one.

If a targeted solution is not sufficient and a global approach is truly required, continue with the next chapters of this article.

Risks of a global need-to-know implementation

Business Risks

If you decide to implement a global need-to-know solution, you must be aware that such an approach introduces significant risk. These risks are not technical at first - they are business risks that directly affect daily operations.

Risk 1: Over-restrictive access and operational blind spots

If access rules are defined too strictly, some records may become invisible to everyone who legitimately needs them. This can lead to business delays, reduced productivity, and even compliance issues when required information is not available at the right time.

A common root cause is the size of the silos you decide to create. Typical examples include rules such as:

• “Users may see only records from their organization”
• “Users may see only records assigned to them or to their groups”

If silos are very small and group membership is limited, the risk increases that records go unattended when key individuals are on vacation, sick, or unavailable. To compensate, organizations often introduce “power users” with broad access to monitor multiple silos. This approach is inefficient, difficult to scale, and contradicts the original goal of strict need-to-know.

Silo sizes must therefore be planned carefully to ensure continuity of operations and avoid situations where nobody is able to act on critical records.

Risk 2: Cross-silo exceptions and exploding complexity

The second business risk is a direct extension of the first. No matter how well data is segmented, there will always be cases where certain users must access records outside their primary silo - for example, to provide temporary support to another organization or service.

In practice, these exceptions are usually implemented using group memberships, where each silo has one or more groups that grant visibility. When silos become too granular, the number of exception groups grows quickly. This makes access logic hard to understand, difficult to maintain, and prone to errors.

Over time, the original security model becomes opaque: business stakeholders no longer know who can see what and why, which undermines trust in the platform and complicates audits.

Risk 3: Fragmented visibility of related data

The third business risk concerns what data you decide to protect. When access to foundational data is restricted, users may see a ticket but not the related user, service, or configuration item. Reference fields may appear empty, even though the data exists. This creates confusion and slows down resolution, as users cannot tell whether information is missing or simply hidden by security rules.

Such fragmented visibility significantly degrades the user experience and increases support effort, especially for fulfillers who rely on contextual data to do their work effectively.

Risk 4 (often underestimated): Business workarounds and shadow processes

An additional business risk - often underestimated - is the creation of workarounds. When users cannot access information they need, they will find alternative ways to get it: screenshots, emails, spreadsheets, chat messages, or parallel tools outside ServiceNow.

These shadow processes undermine both security and compliance, as sensitive data is copied, duplicated, and shared without proper controls. In the end, an overly strict global need-to-know implementation can increase risk instead of reducing it.

Technical Risks

In addition to business impact, a global need-to-know implementation introduces significant technical risks. These risks affect the long-term stability, performance, and maintainability of the ServiceNow platform and are often underestimated during initial design.

Risk 1: Performance degradation

Global need-to-know implementations typically rely on Security Data Filters, Deny-unless ACLs, or a combination of both. These mechanisms add additional conditions to nearly every query executed against protected tables.

On high-volume tables such as Task, Incident, or large CMDB tables, even simple filter logic can noticeably increase query execution time. More complex conditions - especially those involving group membership, reference traversal, or scripted logic - can significantly degrade list loading, reporting, and API response times.

Performance issues introduced by security logic are particularly difficult to troubleshoot, as they affect all users and are often mistaken for general platform slowness.

Risk 2: Reduced upgradeability

Global need-to-know solutions almost always require customization of core security logic. This includes custom ACLs, Security Data Filters, scripted conditions, and sometimes custom attributes added to baseline tables.

Each customization increases the risk of upgrade conflicts and regression issues during ServiceNow upgrades. Even when conflicts are resolved cleanly, extensive regression testing is required to ensure that access rules still behave as intended across all use cases.

Over time, this reduces the organization’s ability to adopt new platform features quickly and safely.

Risk 3: Increased maintenance complexity

Once implemented, global access restrictions require continuous maintenance:

• Changes in team structure require updates to groups and exception logic.
• New services or processes must be integrated into the security model.
• Troubleshooting access issues becomes more time-consuming, as multiple security layers must be analyzed.

As complexity grows, fewer people fully understand the security design, increasing dependency on a small number of experts and creating operational risk.

Risk 4: Reporting, integrations, and automation side effects

Need-to-know implementations often have unintended side effects on:

• Reports and dashboards (missing or inconsistent data)
• Integrations and APIs (unexpected empty responses)
• Automations and workflows (records not found or conditions not met)

Because these components rely on queries executed in different contexts, security logic may behave differently than expected. Fixing such issues often requires additional exceptions, further increasing complexity.

Risk 5: Difficult testing and validation

Testing a global need-to-know solution is inherently difficult. You must validate access behavior across:

• multiple roles and groups,
• direct and indirect data access paths,
• lists, forms, reports, exports, and APIs.

Edge cases are easy to miss, and errors often surface only in production under real-world conditions. This increases the risk of both overexposure and overrestriction.

Key Takeaways: Business and Technical Risks

Do not implement a global need-to-know solution based on vague or generic requirements.

Always validate the concrete business, legal, or regulatory driver before introducing platform-wide restrictions.

Do try targeted solutions first.

When sensitive data exists only in specific scenarios, a focused approach is almost always safer, cheaper, and easier to maintain.

Do implement a global need-to-know solution only when there is a strong, explicit business requirement and clear ownership.

Without long-term commitment to maintaining complexity, the risks will outweigh the benefits.

Do not assume stricter access automatically means lower risk.

Over-restrictive designs often create operational blind spots, delays, and workarounds that increase overall business risk.

Do carefully evaluate silo size and exception handling.

Small silos and numerous cross-silo exceptions quickly lead to unmanageable access models and dependency on “power users.”

Do not hide foundation data or CMDB records entirely without a clear strategy.

Completely restricting access to these records leads to broken references, user confusion, and slower resolution. In most cases, it is better to allow visibility of basic attributes (such as name or identifier) while restricting access to more sensitive details. This preserves context and prevents “invisible reference” scenarios.

Do expect performance impact when applying global Security Data Filters or complex ACL logic.

Test on high-volume tables and validate real-world performance, not just functional behavior.

Do not underestimate upgrade and maintenance costs.

Every custom security rule increases regression testing effort and reduces the ability to adopt new ServiceNow features.

Do design for reporting, integrations, and automation from day one.

Global need-to-know rules often break non-interactive access paths if they are not explicitly tested and accounted for.

Next chapter: Implementation recommendations