What It Actually Means
Instead of deciding thirty separate things about each new starter, you make them an Account Manager and they inherit what that means. When the definition changes, it changes once for everybody who holds it.
That sounds like an implementation detail. It is actually one of the few architectural decisions that is genuinely painful to reverse, which is why it is worth ten minutes of your attention before a build rather than a year afterwards.
Why It Has To Be Early
Permissions are not a feature that bolts on. They are a question asked at every point where the system shows or changes anything, which means they touch essentially all of it.
A system built with two roles, admin and user, and later needing seven, does not get a small change. Every screen, every list, every report and every action has to be revisited to work out what each new role should see. This is the origin of a great many “simple change” estimates that come back as multi-week projects, and it is entirely predictable at design time.
The cheap version of this decision is asking, before anything is built, who will eventually need access and what should be hidden from each of them. Not who has access today. Who will, once the system is doing its job.
The Model Worth Insisting On
Three ideas cover the majority of real requirements.
Roles, not individuals. The moment permissions are set per person, nobody can answer who can see what, and the answer drifts as people come and go.
Scope as well as role. Most real requirements are not “can they see invoices” but “can they see these invoices”. A manager who should see their own team’s records and not another region’s needs both a role and a boundary. Systems that model only the role end up with the boundary hard-coded, which is where the awkward exceptions accumulate.
Deny by default. New things should be invisible until someone grants access. Systems built the other way leak quietly, because every feature added later is visible to everyone until somebody remembers to restrict it.
What To Ask
- Who will need access in two years, and what should each not see? Answer this before the build, not during.
- Can one person hold two roles? Real businesses need this more often than expected, and systems that assume one role each are awkward to extend.
- Is access scoped by team, region or client as well as by role?
- How do we remove access? Offboarding is where most access problems originate, and it should be one action rather than a tour of twelve systems.
What It Does Not Solve
Access control decides what someone is permitted to do. It says nothing about what they did.
Those are separate mechanisms and both are needed. Permissions prevent the wrong action; an audit trail records the right ones. A system with careful roles and no trail can tell you a change was legitimate and never who made it.
The other common gap is review. Access accumulates: people change roles, cover for absences, join projects. Almost nothing removes it automatically. A twice-yearly look at who holds what catches more real exposure than most security spending, and it takes an hour.
More terms are in the glossary.
