Managing access feels awkward in a small company. You know each other, you trust each other, and then you sit down to write out who may and may not get into what. It looks like suspicion, but it is about something else: whether someone's rights still match the work they do today. Roles shift, projects end, people join and leave. Without something that keeps track, access only ever grows.
Digital access is ours, physical access is Radboud University's. Our office is at The Launch on the Heyendaal campus of Radboud University in Nijmegen. The university manages physical access to the building. We manage digital access: accounts, company email, servers and everything else behind a login. This post is about the digital side.
One identity, and nothing outside it. It all starts with identity. Everyone working here has a single company account, and that account is the starting point for every other bit of access they get. You don't walk into the work with a personal account or a stray login.
The reason is simple: without a unique, traceable identity you cannot tell who did what when a change or an incident needs explaining. Shared accounts are therefore ruled out, unless there is genuinely no technical alternative and we put extra safeguards around it. The same goes for access to server environments: that runs on keys tied to a person, not on a password that gets passed around.
Least privilege and need-to-know, in plain words. Two terms from our policy keep coming back:
- Least privilege: you get exactly the rights your work requires, and no more.
- Need-to-know: you can reach information because your task needs it, not because it might come in handy.
That isn't a matter of principle, it is practical. You cannot accidentally break an environment you are not in. And if an account is ever taken over, through phishing for instance, an account with modest rights gives an attacker a modest result.
SOLL and IST: what should be, and what actually is. To judge access at all, we keep two overviews, and the gap between them is the entire point.
| SOLL matrix | IST matrix | |
|---|---|---|
| Describes | The intended situation: which rights belong to which role? | The actual situation: which rights are in fact open? |
| Source | Set together with the people responsible for the systems | Pulled from the systems themselves, not from memory |
| Reviewed | At least once a year, or sooner when roles change | Every quarter, and after larger role changes |
Then we lay the two side by side. That comparison is called a gap analysis, and it produces two kinds of difference:
- Rights someone holds but doesn't need for their role. This is a risk.
- Rights someone needs for their role but doesn't have yet. This is usually a colleague who cannot do their job and is quietly working around it.
We run that comparison every quarter, and again after larger role changes. Differences don't linger: they are recorded and corrected within a few working days, after which the administration is accurate again. That rhythm matters more than being perfect on any single day.
Joining, changing roles, leaving.
New colleagues get the employee handbook on day one and work through an onboarding checklist: access to the systems their work needs, a buddy who checks that everything is actually in place, and, during any trial period, no access to customer data or sensitive company information yet.
Leaving is the same list in reverse. HR reports the departure or role change, after which access to systems and communication channels is withdrawn, company property is handed back, and our register of people and equipment is updated. We also ask departing colleagues to remove company documents and repositories from their own machines. On top of that we schedule a proper handover and a conversation to look back; it should be a closing, not a drain.
Every quarterly review produces differences, and we learn from them: if the same kind of discrepancy keeps returning, we change the process rather than only adjusting rights. Read more about this in continual improvement.
Access is the kind of thing that does not tidy itself. By setting fixed moments, requiring requests in advance, comparing access every quarter and using a fixed checklist when someone leaves, no one has to remember that it still needs to be done. It is simply on the calendar.