> ## Documentation Index
> Fetch the complete documentation index at: https://docs.matproof.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Roles & Permissions

> Role-based access control in Matproof — five built-in roles plus organization-defined custom roles.

# Roles & Permissions

Matproof uses role-based access control to ensure team members only see and do what their role requires. Every team member is assigned exactly one role per organization.

## Built-in roles

Matproof ships five built-in roles. These cover most team structures and cannot be deleted.

| Role           | Typical user                                        | What they can do                                                                                    |
| -------------- | --------------------------------------------------- | --------------------------------------------------------------------------------------------------- |
| **Owner**      | Founder, CEO, organization creator                  | Everything: settings, billing, role management, delete organization                                 |
| **Admin**      | CISO, compliance lead, head of security             | Everything except billing and deleting the organization                                             |
| **Auditor**    | External auditor, internal audit team, board member | Read-only across the program — view controls, evidence, policies, reports — cannot create or modify |
| **Employee**   | Engineering, finance, HR, operations team members   | Submit evidence, complete assigned tasks, acknowledge policies, view their own assignments          |
| **Contractor** | External consultant, agency, temporary staff        | Same as Employee but flagged as non-employee for offboarding and access-review evidence             |

The Auditor role is intentionally narrow — assign it to external audit firms during an audit window so they can review your program without modifying it. The Employee and Contractor roles are intentionally similar in product capability; the distinction is for audit reporting (some frameworks require contractor counts to be tracked separately).

## Assigning a role

<Steps>
  <Step title="Open the team member's profile">
    Go to **People** and click into the team member.
  </Step>

  <Step title="Set their role">
    Click **Role** and pick from the five built-in roles or any custom role your organization has defined.
  </Step>

  <Step title="Confirm">
    The new role takes effect immediately. The change is recorded in the [Audit Trail](/features/audit-trail).
  </Step>
</Steps>

## Custom roles

If the five built-in roles don't fit, define custom roles with a tailored permission set. Common patterns: an "Evidence Reviewer" who can approve evidence but not modify frameworks, a "Department Lead" who can manage their team's controls without seeing the rest of the program, or a "Vendor Manager" focused on the vendor-risk module.

### Creating a custom role

1. Go to **Settings → Roles & Permissions**
2. Click **New role**
3. Name it (e.g. "Evidence Reviewer", "DPO Read-Only", "Vendor Owner")
4. Pick the permissions to grant — toggles per module (Frameworks, Controls, Policies, Evidence, Risks, Vendors, Audit Programs, etc.) with View / Create / Edit / Delete / Approve actions
5. Save — the custom role is now assignable to team members

### Best practices for custom roles

* **Start narrow.** Grant the minimum permissions needed; widen only when someone hits a wall. It's easier to grant more access than to reclaim it.
* **Don't recreate the built-ins.** If you need "everything except billing," use Admin. If you need "read-only," use Auditor.
* **Document the role's purpose** in the description field so future admins know why it exists.

## Audit trail

Every role assignment, custom-role definition, and permission change is recorded in the [Audit Trail](/features/audit-trail) with timestamp, actor, and the before/after state. Most frameworks (ISO 27001 A.5.15–A.5.18, DORA Article 9, NIS2 Article 21, SOC 2 CC6.1) require this evidence — Matproof produces it automatically.

## Best practices

* Keep **Owner** to one or two people; treat it like root access
* Default new team members to **Employee**; promote to **Admin** only when needed
* Use **Auditor** for external auditors; revoke after the audit window closes
* Review role assignments quarterly — assign the review as a [corrective action](/features/corrective-actions) so the review itself is documented

<CardGroup cols={2}>
  <Card title="People" href="/features/people">
    Add team members, assign roles, manage devices
  </Card>

  <Card title="Audit Trail" href="/features/audit-trail">
    Where all role changes are logged
  </Card>
</CardGroup>