Someone quits on a Friday. By Monday you're trying to figure out which systems they had access to. Here's how to set up access control properly — before you need it.
Someone on your team quits on a Friday. By Monday you're trying to figure out which systems they had access to. The Notion workspace, probably. Google Drive, definitely. The AWS console — maybe? The CRM — you're not sure who set that up. The Mailchimp account with your entire subscriber list. The domain registrar.
This isn't a security worst-case scenario. It's Tuesday morning at a 40-person company that didn't think about access control until they needed to.
Why access problems accumulate
Growing teams add tools constantly. Each tool gets configured by whoever sets it up, usually with admin access because that's the path of least resistance. Contractors get onboarded with the same credentials as full-time employees because nobody created a separate role. A billing email address someone set up two years ago is still receiving critical system alerts. The person who left six months ago is the only admin on three systems nobody else remembers setting up.
None of this is unusual. It happens at most companies that grew faster than their processes. And it's rarely a problem — until someone leaves, something breaks, or someone asks for an access audit.
The issue isn't that companies are negligent. It's that access control is easy to defer. It doesn't visibly break anything today. You deal with it later. Later keeps moving.
What this actually costs you
There are two costs to getting access control wrong, and companies usually only think about one.
The obvious cost is the security risk. Stale credentials, over-provisioned access, shared passwords — these are the vectors for most credential-based incidents. The less obvious cost is the maintenance overhead. Every time someone joins or leaves, someone on your team spends time manually tracking down accounts, revoking access, and hoping they didn't miss anything. At 10 people this is annoying. At 50 people it's a half-day project every time.
The solution isn't a compliance framework. It's a simple, documented process that runs without thinking about it.
What getting it right looks like in reality
You don't need enterprise identity management to handle this well. You need three things.
A single place for passwords and credentials. Every system access should live in a shared password manager, not in someone's personal LastPass account, a spreadsheet, or a Notion page. When someone leaves, you deprovision one account and all their access goes with it. When someone joins, you share credentials from one place. Self-hosted options like Vaultwarden work well for this — same Bitwarden interface your team already knows, running on your own server.
Roles, not individuals. Most tools support role-based access. Use it. Define what a read-only user can do, what an editor can do, what an admin can do — then assign people to roles rather than configuring permissions per person. When someone's role changes, you change the role assignment. When they leave, you remove them from the role. Nothing falls through the cracks because there are no custom configurations to track down.
A documented offboarding checklist. This sounds basic. Most companies don't have it until they need it. Write down every system that needs to be touched when someone leaves. Include the systems people forget: the domain registrar, the DNS provider, the cloud billing account, the GitHub org, the analytics tool, the support inbox. Run through it every time someone leaves. Update it when you add new tools.
That's it. Not a framework. Not a project. Three things you can set up in a week.
When to do it
The best time to set up access control properly is during the initial deployment of a new system, not after. Retrofitting access management onto systems that were deployed without it means auditing everything that already exists — every account, every permission, every credential — and that work is slow and error-prone.
When we deploy infrastructure for clients, access control is part of the deployment, not an optional extra. Password management is configured before the first user is onboarded. Roles are defined before the first person is assigned. Offboarding procedures are documented before the first person has to use them. The overhead of getting this right at the start is small. The overhead of fixing it later is significant.
What to do if you're already in a mess
Most companies reading this aren't starting from scratch. You have systems that have accumulated permissions over years, credentials stored in places that made sense at the time, and admin access distributed across people whose scope has changed.
The starting point is an audit. Map out which systems exist, who has access to what level, and where credentials are stored. It's uncomfortable work. You'll find things that should have been cleaned up years ago. But the audit tells you what you're working with, and you can't fix what you haven't mapped.
From there, consolidate credentials into a shared vault, tighten permissions to the minimum required for each role, and write the offboarding checklist before the next person leaves.
It doesn't have to be done all at once. Prioritise the systems where a breach or access problem would hurt most — email, financial tools, customer data, production infrastructure — and work outward.
Want access control built in from the start?
Our Infrastructure Support engagements include access management configuration as a standard part of every deployment. Credentials in a shared vault, role-based permissions, documented offboarding procedures — all set up before the system goes live, not retrofitted after. Workspace & Productivity migrations include Vaultwarden deployment as part of the standard stack.