An access has three moments in its life — grant, role change and removal — and the most expensive is the one almost never automated: removal. An account that outlives its owner is not an administrative oversight, it is a valid credential with nobody accountable for it.
What follows: why removal is the weak point, what automates well, what still requires judgement, and how to sequence the project.
Almost every organisation has a written procedure for granting a person access. Very few have one that runs equally well when that person leaves, moves department, or moves to a different contract.
The asymmetry is easy to explain: someone asks for the grant — the manager who needs the new joiner working — and nobody asks for the removal. Nobody calls the service desk to have a former colleague’s permissions taken away.
Why removal is the weak point
When removal depends on someone remembering, the result is predictable: active accounts belonging to people who have left, accumulated permissions from previous roles, and third-party access whose contract ended months ago.
That invisible inventory is what surfaces in an audit, and it is also what an attacker looks for first, because a legitimate credential raises no alarm.
The underlying problem is not security, it is process: the information that someone has left already exists — it is in the HR system — but it never reaches the systems where the access lives.
What automates well
Granting from a single source. When the HR system is the source of truth, granting stops being a form and becomes a consequence: the person’s record is created and the access matching their role is provisioned on its own.
Removal triggered by that same source. The exact counterpart, and the one that delivers most value. The leaving date is already recorded; automating means that date executes the revocation without waiting for someone to raise a ticket.
Role change. The case that accumulates the most permissions and is handled worst. A transfer usually adds the new access without removing the old, and that is how a set of privileges nobody can justify gets built, person by person.
Periodic recertification. Sending each owner the list of who has access to what, collecting the answer and executing the approved revocations is a repetitive flow with fixed dates and auditable evidence. A natural candidate.
What requires judgement
Defining which permissions belong to each role is not an automation task, it is a business decision. Automating on top of a poorly defined role model only distributes the wrong permissions faster.
Nor is immediate revocation right in every case alike. A contentious exit calls for an immediate cut; extended leave or a temporary transfer call for a reversible suspension. That difference is decided by a person, not a rule.
And some access — administrative rights over critical systems — should still require explicit approval, with a limited validity period and a record of what it was requested for.
What changes by environment
How much can be automated depends on how connected the systems are. Modern corporate platforms expose interfaces for provisioning and revoking; many business applications, especially older ones, do not.
For those the realistic path is hybrid: the automated flow generates the instruction, records it and assigns it to an owner with a deadline, so the manual step sits inside the process rather than outside it.
In organisations subject to personal-data protection — Habeas Data (Ley 1581) in Colombia, the LFPDPPP in Mexico — who can see which data is also a demonstrable obligation, and the evidence an automated flow leaves is exactly what a review asks for.
How to sequence the project
Start with the inventory: which systems hold their own users, who administers them, and how access is requested in each one today. That map usually reveals more applications than the organisation believed it had.
Continue with removal, not with granting. It is the highest-risk case, the one with the most visible result, and the one that generates least debate, because nobody argues that an account should stay active.
Then role change, which is where historical accumulation gets cleaned up. And only then the full granting flow, which is the showy part but the one with least effect on risk.
What has to exist first
Three things, and none of them is technological. A recognised source of truth for who works here today. A catalogue of roles with an owner, so there is something to provision against. And an owner per system, because recertification needs someone to answer.
With those, automation is an integration exercise. Without them, it is a project that automates the disorder.
Where is it best to start?
With removal. It is the case with the greatest exposure, the easiest to justify, and the one that produces immediate evidence: accounts that used to survive for weeks stop doing so the same day.
Does it help if we have older applications with no integration?
Yes, with a hybrid design. The flow automates the decision, the record and the follow-up; execution in that application remains an assigned task with a deadline and evidence. Control is gained even when the last step is manual.
How does this relate to an audit?
Directly. An automated flow leaves a trail of who requested each access, who approved it and when it was withdrawn. Reconstructing that by hand months later is what turns a review into a problem.
Is this a security project or an automation project?
Both, and it is worth treating it that way. The motivation is access control, but the real work is integration between systems and process design.
