User Access Provisioning and Review

User access provisioning and review. Provisioning gets attention because someone is waiting for it. Deprovisioning gets forgotten because no one is. That gap is this lesson.

The scene. A review of active accounts turns up three people who left the company months ago and can still log in, one of them dismissed. It also finds a contractor whose engagement ended in spring. Every one of these accounts was created properly, with an approval and a ticket. The failure was never in granting the access. It was in nobody ever taking it away.

Access tracks employment through three events. First, the joiner: a new person is granted the access their role needs, ideally provisioned from an approved request tied to H-R.

Second, the mover: someone changes role, and their access should change with it, gaining what the new role needs and, critically, losing what the old role needed. Skipping the removal is how privilege creep sets in.

And third, the leaver: someone departs, and all their access must be promptly revoked. Joiner, mover, leaver.

The most acute risk in the whole lifecycle is a leaver whose access is not removed. A former employee retaining active credentials, or an attacker using them, has legitimate-looking access they should no longer hold.

And it is sharpest for an involuntary termination, where the person may be aggrieved and motivated to cause harm, and where access should be cut at, or before, the moment of departure. So deprovisioning is treated as a time-critical control, ideally triggered automatically by H-R when employment ends, not left to someone remembering to raise a ticket.

Why do the mover and leaver steps fail so quietly. Because nothing is blocked when access lingers. The joiner step is self-correcting, the person is present and expecting access. But lingering access blocks nothing, so no one notices until a review, or a breach, finds it.

Which is why a periodic access review, or recertification, backstops the process. At an interval, the business or data owner and the user’s manager re-confirm that each person’s access is still appropriate for their current role, and revoke what is not. It catches the movers who accumulated access, the leavers who slipped through, and orphaned accounts.

And who does the review matters. It must be done by someone who knows what the role should permit, which is the business owner and the manager, not I-T. I-T provides the access listing and executes the changes; it cannot judge appropriateness. And a user reviewing their own access is no review at all.

This is the same independence logic that runs through the course: the person who decides must be positioned to judge, and must not be marking their own homework. An access review where users approve their own access is a conflict, not a control.

So carry this away. Pour less attention into granting access and more into removing it: the terminated user who still has access is the classic finding, and the leaver, especially an involuntary one, is the highest risk in the lifecycle. And the periodic review is a business owner’s recertification of what each role should hold, not an I-T task and not a rubber stamp.