Why Permissions Matter More as a Team Grows

In a small team, everyone can see everything, and that is usually correct. Restricting access between five people who sit together adds friction and removes nothing, because anyone who wanted to know something could simply ask.

The awkward part is that the point at which this stops being true arrives without announcement. There is no day when someone declares the team large. There is only a day, some time later, when a person who left three months ago turns out to still have access to the customer list.

What actually changes with size

Three things, and none of them is about trust.

The number of people who can make an irreversible mistake grows. Deleting a record, sending a campaign to the wrong list, changing a price — these are not malicious acts. They are ordinary errors, and their likelihood scales with the number of hands.

The number of people who understand the consequences does not grow at the same rate. The first five hires learned the system while it was being built. The next ten inherit it finished, and the reasoning behind it lives in conversations they were not part of.

Departures start happening. Access granted informally is almost never revoked informally, because nobody remembers what was granted. Every leaver becomes a small open question that nobody closes.

The two things people confuse

Authentication and authorisation get run together, and separating them makes the whole subject easier.

Authentication is proving you are who you claim. Authorisation is what you may do once that is established. Most access failures in small businesses are authorisation failures — the person is genuinely who they say, and is genuinely allowed in, and should not have been able to do the specific thing they did.

This matters because effort tends to go into the first and not the second. Everyone knows to use a password manager. Far fewer have ever looked at what a "team member" can actually do in the tools they use every day.

What good practice actually says about passwords

Since authentication is where most attention goes, it is worth correcting a common piece of received wisdom, because it costs real effort and buys little.

The guidance that most security teams now follow is explicit that forced rotation is counterproductive: "Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator" [1].

Both halves matter. Rotating every ninety days for no reason produces predictable, weakened passwords and teaches people that security is theatre. Rotating immediately when something has actually gone wrong is not optional. A policy with the first and not the second has it precisely backwards.

Connected accounts are permissions too

The permissions people think about are the ones inside their own tools. The ones that cause trouble are frequently the ones granted to other software.

When you connect an application to your email, your calendar, or your social accounts, you are granting it access on your behalf — a framework designed so an application can "obtain limited access to an HTTP service... on behalf of a resource owner by orchestrating an approval interaction" [2]. The word to notice is limited. The grant has a scope, and the scope is chosen by whoever built the integration, approved by whoever clicked the button, and reviewed by approximately nobody thereafter.

Two consequences follow. First, an application granted broad access retains it long after the reason for granting it has passed. Second, these grants usually belong to an individual's account, so when that person leaves, the connection either dies unexpectedly or continues running under the credentials of someone who no longer works there. Neither outcome is good, and both are common.

A worthwhile exercise: list every third-party application currently connected to your business accounts and, for each, name the person who approved it and the reason. Most teams cannot complete this, and the incompletion is the finding.

Permissions as a way to reduce fear

The framing that makes access control feel bureaucratic is "stopping people doing things". A more accurate framing is that it lets people act without checking first.

When anyone can do anything, careful people become slow. They ask before touching, because the consequence of an error is unbounded and they cannot see the boundary. Well-set permissions draw the boundary, and inside it people move quickly because they can see they are safe.

That is the practical return, and it is larger than the security return for most small businesses. The security case is real but abstract until something happens. The speed case shows up in the first week.

The obligation that arrives with other people's data

There is a threshold worth naming plainly. The moment you hold data about other people — your customers' customers, employee records, anything that identifies someone — permissions stop being an internal efficiency question and become an external obligation.

That obligation is concrete and time-bound. The standard commitment in a data processing agreement is to notify the other party of any personal data breach within 72 hours of becoming aware [3]. Meeting that requires knowing who had access to what, and when. A business that cannot answer those questions cannot meet the obligation it has already agreed to, whatever its intentions.

The shared login is the thing to fix first

If there is one concrete change worth making before any policy work, it is eliminating shared accounts.

A shared login is the single decision that disables everything else. It makes the audit trail meaningless, because every action is attributed to a person who is really five people. It makes revocation impossible, because removing a leaver's access means changing a password that four remaining people depend on — so it does not happen. And it removes the one thing that makes a mistake recoverable: knowing who did it, and therefore being able to ask them what they were trying to do.

Shared accounts persist for a good reason, which is that per-seat pricing makes individual accounts feel expensive. It is worth pricing that honestly against a single incident where nobody can say who deleted the customer list.

Where to start

Not with a policy document. With three lists.

Who has access to customer data, and does each of them still need it. Which third-party applications are connected, and who approved each. What can be deleted permanently, and by whom.

Any of the three will find something. The third usually finds the most, because permanent deletion is the permission people grant most casually and regret most specifically.