Offboarding Is Not Paperwork. It Is an Access Problem HR Owns.

Written by Ankush Gupta

A site in the publishing network we run started serving pages nobody on our team had written. Not many. They sat deep in the structure, the sort of thing you find only because you happened to be reading a sitemap for an unrelated reason. We traced the entry point to an administrator account belonging to someone who had finished working with us months before. Their exit had been processed properly. Every item on the checklist was ticked, signed and filed.

That is the part worth sitting with. Nobody was careless. The checklist was asking about a different set of things than the ones that mattered.

The exit form only knows what HR was told about

An offboarding checklist covers what the people function can see. Laptop returned. Email deactivated. Final settlement cleared. Notice period served. Those are real items and they matter, but they describe the formal relationship, and the formal relationship is rarely where the risk sits.

Access does not arrive through HR. It accumulates sideways. Someone needs to publish a post on a Tuesday, so a colleague makes them an admin instead of an editor because that is faster than working out which permission they actually need. A contractor gets added to a hosting panel for one migration. A freelancer is put into a scheduling tool by whoever happened to be on the call. None of that crosses an HR desk, so none of it appears on the form when the person leaves.

At FameNinja we work on reputation, which means we are usually called in after something has already gone public. The pattern in the cases we run is consistent enough to be boring. The incident is rarely a sophisticated attack. It is a door someone left open and nobody remembered was a door.

HR is the only function that knows a person has gone

I want to be careful here, because “HR should own security” is not the argument. The argument is narrower, and I think harder to dispute.

Your engineering or IT function knows what accounts exist. It does not reliably know which human being sits behind each of them, or whether that human is still part of the company. HR knows. HR holds the leaving date and the last working day. It knows the difference between a contractor whose scope quietly ended and one who is still on call.

So the useful question is not who should be responsible for access. It is who holds the trigger. An access review without a leaving date is a periodic chore that drifts. A leaving date without an access review is a form. Put the two together and you have a control.

We moved the work to the joining side

What we landed on was not a better exit process. It was recording the answer at the point where someone joins, then keeping it current while they are with us.

Every person who comes on now has a single record of what they have been given access to, written in plain language rather than tool names, and that record is updated by whoever grants the access, at the moment they grant it. Nobody has to remember anything months after the fact. The exit checklist stopped asking whether access had been removed and started reading back a list.

The enforcement is deliberately dull. We run an internal automation that chases the open items with reminders that escalate if they are ignored, because the step that fails is never the technical one. It is the follow-up. Someone means to revoke the account after the handover call, and then the day happens to them.

One thing surprised me. The people who built and maintained that automation were our operations team, not developers. They understood the process well enough to automate the part that kept breaking. A developer would have built something more elegant and less connected to how the work actually runs.

The cleanup is public in a way the incident never was

Here is what makes this a people problem rather than an IT one.

When an access failure becomes visible, the response lands exactly where candidates look. Search results for the company name. Coverage that stays indexed long after the technical issue itself is closed. In the work we do, removing or de-indexing that material takes somewhere between two and six weeks in the straightforward cases, and a broader reputation repair runs three to six months. Through all of it, the company is still trying to hire. Candidates search before they apply, and what they are reading is the aftermath.

None of that is an argument for fear. It is an argument about where to spend an hour. An access register maintained from the first day costs one person a few minutes per joiner. The alternative is not necessarily a breach. The alternative is a category of risk that nobody in the building is positioned to see, sitting inside a process everyone believes is complete.

So look at what your offboarding checklist actually asks. If every question on it could be answered by someone who has never logged into a single system your company uses, the checklist is measuring the paperwork and not the exposure. Ours was. We found out by accident.

Author Bio:
Ankush Gupta is a Fractional CMO at
FameNinja, where he works on online reputation management, digital PR and marketing automation.

Share:

Leave a Reply

Your email address will not be published. Required fields are marked *