> For the complete documentation index, see [llms.txt](https://framework.aic.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://framework.aic.io/security-vetting-and-technical-assurance-playbook/identity-access-and-zero-trust/rbac-model.md).

# 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.