Who Can Do What: Access Control When Everyone Has Been an Admin
Almost every Kenyan business that installs a system starts with everyone as an administrator, because that is the fastest way to stop being asked for permissions. Then the controls you paid for stop meaning anything. How to get to least privilege without blocking work.
The first two weeks after go-live are where access control is quietly abandoned. A storekeeper cannot post a receipt, a supervisor cannot approve a requisition, somebody cannot see a report they need at four o'clock — and the fastest way to make all three complaints stop is to give everyone the administrator role. It works immediately. Nobody is blocked again.
What it also does is delete the meaning of every other control in the system. Segregation of duties becomes decorative, because the same person can now raise a purchase order, receive against it and approve the payment. The audit trail still records who did what, but it no longer proves anything about what they were entitled to do. And the eventual investigation finds that thirty-one people had full access, which is the same as saying nobody was responsible.
Why it happens, and why blaming laziness misses the point
It is tempting to treat this as a discipline failure. It is usually a design failure that happened earlier: roles were configured before anyone knew what the work actually looked like, by someone during implementation, using names copied from a template. So the roles do not match the jobs, people hit walls constantly, and the only tool available for fixing it quickly is escalation.
Roles designed from a template
- Named after job titles that do not match your actual jobs
- Set up once during implementation and never revisited
- Every gap is discovered by somebody being blocked mid-task
- The fix is always "give them admin for now"
- Nobody knows what any role can actually do without testing it
- A leaver keeps access because nobody knows what removing it breaks
Roles designed from the work
- Named after what the person does, not what their contract says
- Reviewed after the first month, when the real gaps are visible
- Gaps get fixed by adjusting the role, not escalating the person
- Admin is two or three people, deliberately, and everyone knows who
- You can say in one sentence what each role is allowed to do
- Removing a leaver is one action with a predictable result
When everyone is an administrator, the audit trail still records who did it. It just stops telling you whether they should have.
If you are designing roles from scratch, start elsewhere
This article is about recovery — you already have a system, everyone already has too much access, and you need to get back without blocking work. If you are setting roles up for the first time, roles and permissions: deciding who can see what covers the design properly, including why approval must be a separate permission from the action it approves.
Roles are not the same as permissions, and the difference matters
A permission is a single capability — approve a purchase order, view payroll, delete a customer. A role is a named bundle of permissions that maps to a job. Systems that only give you roles force you to choose the least-wrong bundle. Systems that only give you permissions leave you assigning forty checkboxes per person and quietly copying whoever was set up last.
What you want is both: permissions as the atoms, roles as the bundles you actually assign, and the ability to see what a role contains before you hand it to someone. That last part is what makes review possible. If you cannot answer "what can the branch supervisor role do?" without clicking through a person's account, you will never review it.
| Design question | The weak answer | The answer that survives a year |
|---|---|---|
| How many roles? | One per job title on the org chart | One per distinct set of things somebody does — usually fewer than you expect |
| Who gets admin? | Anyone senior | Two or three named people, listed, reviewed quarterly |
| How are exceptions handled? | Escalate the person permanently | Adjust the role, or grant a documented temporary exception with an end date |
| What happens when someone changes job? | Add the new role, keep the old one | Replace, never accumulate — this is where over-privilege comes from |
| What happens when someone leaves? | Deactivate eventually, when someone remembers | Same-day deactivation, tied to the HR leaver process |
| How do you know it is still right? | You do not | A named person reviews the role-to-person list on a fixed rhythm |
The job-change row is the one that creates most real-world over-privilege, and it is entirely invisible. Nobody grants excessive access on purpose. It accumulates: a storekeeper becomes a supervisor and keeps the storekeeper permissions, then covers for the buyer during leave and keeps those too. Three years later they can do everything, and no single decision caused it.
The combinations that matter more than the count
Reviewing access by counting permissions per person is the wrong measurement. What matters is which capabilities sit together in one pair of hands, because certain pairs remove a control entirely rather than merely widening access. The full treatment is in segregation of duties; these are the combinations to check first in a Kenyan SME, where small teams make them likely rather than exceptional.
Combinations to look for in your own role list
- Can raise a purchase order and approve it — the requisition control is gone.
- Can receive goods and amend the purchase order — quantities can be made to match whatever arrived.
- Can create a supplier and approve a payment — this is the ghost supplier scheme, in two permissions.
- Can adjust stock and perform the count that would have caught the adjustment.
- Can edit an employee record and run payroll — a ghost employee needs nothing else.
- Can record a sale and process a refund with no second pair of eyes on the refund.
- Can grant permissions and perform operational work — the ability to expand your own access is the master key.
That last one is the one people forget. Whoever administers roles can give themselves anything, which is why administration should sit with someone who does not also run operations, and why the audit log needs to record permission changes as carefully as it records payments. The schemes these combinations enable are described concretely in five ways money leaves a Kenyan business.
What the system does, and what stays your decision
What AWRA OpsHub does today
- Permissions as the atoms and roles as the bundles, so you assign a role and can see what it contains rather than reasoning about forty checkboxes per person.
- Enforcement at the request level, so a permission gate is not merely a hidden menu item — the action itself is refused.
- Permission changes recorded in the audit log with actor, time, IP and affected record, so expanding someone's access leaves a trace.
- Support access recorded separately — impersonation is logged as its own event type rather than appearing as ordinary activity.
- Deactivation that ends access immediately, including clearing sessions and API tokens rather than waiting for a session to expire.
- Document vault access logged independently, because the sensitive files are usually the thing that matters and general activity logging is too coarse for them.
What it does not do
- No access review campaign workflow. Nothing prompts you quarterly to confirm each person's role is still right, and nothing records that you did. The review is a rhythm you must run yourself with a named owner and a calendar entry.
- No time-bound permission grants. A temporary elevation for someone covering leave has no expiry date and will not remove itself — you have to remember, which means it should be written down when granted.
- No automatic conflict detection. The system will not warn you that one person can both create suppliers and approve payments. Finding those combinations is a review you perform against your own role list.
- No approval workflow on permission changes themselves. An administrator changes access directly; the change is logged, not gated.
The pattern in that right-hand column is worth naming: the system enforces and records access decisions faithfully, and it does not second-guess them. That is the correct division of labour, but it means the quality of your access control is exactly the quality of your last review — and if you have never done one, that is the honest starting position.
Getting from "everyone is an admin" back to something defensible
If you are reading this because the description at the top is your situation, the fix is not a weekend project and it does not require starting over. It requires one uncomfortable list and then four ordinary weeks.
-
Print who has what, today
Every user, every role. Not to assign blame — to establish the actual starting position, which is almost always worse than the one people describe from memory. This list is the artefact everything else is measured against.
-
Remove the leavers first
Before any redesign, deactivate everyone who has left. It is the fastest reduction in exposure available, it needs no design decisions, and it is frequently the largest single group.
-
Name the two or three real administrators
Decide deliberately who genuinely needs to grant permissions. Write the names down. Everyone else comes off admin, and the reason for each of the two or three is recorded.
-
Rebuild roles from observed work, not job titles
Sit with each function for an hour and list what they actually do in the system. Roles built from that are close to right on the first attempt; roles built from an org chart never are.
-
Cut over one function at a time
One department per week, with someone available to fix gaps the same day. Gaps are fixed by adjusting the role — never by escalating the person, because that is precisely how you got here.
-
Set the review rhythm before you finish
A named person, a fixed date, the same printed list. Quarterly is enough for most businesses. Access control decays continuously and silently, and the only thing that stops the decay is somebody looking on a schedule.
The two-minute version of an access review
Sort your user list by permission count, descending. Read the top ten names and ask, for each, whether that person's job explains that much access. Then check the four combinations above against your role list. Most over-privilege in most businesses is visible in those two minutes — which is why not doing it is expensive rather than merely untidy.
The prerequisite nobody mentions
All of this assumes one person, one login. Where a shop, a branch or a whole shift shares a single account, roles are irrelevant — there is one identity doing everything, the audit trail attributes every action to a shared name, and no combination of permissions can separate what four people did. That failure is common enough in Kenyan retail and field operations to deserve its own treatment, in the shared login.
It is also the reason access control is upstream of almost everything else in this category. An audit trail is only as specific as its identities, personal data can only be restricted to people you can distinguish, and the Data Protection Act's security safeguards reduce, in practice, largely to who can reach what.
Our take
Design roles from the work rather than the org chart, keep administration to two or three named people, and replace roles on a job change instead of adding to them — that single habit prevents most over-privilege, because it accumulates rather than being granted. Then measure the combinations, not the counts: one person who can create a supplier and approve a payment is a bigger problem than ten people with broad read access. And book the quarterly review now, because nothing in the system will remind you, and access control is the only control that gets worse on its own.
See permissions, roles and the access log
Permissions as atoms and roles as bundles, enforced at the request rather than the menu, with permission changes, support impersonation and document access each recorded separately.
Explore roles & governanceFrequently asked questions
How many roles should a 20-person business have?
Fewer than twenty, and usually fewer than eight. Roles should map to distinct sets of work rather than to job titles, and in a small business several people genuinely do the same set of things even though their titles differ. The test is whether you can state in one sentence what a role is allowed to do — if you cannot, it is probably two roles that got merged, or a job title that got copied.
Is it really a problem if senior staff all have admin?
Yes, and the reason is not distrust. Administrator access means the ability to grant yourself anything, which removes the meaning of every other control — segregation of duties becomes decorative, and the audit trail records who did something without establishing whether they were entitled to. It also concentrates risk in whichever of those accounts has the weakest password. Two or three named administrators is not a statement about anyone's integrity; it is what makes the rest of the controls true.
What is the fastest way to reduce risk if we do nothing else?
Deactivate the leavers. It requires no design decisions, it is frequently the largest single group of over-privileged accounts, and dormant accounts belonging to people who no longer work for you are the most attractive thing on your system. After that, take everyone off administrator except two or three named people. Those two actions take an afternoon and remove most of the exposure.
How do we handle someone covering for a colleague on leave?
Grant the additional role, write down that it is temporary and when it ends, and put the removal in a calendar. There are no time-bound grants in the product — a temporary elevation will not remove itself — so the discipline has to live outside the system. This matters because cover grants are the single most common origin of permanent over-privilege: nobody revokes what nobody remembers granting.
Will the system warn us if one person has a dangerous combination of permissions?
No. There is no automatic conflict detection, so a person who can both create suppliers and approve payments will not be flagged. Finding those combinations is a review you run against your own role list, which is why the combinations checklist in this article is worth working through by hand at least once — and quarterly if you can.
