· Yair Knijn
The internal mover who accumulated every role they ever held
Joiner-mover-leaver is the framework every GRC lead can recite. You staff the joiner runbook because a new hire with no access is a visible problem. You staff the leaver runbook because an ex-employee with live credentials ends up in a board pack. The mover gets a shrug. Someone changes teams, a manager files a ticket for the new access, it shows up, everyone moves on. Nobody files the ticket that removes the old access, because the old access is not anybody's job to notice.
The wrong assumption is quiet: that a role change is an addition. It is supposed to be a swap. The add happens, the subtract does not, and four years later your most-moved employee holds a stack of entitlements no single decision ever granted on purpose.
Why the mover, not the leaver, is the privilege-creep risk
The leaver is a clean event: a last day, a checklist, and a binary end state with access on, then off. The mover has no terminating event. They are still here, still productive, still using some of what they hold, so nothing trips an alarm. ISO 27001:2022 control 5.18 is explicit that access rights must be reviewed and modified on a change of role, not only on exit, and that every change is logged. Auditors write that sentence because modify-on-transfer is the step almost everyone skips. A leaver finding is embarrassing. A mover finding is structural: it means your provisioning process has no idea what a transfer is supposed to remove.
Toxic combinations: how movers break segregation of duties
Privilege creep on a single mover is not just "too much access." The danger is the specific pairing. Someone who once worked in procurement can raise a purchase order. After a move to finance they can now approve the payment. Neither entitlement is wrong on its own. Held by one person they are a textbook segregation-of-duties break, the exact create + approve conflict ISO 27001:2022 control 5.3 exists to stop: it lets a single individual commit, conceal, and justify the same action.
What makes these pairs slippery is that no provisioning event ever created them. Each grant was reasonable in its moment. The conflict is an emergent property of two correct decisions made eleven months apart, which is why a review that inspects one request at a time never catches it. You have to look at the accumulated set.
Entitlement history in one place, across every product
Here is where the GRC lead loses. To answer "what does this person hold, and which pairs conflict," you need the full entitlement history for that human across every system they have touched. In a fragmented estate it lives in pieces:
- The current grant is visible; the grant it was supposed to replace is not.
- Conflicting entitlements sit in two different products that never compare notes.
- "When did they get this, and against which role change" has no single answer.
So you rebuild it by hand, per app, reconstructing the present state without the timeline that explains how it got toxic. The four-year trail of grants and revokes is scattered, or already rotated out of logs.
Catching creep with a periodic least-privilege reconciliation
The control that works is boring and periodic: a recurring reconciliation that compares what each person holds against what their current role justifies, and flags both orphaned grants and toxic pairs. Run it on a cadence, not only when someone moves, because the conflicts you are hunting were assembled across moves you have already forgotten. Treat every transfer as a revoke-then-grant, and make the revoke list a required output of the move.
This stays cheap only when entitlement history is one record instead of ten. In Spot Suite, every grant and revoke across the products hangs off a single Customer Environment, so a least-privilege reconciliation reads one timeline and the toxic create + approve pair surfaces in a single export instead of a spreadsheet stitched together the night before the audit. The security page lays out how that record handles access and audit.