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 specific object (e.g., a test, document, or risk), allowing for precise 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. An object-level role defines a set of permissions on a particular object and mapped child objects. These roles provide additional granular permissions, granting users fine-grained 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:
Controls
Tests
Documents
Risk Scenarios
Risk Tasks
Systems within an Access Review
Reports
Some of these Objects have parent‑child relationships:
Control → Test
Control → Document
Risk Scenario → Risk Task
Please note: Objects are distinct from Resources, which are pulled into Vanta from external integrations. Examples of Resources include people, assets, inventory, and vulnerabilities.
Object-level roles
Vanta has three object-level roles:
Owner of controls, 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 assignments. You can upgrade an employee's permissions at any time from the Permissions page. Users who do not have object-level permissions will be grey in the owner drop-down, indicating they require a collaborator role or higher.
Object-level Roles and Access Inheritance
Vanta’s access rules respect a basic parent-child access inheritance model. If a user has object-level access to a parent object (for example, if the user is a Control Owner), the user gains equivalent privileges for its mapped child objects, plus the permission to modify child objects’ owners (in this case, Tests & Documents).
Here’s what this means in practice:
Being the Owner of a Control gives you the same permissions as Test & Document Owners on the Control’s mapped Tests & Documents. Control Owners also have the permission to modify the Owners of their Control’s mapped Tests & Documents.
Access does not propagate to peer, parent, or unrelated objects. For example, the Owner of a Control will not have access to mapped Risks or mapped Frameworks.
Below is a diagram illustrating how access propagates from parent to child objects (green arrows) or does not propagate (red Xs) across different parts of Vanta:
Please note: Access only flows from the parent object to the child object. It does not propagate from an object to other non-object pages in Vanta. For example, a Test Owner of a test that links to the Personnel page will not have access to the Personnel page via their Test Owner role. If that user needs access to the Personnel page, they will need an org-level role that grants access to that page.
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 grants access to the Personal Security tasks page and personal settings by default. The Editor role, by default, grants access to most pages in Vanta. If you have custom roles in your package, you can use them to choose which modules a user can access, such as the Risk module. However, a user with a custom role that includes the Risk permission 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. This means that when determining what a user has access to, Vanta considers the sum of permissions granted through 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 grants access to the Personal Security Tasks page, where users can complete assigned personnel tasks and personal settings.
Because the user also holds the object-level owner role on a test, they can access the Tests list page, which is filtered to display only the tests to which they have access via their test Owner object-level role. The user can click on that test and view the test’s details page. For details included in the test owner object-level role, click here.
If two permissions conflict, such as when a user’s org-level role prohibits an action but their object-level role allows it, 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: The Manage Access modal currently 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:
| ❌ | Assigned objects only, and any mapped child objects | ✅ | ✅ | ✅ |
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
Control owner
Action | Permission |
Create comments | ✅ |
Permissions on mapped tests & documents | Same as Test & Document owners, plus the permission to modify Test & Document owners |
Reassign Control Owner | ❌ |
Add new custom documents | ❌ |
Modify test & document mappings | ❌ |
Modify risk mappings | ❌ |
Modify framework mappings | ❌ |
Export control | ❌ |
Export evidence | ❌ |
Delete control | ❌ |
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) and mapped child objects
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.