RBAC Model

Purpose

Role-Based Access Control uses defined roles to grant permissions. It is the baseline model for repeatable access management because it is clear, auditable and easy to explain.

Role Design

A role must represent a real business or delivery responsibility. It must not be created merely to work around an approval process.

Each role must have:

• role name;

• role purpose;

• business owner;

• permission set;

• systems covered;

• data classification permitted;

• approval route;

• separation of duties constraints;

• review cadence;

• offboarding rule.

Role Examples

Role	Typical permissions	Restrictions
Delivery Lead	View project plans, risks, reporting and delivery evidence.	No production admin by default.
Developer	Access development repositories and development environments.	No direct production write access by default.
DevOps Engineer	Manage pipelines and infrastructure code.	Production changes require change approval.
Security Lead	View security evidence, risks and audit logs.	Does not own business acceptance of risk.
Customer Reviewer	View deliverables and acceptance evidence.	No edit access to internal working repositories unless agreed.
Supplier Contributor	Access only approved work package material.	Time-bound and contract-bound access.

RBAC Process

1. Define standard project roles during mobilisation.

2. Map roles to systems, repositories, data sets and environments.

3. Remove unnecessary permissions from default roles.

4. Test separation of duties.

5. Assign users only after screening and approval.

6. Review role membership at project gates and at least quarterly for sensitive systems.

7. Remove access at role change, project exit or contract end.

Anti-Patterns

• creating roles for individual convenience;

• assigning admin rights to broad delivery roles;

• using shared accounts;

• leaving supplier accounts active after work ends;

• granting direct permissions that bypass the role model;

• failing to document role owners.