OBLYTECH Logo
Enquire Now
OBLYTECH Logo

ServiceNow / Practical guide

ServiceNow Access Controls: A Practical Review Guide

ServiceNow access controls should make it possible for people to perform their work without giving every role a general view of the platform. The review starts with the work, not with a list of roles copied from a previous environment.

For ServiceNow administrators and service owners reviewing access without a broad default role model..

ServiceNow access controlsServiceNow rolesleast privilege
Discuss this ServiceNow topic

Guide map

Reviewing role assignments and access rules

Start with the work each role must perform

Write down the tasks each role has to finish, then grant only the access those tasks need, rather than starting from a broad default role.

Separate administration, approval, and execution

When one person can request, approve and carry out the same change, the review loses its value, so keep those roles in separate hands wherever possible.

Review exceptions as carefully as normal access

Every standing exception should carry an expiry date and a named approver, because temporary grants that never get reviewed become permanent by default.

The practical framework

Review ServiceNow access controls by mapping roles to work, separating administration from approval, checking exceptions, and recording ownership.

An access model is easier to maintain when each permission has a reason, an owner, and a review path. That applies to administrators, analysts, approvers, requesters, integration accounts, and temporary access.

Start with the work each role must perform

Describe the task before choosing the permission. An analyst may need to read and update incidents assigned to a group. An approver may need to make a decision without editing the underlying workflow. A service owner may need to review performance and ownership without changing platform configuration.

This framing reveals permissions that do not contribute to the task. It also prevents the team from using a role name as a substitute for a clear access decision. Where responsibilities differ, separate the roles even if the people sometimes overlap.

Separate administration, approval, and execution

The person who configures a workflow should not automatically be the person who approves its business outcome. The person who fulfils a request may not need access to every administrative setting. Separation does not require unnecessary complexity; it requires the model to show where a decision, change, or action could affect its own control.

Document the boundary in plain language. A review should be able to answer who can change the rule, who can approve the work, who can execute it, and who can inspect the record afterward.

The ServiceNow solutions page is the right internal commercial route when access decisions cut across IT, employee, and enterprise workflows.

Review exceptions as carefully as normal access

Temporary access, elevated troubleshooting, emergency changes, and integration permissions are common sources of drift. An exception should identify the reason, scope, owner, start condition, end condition, and evidence that it was removed or renewed.

Avoid treating an exception as a permanent role with a note attached. If the same exception is repeatedly renewed, the team should decide whether the underlying operating model needs redesign.

Connect access to the records it protects

Roles are only one part of the access review. Check which records a person can see, which fields they can change, which actions they can trigger, and which related data becomes visible through a relationship or report.

The review should include the user experience. A permission that appears correct in a role matrix may fail when a workflow reaches an approval, a notification contains a reference, or an integration account encounters a record it should not process.

The ServiceNow health checks and audits service provides the relevant route for a structured review of platform configuration and ownership.

Make access review a repeatable activity

An access review needs a defined population, reviewer, evidence source, decision options, exception route, and completion record. It should show what was reviewed and what changed. A report that says “reviewed” without a disposition cannot help the next reviewer understand the current state.

Review after meaningful change as well as on a schedule. New workflows, integrations, reorganised teams, and new data classes can change the risk of an existing role.

Common questions

Questions teams ask about ServiceNow access

Is a larger role easier to manage?

It may reduce the number of role assignments, but it can make ownership, testing, and review harder. A role should be as broad as the work requires and no broader by default.

What should an access review record?

Record the person or account, role or permission, business reason, reviewer, decision, exception details if any, and action required. Keep the evidence sufficient for a later reviewer to understand the decision.

The research-grounded boundary

Where one person holds two of those roles, the review should say so and decide whether the overlap is acceptable for that workflow. Typical cases are an administrator who also approves changes, or a fulfiller who can edit the approval rules. Record the decision next to the reviewer's name and the date, so a later reviewer can follow the reasoning without rebuilding it from role names.

Where access is actually decided on the platform

A review that looks only at role lists misses most of the places where access is granted or refused. On the platform, a person’s reach comes from several layers that interact: the roles held directly or through groups, the access rules attached to tables, fields and records, the scripts that run before a record is shown or saved, and the reports and related lists that can expose data indirectly. A role can look narrow in its name and still open a wide view if a rule below it is permissive. The reviewer needs to know which layer produced each outcome before deciding whether it is correct.

