An employee joins, changes roles, or leaves. In each case, someone has to decide which systems they can access, and which they no longer can. While a company is small, this is often done from memory: the administrator knows who's logged in where, and sorts it out when needed. As the team and the number of services used grow, memory stops being a reliable tool.
Managing access isn't just a technical question. It's an agreement on who makes the decision, who carries it out, and how you verify that everything has been done. This article looks at how to put such an agreement together without excessive paperwork.
Why access rights "linger" and why that's risky
A typical situation: an employee left six months ago, their computer was returned, and their email account was disabled — yet a login to the accounting system, cloud storage and a client self-service portal is still active under their name. No one did this on purpose — it's just that no one had the complete list.
Such accounts create several problems at once. A former employee, or someone who knows their password, can access company data. Licenses sometimes keep being paid for unused accounts. And when an incident occurs, it's hard to answer a simple question — who had access at the time. A similar problem arises with role changes: an employee gets new permissions, but the old ones remain, so over time one person ends up seeing more than their job requires.
Start with a list, not a tool
Before choosing an access management solution, it's worth answering the question of what actually needs to be managed. In many companies, the list of systems is longer than it looks at first glance: besides email and the accounting program, there's online banking, document storage, a CRM system, social media accounts, supplier portals, office door codes and the printer administrator password.
A practical approach is to build a single table listing, for each system, who owns it within the company, who technically creates and removes accounts, and which access level each role receives. The table doesn't have to be perfect. What matters is that it exists, lives in one place, and has a responsible person keeping it up to date.
Such a review often reveals systems accessed with a shared password, or accounts whose owner no one remembers anymore. That's not a criticism — it's a useful starting point, and exactly where it's worth beginning to tidy things up.
Three moments that need a clear procedure
Once the list exists, you can agree on what happens in three situations: when an employee joins, changes roles, and leaves. A short but specific sequence is enough for each case.
- Onboarding. A manager or HR representative reports the new employee, their role and start date. Accounts are created according to the agreed role-and-access table, multi-factor authentication is enabled, and login details are shared securely. Any permissions not covered by the table are granted only with separate approval.
- Role change. This is the most commonly forgotten case. New permissions are granted, while the old ones are reviewed and removed if no longer needed. If old permissions are needed during a transition period, a date is set in advance for when they'll be revoked.
- Departure. On the last working day, or at an agreed time, all accounts on the same list are disabled, any shared passwords the employee knew are changed, and their email inbox and documents are taken over or redirected. Equipment is returned, and completed actions are recorded.
At every step, it must be clear who initiates it, who carries it out, and who confirms the work is done. The most common mistake is everyone assuming someone else will handle it.
How to check the procedure actually works
An agreement on paper doesn't mean it works day to day. That's why it's worth scheduling a periodic review, during which you check together with system owners whether the list of active accounts matches your current employees and their roles. It's best to match the review frequency to how often staff change at your company.
A few simple guidelines that help keep things in order:
- Avoid shared accounts wherever the system allows individual ones. Where a shared account is unavoidable, its password is kept in a password manager, not a shared document.
- Grant permissions based on role, not on requests to match "what a colleague has". Exceptions are fine, but they get recorded.
- Give administrator rights only to those who need them daily, not to everyone just in case.
- Log account creation and removal so you can later confirm when it happened and by whose decision.
If access management is handed to an external partner, the same principles apply to them as well: it must be clear which systems are covered by maintenance, how requests for new or removed accounts are submitted, and how quickly they're carried out. Anything not included in the agreed scope is stated separately, so there's no assumption that someone else is handling it.
Access management isn't a one-off project. It's a daily practice resting on three things: a single list, clear responsibilities, and regular verification.
No measure removes risk entirely, but organized access rights help avoid surprises as your team changes. You can start with a small step — one list and one responsible role.