At three people, everyone can read customer data, nobody reviews it, and nothing is logged. Every remedy written on the subject assumes an identity team and a joiners and leavers process, so the advice gets abandoned rather than adapted.
Least privilege still applies at this size. Just not through the dimension everyone writes about.
Why least privilege advice does not fit a small team
Least privilege, which OWASP’s application security verification standard treats as an access-control requirement rather than an aspiration, has three dimensions: scope, which resources; level, what kind of access; and duration, for how long. Most advice about it is really advice about scope, and scope is the dimension a small team cannot use. You cannot meaningfully restrict which systems three people touch when three people are the entire company.
That is why the advice reads as impossible and gets abandoned. The mistake is concluding that least privilege does not apply at your size. It applies completely, just through the other two dimensions.
Level and duration are available to you. Not everyone needs write access at all times. Nobody needs to be reading raw customer records as a background condition of their working day. And the difference between permanent capability and requested capability is achievable with tools you already pay for.
| Dimension | Available to a team of three? |
|---|---|
| Scope | Barely. Everyone touches everything. |
| Level | Yes. Read is not write, support is not admin. |
| Duration | Yes, and this is where the leverage is. |
Break glass access and a deliberate support path
The workable version is not restriction, it is separation of the normal from the exceptional. Two ideas carry most of the value.
Split standing access from break glass access. Everyday accounts do everyday work and cannot read raw customer data. A second, more powerful path exists, requires a deliberate act to use, and produces a record when used. Nobody is blocked, because the powerful path is always available. What changes is that using it is now an event rather than a condition.
The realistic objection is that at three people you will approve your own break glass access every time, which feels like theatre. It is not, because approval was never the point. The record is the point. It gives you an answer when a buyer asks, it makes unusual access visible, and it is the only version of this that keeps working when the team is thirty and you are no longer the person using it.
Build the support path deliberately. Most customer data access happens because someone is helping a customer. If the only tool for that is direct database access, then every support request is an unrestricted read of the entire customer base. A modest internal tool that looks up one customer, and records that it did, converts your most frequent access into your most controlled one.
That tool is also the most dangerous software you own, because it is designed to see everything. It deserves the authentication and the logging you would give the product itself, which is a sentence worth remembering when it is being built at speed on a Thursday.
Where production access goes wrong
- Everyone shares one administrative account. The CIS Controls put account and access management this early for a reason. Convenient, and it destroys the ability to answer who did anything. The first fix is individual accounts, before any question of roles and permissions.
- Temporary access that never ends. Elevation granted during an incident, never withdrawn, because taking it back is socially awkward and nothing visibly breaks.
- The contractor who still has access. Offboarding at a small company happens in the middle of something else. The person left, the access did not.
- Automation with more rights than any human. The deployment credential that can do everything, held by a system nobody thinks of as a user.
- Logging that captures logins but not reads. Knowing someone connected is not knowing what they looked at, and the second is what you will be asked.
- Personal devices as the real boundary. Access is controlled properly, then a full customer export sits in a downloads folder on a laptop indefinitely.
The last one is worth a specific habit. Exports are how carefully controlled data escapes control, and the fix is not a policy but a default: exports go to a location with an expiry, not to someone’s machine.
Questions to ask about production access
- Who can read customer data today, and could I prove that answer to someone who did not believe me?
- Is reading a customer record something we do, or something that happens as a side effect of doing other work?
- What is recorded when someone accesses production, and would it still be there in eight months?
- What access does each of us hold that we last used more than a month ago?
- If someone left tomorrow, what is the list of things to switch off, and does the list exist before we need it?
- Which automated systems hold rights greater than any person’s, and why?
The fourth question is the cheapest useful exercise on this list, and when you act on it, disable before deleting. Reversible decisions are the ones people actually make.
For the principle underneath all of this, and why the duration dimension is where most organizations quietly lose control, see what least privilege actually means.
Start here. List every account with elevated access in three columns: who owns it, what it is for, when it was last used. It takes an afternoon, and the rows nobody can justify are the finding.
At three people the question is never who to keep out. It is whether anyone could tell, afterwards, what any of you did.