Control layerWhat it governsTypical review questionCommon surprise
Role grants through groupsWhich functions a person can open at allDoes this group need this role, or only part of what it bundles?A role containing other roles carries them in silently
Table and field access rulesWhich records and columns can be read or changed (see the access control list explainer)Does the rule check the role at the level where the data sits?A permissive rule on a parent table exposes child data
Record-level conditionsWhich rows a person sees within a tableAre conditions based on fields that users can edit themselves?A condition on an editable field lets a user widen their own view
Reports and listsWhich aggregated or related data is visibleCan a report show fields the person could not open on the record?Summaries can reveal values the record view hides
Integration accountsWhat automated processes can read or writeIs the account limited to the data its job needs?A service account built for one job accumulates roles over time

The practical lesson is that a review should name the layer behind every finding. A finding that says a user can see a value is incomplete until the reviewer knows whether the value came from the record, a related list, a report, or an API call.

Testing access as a standard user rather than reading the matrix

A role matrix describes intent. A test describes behavior. The strongest evidence in an access review comes from signing in as ordinary users in each population and attempting the tasks they are supposed to perform, along with the tasks they are not. Administrators who test with their own accounts often see more than the people they are supposed to represent, so the test needs accounts that carry only the access the population should hold. Where the populations are already set out in an access, privacy and segregation of duties design, the test list should be built from that design rather than from memory.

  1. Create or select a test identity for each population, using the same group memberships that production users receive. Do not use a copy of an administrator account.
  2. Write the tasks as a list before signing in: open the service, read the record, change the fields that belong to this role, attempt the fields that do not, and trigger the approval or closure action.
  3. Run the list in a non-production copy where possible, and record for each step what happened, what the record showed, and whether the outcome matched the intended access.
  4. Repeat the list from the reports and the list views, not only from the form, because the same data can appear in both places under different rules.
  5. Give every mismatch to the owner of the rule that produced it. Decide whether the rule, the group or the expectation is wrong before anyone changes anything.

This sequence exposes the drift that a matrix hides. A person who was moved to a new team last quarter may still belong to a group that opens a sensitive queue, and no role list will show that the group, not the role, is the source of the access.

Mistakes that make access reviews look complete while missing real exposure

Several patterns recur in reviews that pass their own checks and still leave exposure behind. The first is reviewing only the roles that were requested, not the roles that arrived through bundles. The second is accepting an exception because the requester has a good reason, without setting an end point that someone will check. The third is treating integration accounts as infrastructure rather than as users with reach, so their permissions are never part of the population being reviewed. The ServiceNow health checks and audits page covers assessing an instance for performance, security and opportunities for improvement, which is the wider context for these accounts.

  • Roles granted to a group that is itself nested in another group, so the effective access is larger than anyone wrote down.
  • Access rules that were written for a single use case and later applied to a wider population without being re-read.
  • Elevated roles kept on accounts after a project closes, because removing them was never added to the close-out checklist.
  • Reports shared broadly because their owner assumed the underlying records were restricted, when the summary itself exposes the values.

When a full access review is the wrong first move

A full review across every layer is expensive, and it is not always the right opening step. If the platform is about to be restructured, reviewing today’s access in detail may waste effort on rules that will be replaced. If a specific incident has shown that one population can see data it should not, the review should begin with that population and its rules, then widen only where the same pattern is likely. Reviews that try to cover everything at once usually finish with a long list of findings and no owner for any of them.

Should we remove standing elevated access and grant it only when needed?

Time-limited elevation is a sound pattern where the work is occasional and the approval is quick. It fails when the approval is a formality or when the elevation is never revoked. Decide which tasks truly need elevation, make the request route visible, and confirm that revocation happens without relying on memory.

How do we review access held by a team that changes often?

Review the group, not each person. Group membership changes are where access drift starts, so a review that checks which groups grant what, and who is responsible for each group, will catch more than a person-by-person sweep.

Does an access review need the platform owner present?

The platform owner should sign the rule decisions, but the business owner of each population should confirm the task list. Without the second signature, the review tests what the platform allows rather than what the business needs.

What evidence will satisfy an internal audit?

The evidence is the test list, the identity used, the observed result, the decision taken and the name of the person who accepted it. A screenshot of a role list on its own rarely answers the question an auditor is asking, which is whether the access works as intended for the person it was meant for.

Scoping an access review before testing starts

If the review has to cover several populations, integrations and reports, scoping them before the testing starts can save a round of rework.

Before the testing starts, contact OBLYTECH about the populations, integrations and reports in scope.

A practical next step

Need a clearer ServiceNow operating model?

OBLYTECH can discuss the questions raised by this guide and the next review step. See the ServiceNow consulting services page for the commercial route.

Useful starting pointBring the current question, scope, ownership concerns, and evidence needs into the first review conversation.

Review ServiceNow consulting

ServiceNow guides on this topic

Guides from the Oblytech ServiceNow library that explain the practice behind this page.

More from the blog

Related reading