Most access control problems do not start as security failures. They start as small, reasonable exceptions — someone was given temporary access to cover for a colleague, and nobody removed it once 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.

01. Why person-based access drifts

When permissions are granted to a specific person, removing them requires someone to notice the person’s responsibilities have changed and take a deliberate action to update their access. That noticing step is exactly where it breaks down — not because anyone is careless, but because access review is not usually anyone’s full-time job, so it happens on a schedule, if it happens at all, rather than the moment a change actually occurs.

02. What role-based access changes structurally

Access is defined against a role — approver, reviewer, administrator of a specific workflow — rather than against a named individual. When someone moves into that role, they get its permissions. When they move out, whether by promotion, a team change, or leaving the organisation, the permissions stay with the role and simply apply to whoever is in it next. The update happens automatically as a consequence of the role change, rather than requiring a separate, easily-missed step.

03. Why this specifically matters for client data

For any organisation handling client-confidential material, the question “who can currently see this, and why” needs a clean answer at any point in time — not just at the moment access was originally granted. Role-based access keeps that answer current by construction. It is also what makes the audit trail meaningful: knowing who approved something is only useful if “who” reliably means the person who held that accountability at the time, not whoever happened to still have leftover permissions from an old assignment.

04. How this is built into what we deliver

Access control is one of the control layer’s core components 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, and it shapes the design of every system we build — it is not a checkbox added at the end for a compliance reviewer.

05. What to check in your own operation

A simple test: if someone left your organisation tomorrow, could you list, with confidence, exactly what they had access to and why — without checking multiple systems and asking around? If the honest answer is no, the access model is probably still tied to people rather than roles, and it is worth treating as a design problem rather than a one-off cleanup exercise.

See how access, review, testing and traceability fit together as one governance model — how the work is controlled →