Guest post by Julian Lübke, Co-Founder and CEO of deeploi.
Key takeaways
- Missing evidence is a symptom, not the problem. When nobody can show who had access to what, it's usually because the process was never defined, not because anyone was careless.
- A defined process needs three things: an event that triggers it, a named person who owns the outcome, and a system that carries out the change and records that it did.
- The three days that matter most. Access changes hands on someone's first day, on the day they move to another team, and on their last day. The middle one is the one almost everyone skips.
- Structure the process and the record writes itself. The dates become real because the system recorded them as it acted, instead of being reconstructed from memory during audit week.
The problem is not carelessness
When an auditor asks who had access to what, and when, the honest answer in most small companies is that nobody can reconstruct it. It is tempting to read that as a discipline problem. It usually isn't.
Access is granted over Slack by whoever has ten minutes on that day. It gets removed whenever someone happens to remember. Since there is no trigger, no owner, and no defined end state, there is nothing to document. The evidence is missing because the process was missing, and you cannot document a process that doesn't exist.
A defined access process is one where every change consists of three things: an event that triggers it, a named person who owns the outcome, and a system that carries out the change and records that it did. Take away any of the three and you are relying on somebody's memory.
There are three days in every employment relationship where access changes hands: the employee's first day, the day they move to a different team, and their last day. Each of them can be run as a defined process, and when they are, the record you need at audit time falls out of the process by itself instead of being a separate job you do twice a year from memory.
Here's what a defined process looks like at each of those three moments. This is written for companies where the person handing out access also has another full-time job, because that's who usually ends up doing it.
When someone joins a company
1. Role-based access: every role has a default, and everything else is an exception
The informal version starts by asking what this person needs. Whoever answers is guessing, and the guess runs generous, because being too restrictive creates a support ticket and being too generous creates nothing visible at all.
The alternative is not to give everyone in a job title identical access. Two people on the same marketing team may need very different things, since one runs the ad accounts and the other writes content, for example. The alternative is to decide what the role gets by default, apply that automatically, and treat anything on top as a request that a named person approves.
That single distinction is what makes an access review possible. When there is a default, you can look at one person's access, see where it differs, and ask why. When there is no default, there's nothing to compare against, and the review turns into a long conversation that ends in a shrug.
2. Device management starts with knowing whose laptop it is
Almost every company with under a hundred people tracks its hardware in a spreadsheet. There is a tab with serial numbers, a column for who has which laptop, and a date somebody typed in when it was handed over. It is a reasonable way to start, and it usually stays accurate for about three months.
Then a laptop gets exchanged because it slowed down, and the switch doesn't make it into the sheet. A device is lent to a freelancer for a project that ends without anyone reclaiming it. Someone's row is deleted during a cleanup. The sheet keeps looking authoritative, because spreadsheets always do, but it has quietly become a record of what somebody believed was true at some point in the past.
The problem is not the spreadsheet's format. It’s that a spreadsheet is a claim about reality maintained by hand, and every hand-maintained record drifts in the same direction: incomplete, and confidently so.
A live inventory works the other way around. The device reports what it is, who is signed into it, which operating system version it runs on, and whether encryption is on. The record updates because the device said so rather than because someone remembered to write it down. In the fleets we manage at deeploi, that is what the inventory is: not a list somebody maintains, but what every device is currently reporting about itself. When you later need to show that a laptop holding customer data was encrypted on a particular date, you are reading a system that observed it rather than reconstructing it from a sheet.
That link between a named person and a specific device is also the foundation for everything else. Patch status, encryption state and remote lock are all attributes of a device, and they only become evidence about a person when the assignment is recorded properly. Getting IT device management right at the moment of handover is what makes the other eight steps provable.
3. Security settings apply on day one, not at some point
Disk encryption, screen lock, password rules and automatic updates are all things that are configured properly at some point after the first day, when someone gets round to it. The gap between the start date and that point is invisible, unbounded and impossible to reconstruct afterward.
The structured version applies the baseline before the person ever logs in. The device arrives already configured, and the settings are enforced rather than recommended. This is the moment where written policy either becomes real or stays theoretical, and it costs nothing extra to do it at the start. Doing it later costs an afternoon per device and leaves a gap in the timeline.
When someone switches teams
4. Access is added for the new role
This step always happens since the person cannot do their new job without it. It's the only one of the nine that never gets skipped, which is worth noting: work that could otherwise potentially block somebody gets done, and work that blocks nobody does not.
5. Access is removed from the old role
This is the step almost everyone skips, and it is the reason access reviews in fast-growing companies turn up people with permissions from two jobs ago. The old access is not causing anyone a problem. Nothing breaks, nobody complains, and so it stays.
A defined process treats a team change as a single event with two halves, not as a request for more access. The move is triggered from the HR system, and both the addition and the removal are part of the same action. If the removal is a separate task that somebody has to remember, it will be forgotten, and the person who eventually leaves the company will leave with a permission set nobody understands.
6. Someone confirms the result
The third step is the one that feels bureaucratic but actually is not. After the change runs, there should be a defined moment when a named person looks at what the access set actually is now and confirms it matches the new role.
Without that moment, you are assuming the change worked. Most of the time it did. The times it didn't are exactly the cases that show up in an audit, and the difference between the two is a confirmation that takes about a minute and produces a dated record with a name on it.
When someone leaves
7. IT offboarding closes every account on a trigger, not on a reminder
Email gets closed on the last day because email is visible. The project management tool, the design tool, the CRM, the tool one team started using last spring and never told anyone about: those stay open, sometimes for years.
A defined offboarding runs from the leaving date in the HR system rather than from someone's recollection, and it covers the full set of accounts in one flow. deeploi is connected to the company's HR system, so when someone in HR enters a leaving date in Personio or whichever system they use, the offboarding is scheduled for that date automatically: the accounts are lined up to close, the licenses to be released, the device to be locked.
The trigger matters as much as the coverage. A task that depends on a person remembering it will be done late, and late is what the record will show. Automating employee IT offboarding is not about speed, though it is faster. It's about the process starting without anyone deciding to start it.
8. The device comes back or gets locked remotely, and either way it is recorded
Hardware goes missing at exits more often than anyone likes to admit, particularly with remote teams and/or when the exit was not amicable. The process needs to handle both outcomes. Either the device is returned and reset, or it is locked and wiped remotely, and the outcome is recorded with a date in both cases.
An unreturned laptop is a manageable incident when you can show it was locked on the last day. It is a serious problem when the honest answer is that nobody knows where it is.
9. Files are handed over and licenses are reclaimed before anyone goes looking
Two things happen when this step is undefined: First, business-critical documents sit in a closed account and someone has to request access to their former colleague's drive three weeks later. Second, paid licenses keep renewing for people who no longer work at the company.
Handing over data to a named successor and reclaiming the license belong in the same flow as closing the account, on the same trigger. The GDPR angle is worth noting, too: a defined cleanup date, separate from the exit date, gives you a documented point at which personal data is actually deleted rather than an account that quietly persists forever.
The nine steps, their triggers, and what they leave behind
The gap nobody records
Here's the situation that makes the argument better than any principle can.
Your HR system says the person left on the 31st. Their accounts were actually closed the following week, or the week after that, because the person who closes accounts was on holiday and picked it up when they got back. Nothing anywhere records the difference between those two dates, and six months later, nobody can tell you what it was.
That gap is not a discipline problem, and hiring someone more conscientious will not close it. It's what happens when a task depends on a person remembering rather than a process triggering. The fix is structural: define the trigger, name the owner, and let the system carry out the step.
Do that and the evidence writes itself. The dates are real because the system recorded them as it acted, which is the only kind of evidence worth having. Leave the three days informal and you will spend audit week reconstructing history from memory, hoping the version you reconstruct is close enough to what happened.
Policies describe how access should change hands. What makes them true is a process that runs whether or not anyone is thinking about it. If you are already doing the policy work properly, IT compliance at the device and access layer is what to structure next.
Frequently Asked Questions
What are the three moments when employee access changes?
Access changes hands on someone's first day, on the day they move to a different team or role, and on their last day. Each of those is a point where permissions are added, removed, or both, and each one should be triggered by an event in the HR system rather than by a request from whoever noticed.
Why can small companies rarely show who had access to what?
Because the process was never defined, not because someone was careless. When access is granted informally and removed whenever somebody remembers, there is no trigger, no owner and no system carrying out the change, so nothing gets recorded along the way. The evidence is missing because the process that would have produced it doesn't exist.
Do people in the same role need identical access?
No, and a good process does not assume they do. The role defines a default that applies automatically, and anything beyond it gets requested and approved by a named person. Two people on the same team can end up with different permissions, as long as the difference is a recorded exception rather than an accident.
What should trigger an IT offboarding?
The leaving date in the HR system. A trigger tied to a date closes accounts on schedule whether or not anyone is thinking about it, while a trigger that depends on someone remembering produces a gap between the official last day and the day access actually ended. That gap is what auditors ask about, and it is usually undocumented.
Why is a device spreadsheet a problem for compliance?
A spreadsheet records what somebody believed in the moment they typed it. Devices are exchanged, lent and returned without the sheet being updated, so it drifts out of date while still looking authoritative. A live inventory reads the state from each device, which means encryption and patch status are observed facts with dates attached rather than claims you have to reconstruct.
