Access That Follows the Role, Not the Person
Access tied to a person goes stale, because someone must notice a change and act on it. Access tied to a role follows responsibilities: the permissions stay with the role as people move. For client data, that keeps the answer to “who can see this, and why?” current.
Most access problems do not start as security failures. They start as small, reasonable exceptions that nobody removed: someone was given temporary access to cover for a colleague, and nobody took it away when the cover period ended. Multiply that across a few years and a few dozen people, and the result is an access list nobody can fully explain. This article explains why that happens and what changes when access follows the role.
01. Why person-based access drifts
When permissions are granted to a specific person, removing them takes a deliberate action by someone who has noticed that the person’s responsibilities have changed. That noticing is where it breaks down. Not because anyone is careless, but because access review is rarely anyone’s full-time job, so it happens on a schedule, if it happens at all, rather than at the moment a change occurs.
02. What role-based access changes
Access is defined against a role, such as approver, reviewer, or administrator of a specific workflow, rather than against a named individual.
| Person-based | Role-based | |
|---|---|---|
| Permissions are granted to | A named individual | A role |
| When someone moves into the job | Someone must add each permission | They receive the role’s permissions |
| When someone moves out or leaves | Someone must notice and remove them | The permissions stay with the role |
| Temporary cover | A personal exception that is easy to forget | The role, with an end date |
| The question “who has access, and why?” | Needs a search across systems | Answered by who holds the role now |
With roles, the update is a consequence of the change, not a separate step that is easy to miss. When someone moves out of a role, by promotion, a team change or leaving, the permissions stay with the role and apply to whoever holds it next.
03. Why it matters for client data
For any organisation holding client-confidential material, “who can see this right now, and why?” needs a clean answer at any point, not only at the moment access was first granted. Role-based access keeps that answer current by construction.
It is also what makes an audit trail meaningful. Knowing who approved something is only useful if “who” reliably means the person who held that accountability at the time, not someone who happened to retain permissions from an old assignment. See audit trail and traceability.
04. What a role does not fix
Roles are not a cure on their own.
- The roles themselves can sprawl. A role that quietly gains permissions becomes a shared exception. Roles need a small, written definition and a review when responsibilities change.
- One person can hold several roles. That is fine, as long as each is visible, not hidden inside a personal account.
- Role design takes thought. It is done at design time, not discovered afterwards.
05. How this is built into what we deliver
Access control is one of the core components of the control layer in every connected delivery system we build. Who can see and do what is defined at design time and recorded, following the role rather than the person, so it changes when responsibilities change rather than when somebody happens to remember. This is stated as a governance commitment on Trust & Security, and it shapes the design of every system. It is not a box ticked at the end for a compliance reviewer. For how it fits with data handling, see what we do with your data.
06. A five-minute test for your own operation
Run three checks:
- The leaver test. If someone left tomorrow, could you list, with confidence, exactly what they had access to and why, without checking several systems and asking around?
- The mover test. If someone changed teams last month, which of their old permissions are still active?
- The role test. For each important role, can you name who holds it today and where its permissions are written down?
If the honest answer to any is no, the access model is probably still tied to people. That is a design problem, not a one-off clean-up.
07. Frequently asked questions
What is role-based access control?
A model in which permissions are granted to a role, such as approver or reviewer, rather than to a named individual. Whoever holds the role has its permissions.
Why is person-based access a risk?
Removing a person’s access depends on someone noticing their responsibilities have changed. That step is easily missed, so access drifts and lists become impossible to explain.
Does role-based access remove the need to review access?
No. Roles need a short written definition and a review when responsibilities change. What changes is that individuals’ permissions update automatically with their role.
How does it help with an audit?
It makes “who approved this” reliable, because “who” means the person who held that role at the time, not someone with leftover permissions.
How can I test my own setup?
Ask whether you could list a leaver’s access without asking around, which old permissions a mover still has, and who holds each important role today.
08. Next step
See how access, review, testing and traceability fit together as one governance model. How the work is controlled →
