Who Has Access to What (And Why You Probably Don't Know)

Ask a small business owner what a particular contractor has access to and you usually get an approximate answer. That approximation is the problem — you cannot remove access you can't enumerate.

Access accumulates naturally. Someone needs one thing for a project, gets added to two more for convenience, and nothing is ever removed because nobody is tracking it and removing things feels unnecessary until suddenly it isn't.

Build the register first

Everything else depends on it. A spreadsheet is fine.

SYSTEM              WHO HAS ACCESS        LEVEL        OWNER      REVIEWED
Email               all staff             user         [name]     2026-09
Accounting          [name], [name]        admin/user   [name]     2026-09
Bank                [name]                admin        [name]     2026-09
CRM                 all staff             user         [name]     2026-09
Domain registrar    [name]                admin        [name]     2026-09
Website hosting     [name], [agency]      admin        [name]     2026-09
Shared drive        all staff             varies       [name]     2026-09
Payment processor   [name], [name]        admin        [name]     2026-09

Building it the first time takes an afternoon and is genuinely uncomfortable — most people find at least one account belonging to someone who left, and usually one system nobody remembers who owns.

That discovery is the point. You can't fix what you can't see.

Include the things people forget: domain registrar, DNS, hosting, social accounts, the password manager itself, API keys, third-party integrations, and anything a former agency set up.

Least access, not convenient access

The default in small businesses is to give everyone admin because it's simpler and nobody wants to be the bottleneck for a permissions request.

That converts every small mistake into a potentially large one — an accidental deletion, a compromised account, a misconfigured setting.

Give the least access that lets someone do their job. Practically:

• Admin is for the smallest possible number of people, ideally two so you're not a single point of failure
• Read-only where read-only is enough — bookkeepers frequently need to see, not change
• Project-scoped access rather than everything, where the tool supports it
• Time-limited access for contractors, with an end date set when it's granted

That last one is the highest-value habit. Set the removal date at the moment you grant access, while you're thinking about it, rather than intending to remember later.

Shared logins are the real problem

One account, several people, the password in a shared vault or — worse — a chat message.

The technical risk is real, but the bigger cost is that you lose accountability entirely. When something changes, you cannot tell who did it. When someone leaves, you have to rotate a credential several people know and hope you caught everyone who has it.

Where individual accounts exist, use them, even when it costs more per seat. The per-seat fee is usually less than one incident's worth of untangling.

Where a shared login genuinely can't be avoided — some legacy tools, some social platforms — then at minimum: it lives in the password manager, it's rotated whenever anyone with access leaves, and the register records exactly who has it.

The joiner checklist

Run on day one, and it belongs in the onboarding plan rather than being improvised:

• [ ] Individual accounts created for every system they need
• [ ] Least-privilege level set, not admin by default
• [ ] Added to the password manager, with only the shared credentials they need
• [ ] Two-factor enforced on email and anything sensitive
• [ ] Added to the access register
• [ ] End date recorded if they're a contractor

Everything working on the first morning matters for a second reason: someone who spends day one waiting for logins learns something about how the business runs.

The leaver checklist

The one most often skipped, and it runs the same day — not eventually.

• [ ] Email disabled (forward first if needed, then disable — don't leave it active)
• [ ] Removed from every system on the register
• [ ] Shared credentials they knew, rotated
• [ ] Devices returned or remotely wiped
• [ ] Personal devices removed from any mobile device management
• [ ] API keys or integrations they created, reviewed and reassigned
• [ ] Register updated

"Eventually" means never. The account still active eighteen months after someone left is a real and common finding, and it's the kind that shows up in an incident report rather than an audit.

Contractors and agencies are the most-forgotten category, because there's rarely a formal leaving date — the work just stops. Hence setting the end date at grant time.

Review quarterly

Fifteen minutes against the register:

• Is everyone on this list still here?
• Does anyone have more access than their job needs now? Roles change and access accumulates.
• Is anything owned by someone who has left?
• Any accounts that aren't a person — service accounts, integrations — and does anyone know what they do?

Put it in the quarterly planning cycle. It's the same discipline as any other audit that quietly stops happening without a slot.

When you can't answer the question

If you genuinely don't know who has access to what, start here rather than trying to be comprehensive:

1. The critical five — email, bank, accounting, domain, hosting. Enumerate and clean these first.
2. Rotate the shared credentials you can't account for.
3. Check email accounts for forwarding rules you didn't create, which is a common sign of compromise.
4. Then the rest, over a couple of weeks.

Doing the critical five properly beats doing everything superficially.

The mistakes

1. No register. You can't remove what you can't enumerate.
2. Admin by default. Turns small mistakes into large ones.
3. Shared logins. Accountability gone, rotation painful.
4. No end date on contractor access. Nobody remembers later.
5. Leaver process "eventually." Which means never.
6. Forgetting domain and DNS. The most damaging access to lose control of.

What to do next

Spend an hour building the register for the critical five: email, bank, accounting, domain and hosting. Just those.

You will almost certainly find at least one account that shouldn't still exist — and that finding is worth the hour on its own.