In short
Access accumulates because granting it is easy and reviewing it is nobody's job. Regain control with three moves rather than a security project: build an inventory of which systems exist and who owns each one, replace shared passwords with a password manager so credentials can be revoked rather than merely changed, and run a review twice a year plus every time someone leaves. Aim for a business where access can be removed in an hour, not for perfect least privilege.
Key takeaways
- Nobody grants excessive access deliberately. It accumulates through reasonable individual decisions.
- Shared passwords cannot be revoked, only changed, which means they are rarely revoked at all.
- The inventory comes first. You cannot review access to systems you do not know exist.
- Each system needs a named owner, or reviews have nobody to run them.
- The realistic goal is fast, complete removal on departure, not perfect permissions.
How access accumulates
No small business decides that everyone should be able to see everything. It arrives through a sequence of individually sensible decisions.
A folder is shared with the team because three people need it. Someone joins and is added to the team. A contractor needs one file, so they are added to the folder for the duration and never removed. Somebody sets up a tool with a shared login because individual seats cost more. A client issues a portal account in one person's name. Four years later, nobody can answer the question of who can reach the payroll folder, and the honest answer is that several people can who should not, none of whom sought it.
Two properties make this self-reinforcing. Granting access takes seconds and is a favour; removing it takes deliberate effort and feels like a statement of distrust. And nobody owns the review, so it is nobody's failure that it has not happened.
Access is granted by people who are busy and removed by nobody, which means it only ever accumulates.
The inventory nobody has
The first task is not tightening permissions. It is finding out what exists, because you cannot review access to systems nobody has listed.
The inventory takes an afternoon and is built from three sources, all of which surface different things:
- Ask everyone what they log into in a normal week. Produces the tools people actually use, including ones management does not know about.
- Check the card statements for the last twelve months. Produces the subscriptions nobody mentioned, including the ones on personal cards claimed as expenses.
- List client-issued accounts. Portals, systems and logins provided by clients, which appear in no internal record at all.
For each system, record four things: what it is, who owns it internally, who has access, and whether it holds sensitive data. That last flag is what lets you prioritise, because the goal is not to treat a design tool and a payroll system identically.
| Field | Why it matters |
|---|---|
| Named owner | Without one, nobody runs the review or notices the renewal |
| Who has access | The list is almost always longer than expected |
| Sensitive data? | Sets which systems get real attention rather than periodic attention |
| Individual or shared login | Determines whether access can be revoked at all |
This inventory has a second use beyond security: it is usually the first complete list of what the business pays for, and it commonly turns up two or three subscriptions nobody uses. It overlaps directly with the systems inventory in your tools don't talk to each other, and doing both at once is efficient.
Shared passwords are the core problem
Everything else is a matter of degree. Shared credentials are a categorical difference, because they cannot be revoked.
When access is individual, removing someone takes one action and is complete. When a password is known, removing someone requires changing it, which disrupts everyone else still using it, so it is deferred, and deferred indefinitely. The practical consequence is that every person who has ever known that password still has access, including former employees and contractors from three years ago.
The fix is a password manager, and it is the single highest-value security change available to a small business.
- People use credentials without knowing them. Access becomes revocable, which is the entire point.
- Removal becomes one action rather than a coordinated password change.
- You get a list of what exists, maintained as a side effect of daily use.
- It removes the spreadsheet, or the shared document, or the note in a message thread, which is where credentials currently live in most small businesses.
- Revocable access
- Access that can be withdrawn by an administrative action, without requiring anything to change for anyone else. Shared known passwords are not revocable, which is why they persist long after the people who know them have left, and why replacing them is worth more than any amount of permission tightening.
What good looks like in a small business
Perfect least privilege is not the target. In a team of fifteen, tightly scoped permissions produce constant requests for access to things people legitimately need, and the requests are granted in a hurry, which returns you to where you started.
A realistic standard has four properties:
- Sensitive categories are deliberately restricted. Payroll, contracts, financial systems, client personal data. Everything else can be broadly open.
- Access is granted by role, not per person. Groups rather than individual grants, so joining and leaving a role is one change rather than eleven.
- Every system has a named owner. Reviews need someone to run them.
- Removal takes under an hour and is complete. This is the test that matters most, and it is the one most businesses fail.
Is a reasonable target for removing all of someone's access on their last day. A business that cannot do this is not necessarily insecure, but it cannot demonstrate otherwise, and it will discover the gaps individually over the following year.
Reviews: twice a year and on every exit
Two triggers, and the second is the one that gets missed.
Scheduled, twice a year. Each system owner checks the access list and removes anyone who no longer needs it. Half an hour per system. The most common finding is contractors and former team members still listed, followed by people who changed role and kept both sets of access.
On every departure and role change. Departures are usually remembered, at least partially. Role changes almost never are: the person gains access for the new role, and nobody removes the old, so the longest-serving people accumulate the broadest access in the business. Working from the inventory rather than from memory is what makes either version complete, which is why the list is built at the start of a notice period, as covered in employee offboarding.
Client systems and the ones you forget
The categories that survive every review because they are invisible to it:
- Client-issued accounts. Held by an individual, unrecorded internally, and outliving both the engagement and the employee. Removing them requires the client to act, which requires asking, which is why it belongs in client offboarding.
- Personal-card subscriptions. Account in an individual's name, renewing silently, invisible to the business until it lapses.
- Recovery routes. Someone's phone as the second factor on a company account, or their personal email as the recovery address. These outlast every other form of access and are found only when an account needs recovering.
- Automation and integration credentials. Connections built by someone who has left, running under their account, which stop working at an unpredictable moment.
That last one has an operational cost as well as a security one: an integration authenticated as a departed employee will fail eventually, usually silently, and the data stops flowing before anyone notices. It is worth checking which of your automations run under a personal account rather than a service one.
None of this requires an IT function or a security budget. It requires a list, an owner per system, a password manager, and two calendar entries a year. The Mayim Ops assessment treats this as part of resilience rather than as a security topic, because the operational question — can this business continue and can it cleanly remove someone — is the same question.
Frequently asked questions
How should a small business manage access to its systems?
Keep an inventory of every system with a named owner for each, use a password manager so credentials are shared without being known, grant access by role rather than individually, and review twice a year plus on every departure. That is achievable without an IT function and covers most of the practical risk.
Why are shared passwords a problem?
A known password cannot be revoked, only changed, and changing it disrupts everyone still using it. So it is not changed, and everyone who ever knew it retains access indefinitely, including people who left years ago. A password manager solves this by sharing use without sharing knowledge.
How often should you review who has access to what?
Twice a year as a scheduled review, and immediately whenever someone leaves or changes role. Role changes are the more commonly missed of the two, because access is added for the new role and never removed for the old one.
What is least privilege and is it realistic for a small business?
Least privilege means people have only the access their role requires. Perfect application is impractical for small teams, where flexibility matters and roles overlap. A realistic target is that sensitive categories — payroll, contracts, client data, financial systems — are restricted deliberately, and everything else is reviewed periodically.
What access is most commonly forgotten when someone leaves?
Client-side accounts issued directly to the individual, subscriptions bought on personal cards, shared credentials that are known rather than assigned, and recovery routes such as their phone as a second factor or their email as an account recovery address.