I’m going to tell you a story. The details have been changed to protect the company involved — but the sequence of events is real.
A 45-person SaaS company. Good team, strong culture, growing fast. A developer resigned after three years — no bad blood, they were going to a larger company. The notice period was worked out professionally.
On their last Friday, the standard things happened. The Google account was suspended. Slack was deactivated. They handed back their laptop. There was a farewell lunch.
By any normal standard, the offboarding was handled.
Then, on a Tuesday three weeks later, a commit appeared in a private repository from an account nobody recognised.
What Had Been Missed
What the standard offboarding process had caught:
– Google Workspace account — suspended ✅
– Slack — deactivated ✅
– Company laptop — returned and wiped ✅
What it had missed:
– Personal laptop — still had the production database credentials saved in Chrome. Never cleared.
– AWS account— the developer had been given admin access 18 months earlier to handle a specific project. Nobody had removed it. It was still active.
– MFA authentication app — three critical systems used MFA via an authenticator app on the developer’s personal phone. The phone was still associated with those accounts.
– GitHub — the developer’s personal GitHub account had been granted access to the company’s private repositories. That access was never removed.
– Figma — still a member of the company’s Figma workspace with access to product designs.
The mysterious commit couldn’t be definitively attributed to the former employee. It might have been an automated process, a misconfigured integration, a different security issue entirely. It was investigated and closed without conclusive findings.
But the damage — the damage was to trust, to confidence, and to the realisation that the company had been exposed for three weeks without knowing it.
Why This Happens
This story isn’t unusual. The reason it happens isn’t negligence or malice — it’s a gap between what “offboarding” means to HR and what it means to IT.
HR thinks: final paycheck processed, equipment returned, access removed.
IT thinks: access removed means every access, from every system, including the ones we don’t think about.
These two definitions are different. And the difference lives in the gap where security incidents happen.
The Anatomy of Thorough IT Offboarding
When I build offboarding processes for companies, I work backwards from a single question: in six months, could this person still access any company system or data? If the answer is yes, or even maybe, the offboarding isn’t complete.
That means thinking about:
Active accounts you know about:
The obvious ones — email, Slack, GitHub, Jira. Most companies cover these.
Active accounts you forgot about:
The third-party tools. The external Slack workspaces. The contractor accounts from before they were a full employee. The vendor portals. The monitoring dashboards. The analytics tools.
Persistent access that outlives account suspension:
OAuth connections — tools that were authorised via “sign in with Google” persist even after the Google account is suspended. The connection is to the third-party service, not to the Google account itself.
Device-based access:
MFA apps on personal phones. Browser-saved passwords on personal devices. Locally cached credentials. Cloud sync that may have left company data on a personal machine.
Infrastructure access:
AWS, GCP, Azure roles and IAM permissions. SSH keys. API keys created in the person’s name. Database access.
Building an Offboarding Process That Catches Everything
The solution is a documented process with an explicit checklist, tested and maintained.
Not a mental checklist. Not “we know what to do.” A written, versioned checklist that is completed and signed off for every departure.
The checklist should be built from your actual IT environment — your specific SaaS tools, your specific infrastructure, your specific device management setup. Generic templates are a starting point, but the real value comes from mapping the process to how your company actually operates.
The process should also have a clearly assigned owner. Someone is responsible for completing every item. Someone else reviews it. Both names are on the completed document.
And the process should be tested — ideally on a low-stakes departure before you need it for a high-stakes one.
The Cost of Getting It Right
Building a thorough offboarding process takes a few hours. Maintaining it — updating it as your tool stack changes — takes 30 minutes every quarter.
Compare that to the cost of an incident. Legal fees. GDPR notification obligations. Reputational damage. The investigation that follows. The weeks of uncertainty about what was accessed.
Offboarding is security hygiene. Like all hygiene, it works best when it’s a habit.
Find out if your company’s offboarding process covers everything it should with the free IT risk assessment at itops.zlefterov.com.