Introduction
Bringing the right team members into Complyance is key to successful platform adoption. Complyance supports Role-Based Access Control (RBAC), which ensures users have the appropriate level of access based on their role.
RBAC helps limit access to sensitive information, supports audit readiness, and simplifies user management by allowing you to assign a role instead of configuring individual permissions.
This article outlines user roles in Complyance, the most common roles used in the platform and how they typically function. To learn how to create or edit a user role, see: How to Create New User Roles.
Complyance System Roles
When you first access your environment, you’ll find three default system roles already available: Admin, Auditor, and Member. These can be used as-is or you can create customized roles to meet your organization’s specific needs.
- Admin: Full access to the entire platform. Can create and edit all content, including risks, controls, vendors, evidence, policies, and reports. Admins can also manage user roles and configure integrations.
- Auditor: Read-only access across most of the platform. Can view all controls, evidence (including confidential evidence), risks, vendors, tasks, and policies. Ideal for external or internal audit teams.
- Member: Default role for new users. Members can view and edit all controls and evidence, create general evidence, view and edit risks (but only delete their own), view vendors and tasks, and edit their own tasks. Members can also view and create reports but cannot manage roles or programs.
Tip: We recommend creating custom roles for new users that are aligned to the specific roles of your team members and their workflows.
Common Custom Roles
Complyance supports unlimited custom roles, giving you flexibility to match platform access to your internal responsibilities.
Roles span across modules (e.g., controls, risks, vendors) and key areas (e.g., reports, tasks, settings). Below are some of the most common examples.
Note: Depending on your Complyance instance, some modules may not be visible in your environment. However reports, tasks and settings are visible to everyone.
Platform-wide Roles
View Only
A read-only role across the entire platform. Users with this role can view content—including controls, risks, vendors, evidence, tasks, reports, and policies—but cannot make edits.
Commonly used as the onboarding role before adjusting access.
Permissions to activate:
- Controls: View own controls & View all controls
- Evidence: View evidence
- Programs: N/A
- Risk management: View own risks & View all risks
- Vendor management: View own vendors & View all vendors
- Reports: View all reports
- Roles: N/A
- Task management: View assigned tasks & View all tasks
- Policies: View all policies
- Integrations: N/A
Owner (View Only)
An assigned owner can only view the entities assigned to them across the platform, for example if you only have the risk module the assigned owner would be able to view risks assigned to them but not make edits to the risk. They would also be able to view the assigned tasks, but not edit the details of the task.
An example of this would be for a Risk Owner/approver - where actions are managed via tasks - but the user does not have edit access to a record.
Permissions to activate:
- Controls: N/A
- Evidence: N/A
- Programs: N/A
- Risk management: View own risks
- Vendor management: N/A
- Reports: N/A
- Roles: N/A
- Task management: View assigned tasks & Edit assigned tasks
- Policies: N/A
- Integrations: N/A
GRC Team Member
Designed for team members who should have capabilities across all of their working modules. This role provides view and edit access to existing records across assigned modules but restricts users from creating new inputs or modifying platform-level settings.
Permissions to activate:
- Controls: All toggled on EXCEPT: Create controls & Create and edit fields for controls
- Evidence: All toggled on EXCEPT: Edit confidential evidence & Create and edit fields for evidence
- Programs: N/A
- Risk management: All toggled on EXCEPT: Create and edit fields for risks
- Vendor management: All toggled on EXCEPT: Create and edit fields for vendors
- Reports: All toggled on
- Roles: N/A
- Task management: All toggled on EXCEPT: Create and edit fields for tasks
- Policies: All toggled on EXCEPT: Create and edit fields for policies
- Integrations: N/A
Module-Specific Roles
It is common to create roles based on ownership of specific modules. These roles are most commonly used to limit access to specific modules, but to allow a broad set of permissions. These users should be able to view, create, and edit within their assigned module(s), and have limited or view-only access to other areas.
Examples:
- Controls Manager – Full access to controls; view-only access to risks, tasks, or policies.
- Policy Manager – Manage all policy content; view-only access to related tasks or controls.
- Risk Manager – View and edit Risks and complete associated tasks; View or Edit access to controls and vendors to form links as configured.
- Vendor Manager - View and edit Vendors and send Questionnaires to Vendors; Edit access to Risks to form links as configured; Edit access to tasks.
These roles can also have access to view all reports and tasks, and edit tasks that are assigned to their role.
Module-Specific Roles with Ownership Limitations
Many clients prefer to restrict roles even further to limit workflows to only the essential access. This is achieved by adding ownership constraints to the roles. Ownership constraints are further separated by action limits:
- View own - only allows users to see entities they are the owner of, they will see no other elements of the platform and will have no edit access.
- Edit own - allows users to edit entities they are the owner of.
A common combination here is for a member of a related team, for example a Privacy or Internal Audit team.
- Privacy/Internal Audit Team Member - Edit own controls; View-only access to all controls; View and Edit own tasks; View Risks.
The most common roles we see with these constraints are:
- Control Owner – View and Edit access to own controls; view-only access to risks; View and edit own tasks.
- Policy Owner – Manage all policy content; view-only access to related tasks or controls.
- Risk Owner – View and Edit own risks; View and edit own tasks; no access to controls or vendors unless configured.
- Vendor Owner - View and edit Vendors and send Questionnaires to own Vendors; View only access to tasks and risks as configured.
Permissions for Reports, Tasks and Settings
Reports
Most teams allow all users to see reports in platform. Users who have editing access in any module are often granted the ability to create and manage reports. This supports cross-functional insights and visibility
Task Center
Task access is commonly granted to all users—regardless of role. Users can:
- View and complete tasks assigned to them.
- Create and assign tasks if permitted.
Elevated Task Permissions: Many clients create roles with task-only access because Complyance’s automated task workflows (email when assigned, email back to creator when done) is great for GRC task management. This role is ideal for team members who don’t own records but frequently complete or assign tasks.
Settings
The Create and Edit Roles permission is reserved for users with administrative responsibilities. This allows them to manage role creation, assign permissions, and configure access.
Caution: Only grant this to platform administrators
Important: Role Stacking
Complyance does not support assigning multiple roles to a single user. This avoids potential conflicts between overlapping and conflicting permissions.
As Complyance allows an unlimited number of custom roles, you can create combined roles depending on the remit of each user. For example, we commonly see the following combinations, though any combination is possible:
Control and Risk Owner - View and edit Own Controls and Risks; View and edit own tasks; View Policies ; Edit reports.
Risk Owner and Vendor User - View and edit Own Risks; View all Vendors; View and edit own tasks.
Summary
Complyance roles give you the flexibility to define access across the platform in a way that supports your internal teams, maintains data security, and enables smooth operations.
The roles outlined here are a starting point—your Complyance Implementation Lead can help you tailor access to meet your organization's exact needs
Still have questions? Reach out to our support team via the Support Center for assistance.