Provision and deprovision on a checklist

Access provisioning is a process most companies run informally and describe formally. There is a documented list, and there is what actually happens, which is that someone grants what the new starter asks for as they discover they need it.

Deprovisioning is worse, because nobody is asking.

Write the standard sets down

Not per person. Per role. A designer gets these six things; an engineer gets these nine. Exceptions exist and should be exceptions, requested explicitly.

The exercise of writing this is usually where a company discovers that three people have access nobody would grant them today.

Build it as a workflow, with gates

Workflows rather than a scheduled job, for one reason: approval gates pause the run and wait, and access granting is exactly the kind of step that should not proceed unattended.

Structure it as: gather what is needed, pause for approval, then grant, then record what was granted.

The gate goes before the grant, never after. Revoking access you should not have granted is possible; unknowing what was seen in the meantime is not. This is the difference between a workflow that saves time and one that creates an incident, and it is one edge in a diagram.

Deprovisioning is the half that matters

Provisioning has a natural forcing function: the new person cannot work until it happens. Deprovisioning has none, which is why it silently does not happen.

When someone leaves, run the deprovision workflow.

Revoke the standard set for their role, plus anything granted to them as an
exception, using the record from when it was granted.

List anything you could not revoke automatically, with who owns that
system.

Do not close the run until every item is either revoked or explicitly
acknowledged as handled by a person.

That last instruction is what stops a partially completed deprovision looking finished.

Audit against the record quarterly

Every quarter, compare who currently has access to each system against who
should, per our role definitions and the exception record.

Report anyone with access their role does not include and no recorded
exception.

This is where you find the accounts that survived a role change two years ago. It is uncomfortable the first time and boring afterwards, which is the correct trajectory.

What good looks like

A new starter has what they need on day one without asking, a leaver has nothing by the end of their last day, and the quarterly audit is dull.

The measure is that audit. If it keeps finding surprises, the exception record is not being written at the moment access is granted, and everything else here rests on it.