Role-based access is only useful when the roles match the work

A role named “privacy administrator” tells you little about what its holder should be allowed to do. Can that person view identity evidence, change consent records, export cases, approve deletion or configure integrations? Those capabilities should not arrive as an unexplained bundle.

Useful roles describe work. Start with the decisions and actions people perform, then assign permissions at the level the application can enforce.

List tasks before naming roles

A hypothetical privacy request service has frontline staff who receive requests, case owners who investigate them, reviewers who approve sensitive decisions and technical operators who maintain integrations.

The tasks overlap, but they do not require identical access. A technical operator may need to restart a failed worker without reading the customer’s supporting documents. A reviewer may need a case summary without permission to change the underlying request.

Create a task inventory with the resource, action and necessary context. “View case” is still broad: viewing a status, reading correspondence and opening identity evidence may deserve separate treatment.

OWASP’s authorisation guidance recommends least privilege, default denial and permission validation on every request. These principles apply to ordinary interface actions, API requests and exports.

Use an access matrix to expose assumptions

A small matrix makes the proposed design easier to challenge:

Task	Candidate access	Boundary to test
Receive a request	Create a case and view its receipt	Cannot browse unrelated cases
Investigate a case	Read assigned evidence	Cannot change approval history
Review a decision	Read the relevant record and approve	Cannot silently rewrite evidence
Maintain an integration	View operational status and retry work	Cannot export customer payloads

These are design proposals for the hypothetical service, not universal role definitions. A small organisation may combine responsibilities, but the permissions and accountability should still be explicit.

Ask a representative worker to complete the task using the proposed role. Record any request for extra access and whether it reflects a genuine task requirement or a convenient shortcut. That exercise can reveal missing narrow permissions before a broad administrator role becomes the default.

Where one person holds several roles, evaluate the combined access. Two modest roles can together permit an action that neither was intended to allow alone.

Add resource scope and context

A role can describe what kind of action is permitted while resource scope determines where it is permitted. A case investigator may be authorised only for assigned cases or one business unit.

For a multi-tenant service, tenant membership must be verified independently of a caller-supplied identifier. OWASP’s multi-tenant guidance addresses trusted tenant context and consistent enforcement across the application.

Some decisions also depend on context, such as whether a case is closed or whether a second approval is required. If the role model cannot express an important condition, add an explicit policy check rather than creating an ever-growing collection of nearly identical role names.

Enforce the policy at the service boundary. Hiding a button can improve the interface, but it does not prevent a direct request to the underlying operation.

Design exceptional access honestly

Urgent investigations may require temporary additional access. Give that path a purpose, an authorised approver where appropriate, a defined duration and a record of use.

Avoid a permanent shared “emergency” account whose activity cannot be attributed. Temporary access should be removable, and its expiry should be tested.

Review the evidence available to the approver. If every request says only “business need”, approval becomes a habit rather than a decision. Ask for the specific case or operational problem and the minimum additional capability required.

Exceptional access should not erase ordinary auditability or grant unrestricted access to unrelated tenants.

Test the lifecycle of a role

Access design is incomplete until it handles a person joining, changing responsibilities and leaving. A promotion should not automatically preserve every earlier permission.

Create test accounts for each intended role and for meaningful combinations. Exercise both allowed and denied operations through the interface and API.

The acceptance checks should include:

• Roles map to named tasks and necessary fields.
• Resource scope is enforced on each request.
• Exports and background actions follow the same policy.
• Combined roles do not create unintended capabilities.
• Temporary access expires and remains attributable.
• Role removal invalidates relevant sessions or cached permissions as designed.

A smaller role catalogue can be stronger than an elaborate one if its boundaries match the work. The evidence that matters is whether each person can complete the assigned task and is reliably prevented from reaching unrelated data or actions.