Roles and permissions

Overview

VerifyWise uses role-based access control (RBAC) to manage what users can see and do. Each user gets a role that sets their permissions across all features. You can use one of the four built-in roles or create custom roles for your organization.

Understanding roles helps you make sure team members have the right access level for their responsibilities while keeping security tight.

Available roles

VerifyWise has four built-in roles. Their permissions are fixed. They can't be renamed or deleted. If none of them fits, create a custom role (see "Custom roles" below).

Admin role

Admins have full control over the platform. This role is for users responsible for platform governance and user management.

Admin capabilities:

• Full access to all platform features
• Create, edit and delete use cases and assessments
• Manage models, vendors, policies and training records
• Invite new users and change user roles
• Configure organization settings and branding
• Set up and manage integrations (Slack, MLflow)
• Create and manage API keys
• Generate all report types
• Access all settings tabs

Reviewer role

Reviewers can view content, approve or reject items assigned to them and upload evidence files, but they can't create or edit content. This role works well for people who need to sign off on governance activities without authoring them.

Reviewer capabilities:

• View use cases, assessments and compliance status
• Approve or reject items in approval workflows where they are an assigned approver
• Approve or request changes on policies they are assigned to review
• View models, vendors, risks, policies and training records
• Upload and manage evidence files
• View reports
• Access dashboard
• Update personal profile and preferences

Reviewers can't:

• Create, edit or delete use cases, models, vendors, risks, policies, tasks or training records
• Invite users or manage team members
• Edit organization settings
• Generate reports
• Access integrations or API keys

Editor role

Editors can work with most platform content but have limited access to admin functions. This role fits team members who contribute to governance activities without needing full system control.

Editor capabilities:

• Create, edit and delete use cases and assessments
• Create, edit and delete models, vendors, risks and policies
• Create tasks
• Create and edit training records
• Upload and manage evidence files
• View organization settings
• Run report templates and scheduled reports
• Access most settings tabs

Editors can't:

• Invite users or manage team members
• Edit organization settings
• Delete training records
• Manage integrations (Slack, MLflow)
• Create or delete API keys
• Change their own role

Auditor role

Auditors have read-only access to the platform. This role is meant for people who need to review governance information without changing anything, like external auditors or compliance reviewers.

Auditor capabilities:

• View use cases, assessments and compliance status
• View models, vendors, risks, policies and training records
• View reports (can't generate new ones)
• Access dashboard
• Update personal profile and preferences

Auditors can't:

• Create, edit or delete any content, including evidence files
• Invite users or manage team members
• Edit organization settings
• Generate reports
• Access integrations or API keys

Custom roles

A custom role belongs to your organization. You name it and decide, permission by permission, what it may do. Manage custom roles in the Roles tab under Settings. Only Admins see this tab by default; a custom role can get it too if you allow its "Create, update and delete custom organization roles" permission.

Create a custom role

1. Go to Settings > Roles
2. Click New role
3. Enter a name and a description. Both are required, up to 255 characters each
4. Click Create role. The new role is selected and its permission list opens

A name can't match a built-in role (Admin, Reviewer, Editor, Auditor) or another role in your organization. The form checks this before saving, ignoring case.

Choose what the role can do

Permissions are grouped by area, such as Use cases, Risks or Groups. Each row shows the permission and a short description of what it covers. A new role starts with every permission set to Deny.

1. In Settings > Roles, select the role from the row of role buttons
2. Set each permission to Allow or Deny
3. Click Save permissions. The button is disabled until you change something

Rename or edit a custom role

Select the role and click Edit to change its name or description, then click Save changes. If you rename it, everyone with that role has to sign in again.

Delete a custom role

Select the role, click Delete, then confirm with Delete role. Its permission settings are removed along with it.

What custom roles don't change

• Built-in roles keep their permissions. You can't edit, rename or delete them
• Only Admins see every use case. People with a custom role see the use cases they own, are a team member of or reach through a group

These areas still need the built-in Admin role, whatever you allow: Settings > Team, Settings > Features, Settings > MCP, the LLM Evals API keys and evals settings, AI Trust Index settings, intake form routing and acting in any review lane, downloading files, the demo data menu and the "All tasks" view. Managing evidence folders needs the built-in Admin or Editor role.

Four permissions only change what the screens show. The server doesn't check them yet: "Choose a use case's team members", "Edit framework controls and answers, and add or remove frameworks", "Record audit results on framework controls" and "Create and change eval projects, experiments, scorers and datasets". Their descriptions in Settings > Roles say so.

Assigning roles

Built-in and custom roles are assigned the same way, in one of two places:

During invitation

When inviting a new team member, select the appropriate role in the invitation modal. The list includes your custom roles. The user will have this role when they create their account.

Changing an existing user's role

To change a user's role after they've joined:

1. Go to Settings > Team
2. Find the user in the team table
3. Click on the role dropdown in their row
4. Select the new role
5. The change takes effect right away

Permission reference

Here's a summary of key permissions by role:

Admins see every use case in the organization. Other roles, custom roles included, see the use cases they own, are a team member of or reach through a group attached to the use case. Likewise, Admins see every task, and other roles see the tasks they created or are assigned to.

"Approve" means approving or rejecting items where the user is an assigned approver in an approval workflow. Anyone assigned as an approver can act on that step, whatever their role. "Review" means approving or requesting changes on a policy the user is assigned to review.

Best practices

• Limit admin accounts: Only give the Admin role to users who need full platform control. Most users should be Editors, Reviewers or Auditors.
• Review roles regularly: Check user roles from time to time to make sure they still match current responsibilities.
• Use Auditor for external access: For external auditors or stakeholders who need to review your governance, use the Auditor role.
• Document role decisions: Keep a record of why users were assigned specific roles for audit purposes.

Frequently asked questions

Can I create custom roles with specific permissions?

Yes. Go to Settings > Roles, click New role, then set each permission to Allow or Deny. The four built-in roles are unchanged.

Can I change my own role?

No. Another administrator has to update your role. This prevents accidental loss of admin access.

How many administrators should we have?

At least two is a good idea, so there's always a backup if one admin is unavailable. But keep the total number low and limited to people who truly need full access.