OBLYTECH Logo
Enquire Now
OBLYTECH Logo

ServiceNow / Practical guide

ServiceNow Access Recertification: Make Retain Decisions Clear

ServiceNow access recertification should produce a defensible decision about whether access remains necessary, should be removed, or needs investigation. Reviewers need the population, role, business need, owner, evidence, exception path, action, and review date.

For ServiceNow security and platform owners running recurring access recertification decisions..

ServiceNow access recertificationaccess certificationentitlement review
Discuss this ServiceNow topic

Guide map

Turn recertification into a repeatable review.

Define the population and access decision

Decide the population and the four outcomes before any reviewer sees the list.

Give reviewers useful context

Each decision needs a recorded reason, a named authority and an action owner.

Record retain, remove, and investigate decisions

Fix the list of accounts in scope and the allowed outcomes first, so every entry is judged against the same rule before review starts.

The practical framework

Run ServiceNow access recertification with population, role, business need, owner, evidence, retain or remove decision, exception, and review date.

Define the population and access decision

State identities, groups, roles, applications, privileged actions, data, and period in scope. Define retain, remove, investigate, and exception outcomes before the review begins.

The ServiceNow access-controls route is the relevant internal destination when access decisions need evidence.

Give reviewers useful context

Show current role, business responsibility, service or data boundary, last relevant activity where available, manager or owner, approval, and inherited access. Context should support a decision without exposing information the reviewer does not need.

The ServiceNow identity-integration route provides an internal path when identity lifecycle affects the review.

Record retain, remove, and investigate decisions

Capture the decision, reason, reviewer, authority, time, affected access, and action owner. A retain decision should explain the current need; a remove decision should identify how it will be verified.

The ServiceNow audit-evidence route supports decision evidence.

Handle non-response and exceptions

Define what happens when a reviewer does not respond, the owner is unavailable, access is shared, or the need is disputed. Record exception scope, reason, compensating action, owner, expiry, and next review.

The ServiceNow process-automation route is relevant when review and escalation need workflow.

Verify actions and improve the next cycle

Check removal, retained access, unresolved records, wrong owners, and recurring exceptions. Use evidence to improve the population, context, notification, authority, and closure rules for the next review.

The ServiceNow continuous-improvement route gives an internal path for improvement.

Common questions

Questions teams ask about recertification

Is a reviewer’s approval enough?

It is one part of the decision. The record should show what access was reviewed, why it was retained or removed, who had authority, and what verification followed.

What should happen after non-response?

Apply the defined escalation or restriction rule, record the evidence and owner, and avoid silently treating silence as approval unless the governed process explicitly says so.

The research-grounded boundary

The useful principle is to decide what the record or workflow must prove before deciding what the platform should automate. Applied to access recertification, the boundary is useful only if a later reviewer can see what was allowed, what occurred, and what remains open.

Scoping the first recertification around privileged access

A recertification campaign that covers every user on the platform is often a campaign that nobody finishes. The better starting point is the access that can change the platform itself, the access that reads sensitive records, and the access held by people whose role has changed since it was granted. Administrative roles, security roles, roles that can edit workflows or scripts, and roles that expose personal data should be in the first wave. Standard end-user access can follow once the reviewers have learned how a decision is recorded.

Scope has to be written down before the campaign opens. State which identities, groups, roles, applications and data sets are included, which period of activity is considered, and which access is out of scope because another control covers it. A reviewer who receives a list without a stated boundary will either approve everything to be finished or ask questions that the owner cannot answer. Both outcomes weaken the record.

Deciding which population to review and in what order

Group the population by the consequence of getting it wrong rather than by department. An administrator who can change access controls is a different review from a requester who can see their own tickets. The first group should be reviewed by someone who understands the platform configuration, and the second by a line manager who knows the work. Mixing the two in one reviewer’s queue produces fatigue, and fatigue produces approvals.

A sequence reviewers can finish without guessing

  1. Export the current role assignments for the scoped population, including roles inherited through groups, and mark any assignment that has no named business owner.
  2. Assign a reviewer to each group of access by business responsibility, not by who happens to be available that week.
  3. Give each reviewer the context needed for the decision: current role, the service or data boundary it touches, the owner, the approval on file and the last relevant activity where the platform can show it.
  4. Record retain, remove or investigate for each line. Require a reason for retain and a verification step for remove, so that the removal can be checked later.
  5. Action removals on a fixed schedule with a named person, and confirm each one by reading the assignment back rather than trusting the change request status.
  6. Keep investigate items open with an owner and a date, and report them separately so they do not disappear into the completed count.

