Standing Rights: Why UK Systems Teams Keep Postponing the Access Review

The review that never makes the roadmap

Ask a UK systems team how many people can amend a customer credit limit in the ERP, and the honest answer is often a shrug followed by a request for a fortnight. The information exists. It sits in role definitions, group memberships, integration accounts and the accumulated debris of three migrations. What is missing is not the data but the mandate to interrogate it.

Access reviews are postponed for a reason that has little to do with difficulty. They are politically expensive. Every entitlement traced back to a named individual is a conversation with a manager who granted it in good faith, and every removal is a small negotiation about cover, convenience and trust. In mid-market firms where the finance systems lead also runs reporting, the review competes with month-end and loses.

The cost of deferral is not abstract. It shows up as segregation-of-duties exceptions in an internal audit, as awkward questions in a cyber insurance questionnaire, and as a slow drift in which the number of accounts holding privileged rights grows faster than the headcount holding them.

Where sprawl actually concentrates

Role creep is not evenly distributed. It clusters around three privileged actions, and knowing which is which turns an unbounded exercise into a scoped one.

Master data change. Price lists, chart of accounts, supplier bank details, customer hierarchies, product dimensions. These rights matter more than transaction rights in many respects, because a master data change propagates silently into pricing, payments, statutory reporting and every downstream dashboard. A user who can edit a supplier's bank details but cannot raise a payment is still a fraud pathway.

Transaction approval. Approval limits and workflow delegation are the classic source of segregation-of-duties conflicts. Temporary cover arrangements are usually the origin, and they are almost never unwound.

Bulk export. The ability to pull a full customer list, payroll extract or margin report is a data protection question as much as an operational one. Exports are often granted to solve a reporting problem, then retained long after the reporting need has moved into a proper warehouse.

Why previous attempts stalled

The pattern is familiar. Someone builds a spreadsheet of role assignments, the export is already out of date by the time it is circulated, managers approve their own teams without reading closely, and the output is filed rather than actioned. The exercise consumes three weeks and changes nothing.

Three design faults cause most of these failures. The review is treated as a point-in-time event rather than a cycle. It is owned by IT alone, when the authority to remove access sits with business managers. And it treats all access as equally important, so reviewers exhaust themselves on read-only reporting roles before reaching the privileges that carry real risk.

A six-step review that survives operational pressure

One: scope at system level, not enterprise level. Pick the two or three systems that hold the privileged actions — typically the ERP, the CRM and the warehouse management platform. Do not attempt an identity estate-wide sweep first.

Two: classify entitlements by action, not by role name. Role names drift. Extract the underlying permissions and tag each as master data change, transaction approval, bulk export or none of the above. This single step usually reveals that a handful of roles carry disproportionate power.

Three: reconcile against current job families. Map each account to a live role in the organisation, not to the role that existed when the account was created. Leavers, movers and long-term cover arrangements surface here.

Four: validate by shadowing, not surveying. A short interview with the person doing the work will reveal the temporary query, the manual workaround and the second login far faster than a form. Budget two days per system.

Five: convert standing rights into time-bound entitlements. An entitlement with an expiry date is a governance control in itself. Where the platform supports it, link elevated grants to a ticket reference and an end date.

Six: institutionalise the cycle. Quarterly attestation for privileged roles, annual for the rest, with joiner-mover-leaver triggers wired into the identity process so the next review starts from a cleaner baseline.

Removing the just-in-case grants without stalling the month

Most resistance comes from cover. A finance manager keeps an approval right because the alternative is being unable to process a payment during a colleague's leave. Removing the permission without replacing the cover mechanism simply pushes activity into shared logins and informal delegation.

Design the delegation route first. A named deputy with a defined window, an emergency access path with retrospective approval, and a clear expectation that the emergency path is reviewed weekly will remove most of the objection. Run the pilot in one module — accounts payable is usually the safest — and let the absence of disruption make the case elsewhere.

The realistic target is not zero standing privilege. It is a documented, evidenced and defensible position that can be explained to an auditor in ten minutes.

What the evidence pack should contain

Increasingly, UK organisations are asked to demonstrate rather than assert. A workable pack holds the current privileged access report per system, the approved segregation-of-duties matrix, the attestation record with named approvers, and a log of removals with dates. Under the accountability principle of UK data protection law, that record is as much an operational asset as a compliance one.

The review is not a one-off clean-up. It is the maintenance schedule for an estate that will keep acquiring permissions for as long as it keeps changing.