Why a former employee can often still just log in
Someone says goodbye, the laptop is handed back, the access badge is returned. And yet: in the systems, that person often stays active for days, sometimes weeks. Not because anyone wants that, but because nobody has nailed down the process. We see this at almost every SME we speak to for the first time - and it’s one of the most underestimated risks out there.
The problem isn’t the technology
Revoking access is technically no problem at all. Disabling an account takes a few minutes. Where it goes wrong is the question of who should do it, and when. HR handles the exit conversation and assumes ICT takes care of it. The manager assumes HR passes it on. ICT waits for a request that never comes, or arrives two weeks late. Between those links, the ball drops - not because people are careless, but because nobody owns the process end to end.
Why this is such a big risk for SMEs
At large organisations, offboarding is often a fixed part of a broader process. At smaller companies it tends to happen ad hoc: an email here, a checkbox there, relying on people’s memory. The problem is that access today is everywhere: email, a shared drive, the CRM system, a planning tool, sometimes a VPN connection or an app on a personal phone. A former employee who can still log in somewhere isn’t just a privacy risk. It’s also an account nobody is watching anymore - and that’s exactly the kind of account an attack targets, precisely because no alarm bells go off anymore.
Measure first: do you know who has access to what?
Before you can arrange anything, you need to know what there is to arrange. That’s why we never start with a tool, but with a simple question: who currently has access to what? That sounds obvious, but at many companies there’s no up-to-date overview of this. Systems were added over the years, accounts were created by different people, and nobody ever took the time to bring it all together. Without that overview you can’t make policy - you’d be making agreements about something you can’t actually see.
Concrete advice: make a list of all the systems an employee might have access to, and note per system who is currently logged in. That’s not a months-long ICT project, it’s an afternoon’s work to get started.
Only then, policy: who is responsible?
Once you know what’s actually going on, you can agree on how it should work. That means: recording who gives the signal (usually HR or the manager), who actually revokes access, and within what timeframe. Preferably: the same day. Not because we assume departing employees have bad intentions, but because an account left open is an unnecessary risk, regardless of the previous owner’s intentions.
This policy doesn’t need to be complicated. One page covering who, what and when is often enough - as long as it’s written down and doesn’t depend on whoever happens to remember.
Bring people along, don’t just mandate
A process around offboarding doesn’t only affect the people leaving, but also those who stay. When colleagues understand why access is taken seriously - during their employment too, not just after - it becomes easier to comply with. We often see companies introduce a rule without explaining why, and then are surprised when it isn’t followed. Explain that it’s not about distrust, but about care. That lands far better than a mandate that appears out of nowhere.
Automation only afterwards, as the final piece
Only once the overview exists and the policy is in place does automation make sense. Think of a link between your HR system and your ICT environment, so that an offboarding notification automatically triggers account blocking. That’s a great step - but only if it supports an existing, well-thought-out process. Automation introduced before you know who has access to what only automates the chaos that was already there.
What this means for your business
As far as we’re concerned, this topic doesn’t belong under “ICT security” alone - it belongs to how you deal with people, from onboarding to offboarding. It’s also directly relevant if you want to work in a way that’s demonstrable towards NIS2: being able to show who has access, and that it’s revoked in time, is exactly the kind of evidence that’s asked for. Not because a law demands it, but because it’s simply good practice.
Don’t start with a tool. Start with the question: do we currently know who has access to what? The answer to that question determines everything that follows.
A few questions we’re often asked
Do we need a separate process for every single system?
No, that’s not necessary. The overview you build covers all systems at once, and the policy - who gives the signal, who executes it, within what timeframe - can be the same for most systems. Only systems with a separate administrator, such as an external accounting package, need a small addition.
What if someone leaves on bad terms and we don’t have time to handle it neatly?
That’s exactly when it matters that the process is already fixed, so you don’t have to improvise under pressure. If it’s already agreed who acts within what timeframe, you can respond immediately even in an abrupt departure, instead of first figuring out who’s supposed to handle it.
Does this also apply to freelancers and temporary staff?
Absolutely, and often the risk is even bigger, because external workers are less likely to be part of the standard HR process. Include them explicitly in the overview and the policy, even if they don’t go through regular payroll.
Is this something we can arrange once and for all, or does it need ongoing maintenance?
The overview and the policy are a solid foundation, but systems and staff change, so it needs periodic upkeep. Plan a fixed moment, for example every quarter, to check whether the overview still holds true.
Want to know how this is arranged at your company, or noticed that nobody can say exactly who has access to what? We’re happy to think it through with you, step by step.