The read-back is a part many campaigns quietly skip. A removal recorded as done in the decision log is not the same as a removal visible on the user record. Read the record back, and where a role is granted through a group, remove the group membership or the role at the source.

Designing decisions reviewers will not rubber-stamp

Rubber-stamping often has a design cause. The screen shows a long list with a single approve button and no information about what the role allows. The reviewer assumes the access was approved at grant time and clicks through. Change the design so that each line states what the role can do in plain words, when it was last used where that is known, and who approved it originally. A reviewer who can see that a role permits changes to workflows will treat it differently from one who can see only a name.

The retain decision needs a reason that describes the present need. “Still required” is not a reason. “Needed to publish the approval workflow that the change authority uses each week” is a reason a second person can challenge. Requiring a specific sentence is a low-cost control, and it also helps make the campaign useful to an auditor reading it later.

Cases that need a rule before the campaign opens

Some situations will arise in every campaign, and deciding them on the day produces inconsistent results. Define in advance what happens when a reviewer leaves the organization, when a reviewer is the person whose access is under review, when access is shared through a service account, and when an owner disputes a removal. For each case, name the escalation route and the authority that decides. Record any exception with its scope, the compensating action, an owner and an expiry, so that it returns to the next campaign rather than becoming permanent.

Comparing review designs before choosing one

Review designStrengthTypical weakness
Review by individual userClear owner for each person’s accessLarge queues that reviewers approve in bulk
Review by roleShows what a role allows across all holdersHides who actually holds the role and why
Review by groupEfficient where groups map to business teamsInherited roles can slip past if groups are not checked
Review by privileged scopeFocuses attention where the damage is possibleLeaves ordinary access without a regular review

Many mature programs combine two of these. A common pattern is role review for the privileged scope and individual review for everyone else, with groups checked only where they grant privileged roles. The right mix depends on how the platform was built and how much of its access arrives through groups.

Signs the campaign is producing control rather than paperwork

A recertification is doing its job when removals happen, when the investigate list shrinks over time, and when the same role does not appear in the next campaign with the same unexplained holders. It is not doing its job when every campaign reports a near-total retain rate with the same reason typed against each line. Look at the removal rate and the reason text together. A campaign with few removals and varied, specific retain reasons is healthy. A campaign with few removals and identical reasons is probably a rubber stamp.

When to delay a campaign

Delay a campaign when the role model is being redesigned, because the decisions will be made against roles that are about to disappear. Delay it when a migration or identity change is in progress, because the population on the day will not match the population in the export. Do not delay it simply because the list is long. A long list is a reason to split the campaign, not to skip it.

Frequently asked questions about access recertification

Should inherited roles be reviewed separately from directly assigned roles?

Yes, at least for privileged roles. An administrator who holds a role through a group may not know the role is there, and a reviewer looking only at direct assignments will not see it. Show inherited access as its own line with the group it came from, so the reviewer can decide whether to remove the group membership or the role.

What do we do with service accounts in a campaign?

Review them under a named owner who is accountable for the integration, not under the individual who created them. Record what the account is for, which systems it calls and what credentials it uses. A service account with no owner is an investigate item by default, because nobody can say whether removing it will break a process.

How should a campaign handle a reviewer who leaves mid-cycle?

Reassign their open lines to a named successor before the next reminder is sent, and record the reassignment with the date. Lines left with a departed reviewer can end up approved by default when the campaign closes, which is the outcome the process exists to prevent.

Can access be certified through a group rather than person by person?

It can, where the group is owned by a business team that knows its members and where the group grants only roles that the team can judge. It is a poor choice where the group is large, mixed in purpose, or granted privileged roles that the group owner does not understand. In those cases certify the group’s membership and the role separately.

Related reading covers platform access reviews, segregation of duties and conflicting access, and a practical review of access controls. Offboarding is covered in the employee offboarding controls note, and the service page on this subject is the access, privacy and segregation of duties route.

If the access model itself is unclear, start by listing the privileged roles and their owners. Talk through your recertification scope with OBLYTECH before the next campaign opens.

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