Role-Based Access Control in Kenya: Build a Permission Matrix First

Role-based access control (RBAC) gives people permissions through defined roles instead of configuring every employee one by one. That sounds simple until a requirement says “manager access” without explaining which records a manager can see, which changes they can make, whether they can approve their own work or who reviews access after someone changes job.

For a Kenyan or East African business planning custom software, a dashboard or workflow automation, the most useful RBAC deliverable is not a list of job titles. It is a permission matrix that connects responsibilities to specific actions and record boundaries. This guide shows operations, finance, programme and technology teams how to prepare that matrix before development begins.

What RBAC should solve

In a role-based model, a role groups the permissions needed to perform a business responsibility. Users receive one or more authorised roles, and every protected request is checked against the applicable permissions. Roles make access easier to assign and review when responsibilities are reasonably stable and many people perform similar work.

RBAC does not remove the need to define the work. “Administrator”, “officer” and “manager” are labels, not access rules. A dependable design still needs to state the resource, action, record scope, business condition and evidence required for each decision.

Start with a permission-matrix structure

Place roles down the rows and permissions across the columns. Split broad verbs into reviewable actions such as view, create, edit, submit, approve, cancel, export and administer. Add a separate scope field for “own records”, “assigned branch”, “programme”, “region” or “all authorised records”.

This is an illustrative shape, not a ready-made policy. Replace the roles, actions, limits and scopes with the organisation’s actual workflow. A small system may need fewer roles; a high-risk workflow may need more separation and context than a role alone can express.

10 decisions to make before implementation

1. Map decisions and records before naming roles

List the records the workflow creates or changes and the decisions that move them forward. For an approval process, that may include drafting, submitting, returning, approving, rejecting and reopening. For a dashboard, it may include viewing summary metrics, drilling into identifiable records, exporting detail and changing metric configuration.

This prevents the matrix from becoming a copy of the organisational chart. Software permissions should follow system responsibilities, not status alone.

2. Define roles from stable responsibilities

Use roles that several people can understand and that remain meaningful when staff change. A “regional reviewer” may be stable; “Mary’s access” is not. Record the owner of each role, its purpose, eligibility and the conditions for assignment.

Avoid creating a new role for every small exception. Too many near-identical roles are difficult to test and review. Where the main responsibility is the same but the records differ, keep one role and express the record boundary separately.

3. Split permissions into specific actions

“Manage orders” or “access finance” is too broad. Separate view, create, edit, approve, refund, cancel, export and configuration. A person may need to correct an address without changing price, issue a report without viewing every personal field, or approve a request without changing the request they received.

Specific permissions also make acceptance testing clearer. Each allowed and denied action can become a test scenario instead of relying on an informal understanding of a broad role.

4. Add record scope to every important action

Permission to view a record does not automatically mean permission to view every record of that type. Define whether access covers the user’s own work, assigned cases, a branch, a project, a county, a customer portfolio or the whole organisation. State how that scope is derived and what happens when a record moves between units.

For dashboards, separate access to aggregated metrics from access to supporting identifiable records. A leadership summary may be widely useful while row-level detail remains restricted.

5. Separate incompatible duties

Identify actions that should not be completed by the same person in the same case. Examples can include requesting and approving a payment, preparing and releasing a bulk export, or creating an account and approving its privileged role. The relevant separation depends on the organisation’s risk and operating policy.

Decide whether the rule is static—one person may never hold both roles—or dynamic—the person may hold both responsibilities but cannot complete both steps for the same transaction. Make override conditions explicit and reviewable.

6. Isolate privileged administration

Managing users, roles, system configuration, integrations or audit settings is different from ordinary business work. Create named administrative responsibilities instead of giving every senior user a universal account. Require appropriate reauthentication and approval for sensitive changes where the risk justifies it.

Administration should also be limited by scope. A branch administrator may manage users for one branch without reading finance records or changing organisation-wide configuration.

7. Deny by default and check every request

When no rule explicitly permits an action, the system should deny it. New screens, APIs, exports and background operations need the same authorisation policy as the visible interface. Hiding a button is useful for clarity but is not an access-control decision; the server must still verify the request.

Return a safe response when access fails and record enough information for authorised support without exposing sensitive data. Permission checks should be consistent across web, mobile and integration paths.

8. Plan joiner, mover, leaver and temporary access

Define who requests access, who approves it, how identity is verified and when the assignment takes effect. Role changes need the same discipline as new accounts. When someone transfers teams, old access should not remain simply because the new role was added.

Temporary cover, contractor access and emergency elevation need an expiry time and a named reviewer. Dormant accounts, shared logins and unowned service accounts make later investigation and removal much harder.

9. Make important access decisions reviewable

Record role assignments, removals, privileged changes, approvals, exports and access failures appropriate to the workflow. An audit record should identify the actor, action, affected resource, time and relevant business context without copying secrets or unnecessary personal data into logs.

Agree who reviews these records, what exception they are looking for and how long evidence remains useful. Collecting a large log that nobody can interpret is not the same as operational accountability.

10. Test allowed and denied paths

For each role, test the actions it may perform and the ones it must not perform. Include direct URL or API requests, guessed record identifiers, cross-branch records, changed ownership, expired temporary access, revoked roles and failure after a record changes state.

Repeat the permission review when features, integrations, business structures or policies change. The software handover checklist also helps confirm that role definitions, administrative accounts and test evidence transfer with the system.

When role-based access is not enough

A role may answer what responsibility a user has, but some decisions also depend on the record, relationship, time, location, risk or transaction state. An approval may require a value limit; a case worker may see only assigned households; a clinician may need a care relationship; a contractor may have access only before an expiry date.

Do not create hundreds of combination roles to encode every condition. Keep stable responsibility in the role and model necessary attributes or relationships separately. The design should remain understandable to the people who approve and review access, not only to developers.

A permission-matrix acceptance checklist

• Every role has a purpose, owner and assignment rule.
• Every important permission names a resource and specific action.
• Record scope is explicit for view, change, approve and export.
• Incompatible duties and override conditions are documented.
• Privileged administration is separate from ordinary work.
• Unmatched requests are denied and server-side checks cover every interface.
• Temporary access expires and transfers remove obsolete roles.
• Important assignments and actions create proportionate audit evidence.
• Positive and negative tests cover cross-scope and direct-request attempts.
• A named owner reviews the matrix after organisational or product change.

Connect permissions to the wider system scope

Permissions affect interface design, database queries, exports, approvals, notifications, integrations, testing and support. Include them in discovery instead of adding an “admin panel” near the end. The MVP scoping guide helps place roles beside users, data and acceptance; the business dashboard guide helps distinguish summary access from record-level detail.

For workflows that cross systems, use the API integration guide to define service-account permissions, credential ownership and failure handling. A person’s role in one application does not automatically authorise an integration to copy every field elsewhere.

Frequently asked questions