Vanta has a two-tiered access system: organization-level (organization) and object-level (specific assignments) roles. Organization-level roles govern permissions across the platform. Object-level roles govern permissions on a particular object (e.g., a test, document, or risk), enabling rigid access control.
What are Org‑Level Roles?
Every user in your Vanta workspace has an org‑level role that governs their broad permissions at the workspace or organization level. Here are Vanta’s Org‑level roles:
-
Employee
- Users with the Employee role have access to complete their personal security and compliance requirements. By default, any person on the People page gets the Employee role. Users are added to the People page manually or through an IDP integration. Employees cannot be assigned to specific objects/tasks (such as tests or documents) within the Vanta Dashboard.
- The primary purpose of this role is to allow your personnel to complete their security onboarding and offboarding tasks within Vanta.
-
Collaborator: Same permissions as Employee plus:
- Can be assigned to objects (specific tasks or items within Vanta - a test, document, or risk)
- Can be assigned as a member of team
-
Privileged Roles (e.g., Admin, Editor, or a custom role*)
- These roles grant more extensive permissions across the Vanta workspace, beyond what a Collaborator has by default.
- An Admin can manage global settings, invite new users, change billing, etc.
- Custom Privileged roles can also be combined with object‑level roles on specific items to grant fine-grained access.
*Please note: Custom roles are available in the Scale package or as an add-on purchase if you have the Growth package.
What are Object-level roles?
Collaborator roles and above can be given object-level roles in Vanta. These roles layer on additional granular permissions, giving them access to assigned objects.
Understanding Vanta Objects
A Vanta object is any entity that’s created and managed within Vanta. These are the objects that have object-level roles enabled:
- Tests
- Documents
- Risk Scenarios
- Risk Tasks
- Systems within an Access Review
- Reports
Please note: Objects are distinct from Resources, which are pulled into Vanta from external integrations. Examples of resources: people, assets, inventory, and vulnerabilities.
Object-level roles
Vanta has three object-level roles:
- Owner of tests, documents, risk scenarios, and risk tasks
- Reviewer on systems within an access review
- Viewer on reports
Object-level roles grant sufficient permissions to perform their tasks, but do not grant full admin permissions on their object. For example, test owners can view test results, view remediation instructions, and create third-party tasks, but they cannot change control mappings or reassign ownership.
Please note: To be given an object-level role or above, a user must have the Collaborator org-level role. Employee users cannot be given object-level roles. Users who do not have object-level permissions will be grey in the owner drop-down, indicating they require a collaborator role or higher.
Using Org and Object-level Roles
Org-level roles grant more coarse, broad permissions. They determine what modules or pages the user can access by default without being assigned any object-level roles. For example, the Collaborator role by default grants access to the Personal Security tasks page and personal settings. The Editor role, by default, grants access to most pages in Vanta. If you have custom roles in your package, you can use custom roles to choose which modules a user can access, such as the Risk module, but a user with a custom role with the Risk permission enabled will have access to all Risk Scenarios.
In contrast, you can use object-level roles to achieve more fine-grained permissions. Use object-level roles if you only want the user to access specific items. For example, if you want a user to access only assigned Risk Scenarios, you’d give them the Collaborator role and assign them the Owner role on the Risk Scenarios you want them to access.
Permissions are additive. That means that when determining what a user has access to, Vanta looks at the sum of permissions granted via the user’s org-level role and any of their object-level roles. Let’s look at an example to understand this: a Collaborator user who is the Owner of a test.
- By default, the Collaborator role gives access to the Personal Security Tasks page (where users can complete assigned Personnel Tasks) and personal settings.
- Because the user also has the object-level owner role on a test, they can access the Tests list page, filtered to the test they have access to via their test Owner object-level role. The user can click on that test and view the test’s details page. For details on the permissions included in the test Owner object-level role, jump here.
If two permissions conflict, such as if a user’s org-level role says they can’t perform an action but their object-level role says they can, Vanta will apply the more permissive permission.
Managing Access
Managing org-level roles
- Employee users are managed on the People page
- All other users are managed on the User permissions page
Managing object-level access
You can manage access through the Manage Access modal on any object’s detail page (look for a “Manage Access”) where object-level roles are enabled. From there:
- View current owner
- Change owner—If you have sufficient permissions (e.g., Admin or existing Owner), you can unassign the current owner or give another user the Owner role on the object.
- Owners will also be visible and editable from the owner column (Tests, Risks, Access).
Please note: Currently, the Manage Access modal does not appear on Risks, Risk Tasks, and Systems within Access Reviews.
Org-level Roles Details
Employee | Collaborator | Editor | View-only Admin | Admin | |
Complete personal security tasks | ✅ | ✅ | ✅ | ✅ | ✅ |
Be a member or admin of a team | ❌ | ✅ | ✅ | ✅ | ✅ |
Access any of the following assigned items:
|
❌ | ✅ | ✅ | ✅ | ✅ |
Access to all Vanta capabilities except Admin-only capabilities (see row below) | ❌ | ❌ | ✅ | ✅ | ✅ |
Admin-only capabilities:
|
❌ | ❌ | ❌ | View-only | ✅ |
Examples of restricted documents include:
- Board of Directors meeting
- Background checks
- Exit interview
- Org chart
- Performance evaluations
- Contractor Agreement
- Employee agreement
Additional Customer Trust specific permissions:
Trust Collaborator | Trust Admin | |
Knowledge base | ||
View the knowledge base | ✅ | ✅ |
Edit the knowledge base | ❌ | ✅ |
Trust Center | ||
View all Trust Center content | ✅ | ✅ |
Manage external access to your organization's Trust Center | ✅ | ✅ |
Edit the Trust Center and settings | ❌ | ✅ |
Questionnaires | ||
Use the browser extension | ✅ | ✅ |
View & edit all questionnaires | ✅ | ✅ |
Approve answers in questionnaires | ❌ | ✅ |
Edit approved answers in questionnaires | ❌ | ✅ |
Approve questionnaires | ❌ | ✅ |
Mark questionnaires as complete | ❌ | ✅ |
Edit questionnaire settings | ❌ | ✅ |
Customers with the Scale package can also create Custom org-level roles. Learn more here.
Object-level Roles Details
Test Owner
Action | Permission |
Create tasks/task automation |
✅ |
Create comments | ✅ |
Download test result data | ✅ |
Unlink existing tasks | ❌ |
Manage subscriptions | ❌ |
Delete custom tests | ❌ |
Deactivate a test | ❌ |
Reassign test owner | ❌ |
Modify control mappings | ❌ |
Modify audit mappings | ❌ |
Document Owner
Action | Permission |
Renew, upload, and submit (or submit for approval) | ✅ |
Create a task | ✅ |
Delete prior versions | ✅ |
Create comments | ✅ |
Edit name & description | ❌ |
Mark document as sensitive | ❌ |
Unlink existing tasks | ❌ |
Assign approver | ❌ |
(available on custom Documents) Delete | ❌ |
Reassign Document owner | ❌ |
Modify Control mappings | ❌ |
Modify Audit mappings | ❌ |
Edit recurrence | ❌ |
Risk Scenario Owner
Action | Permission |
Edit Risk Category | ✅ |
Modify all other metadata | ✅ |
Complete risk assessment EXCLUDING control mappings | ✅ |
Create tasks | ✅ |
View & edit tasks linked to their risk scenario | ✅ |
Approve risk assessment | ✅ |
Reassign Owner | ❌ |
Modify control mappings | ❌ |
Mark as sensitive | ❌ |
Archive | ❌ |
Risk Task Owner
Action | Permission |
Export | ✅ |
Add notes & upload a file | ✅ |
Mark as complete | ✅ |
Delete | ❌ |
Change owner | ❌ |
Change due date | ❌ |
System Reviewer
Action | Permission |
Complete access review for assigned system | ✅ |
Create notes & tasks associated with an account | ✅ |
Change account owners | ✅ |
Remove system from review | ❌ |
Change owner | ❌ |
Report Viewer
Action | Permission |
View report schedules | ✅ |
Share with new users | ❌ |
Edit |
❌ |
Frequently Asked Questions
Can a Collaborator see all objects in Vanta?
- No. A Collaborator can see these objects they’re assigned to (with the object-level Owner, Reviewer, or Viewer role)
Can a user have more than one org-level role?
- No. Users can only have one org-level role, but they can have multiple object-level roles. If you want a user to have a custom set of org-level permissions, use our custom roles feature, available in the Scale package or as an add-on purchase in the Growth package.
What happens if a user has conflicting permissions?
- Permissions are additive, so Vanta will always look at the sum of the permissions defined in the user’s org and object-level roles. If two permissions conflict, Vanta gives the user the more permissive permission. For example, let’s look at a View-only admin that owns Risk Scenario A. View-only admins only have view access to Vanta and cannot edit any fields. However, because this user has been granted the object-level Owner role on Risk Scenario A, which grants the permission to edit some fields on Risk Scenario A, this user can edit those fields.
Updated