Skip to main content

Overview

Zenable uses Role-Based Access Control (RBAC) to manage who can do what within your organization. The system follows these principles:
  • Permissions are atomic actions (e.g., “edit requirements”)
  • Roles bundle permissions together (e.g., “Admin” has many permissions)
  • Users are assigned roles directly or via identity provider groups

Check your permissions from the CLI

Not sure whether you can do something? The Zenable CLI answers it directly. zenable auth can-i prints yes or no (and sets a matching exit code, so it’s scriptable) for any RBAC permission or MCP tool:
Every permission in the matrix below and every Zenable MCP tool is covered. --list shows them all at once with each one’s grant status.
Don’t have the CLI yet? See the installation guide.

System Roles

Zenable provides six predefined roles that cover common access patterns:
Custom roles are available on Enterprise plans. Contact us to learn more.

Groups

Groups are tenant-owned sets of users, created and managed on the Groups tab in Company Settings. They are referenced by GROUP requirement scopes (see groups:read / groups:write). A group can also contain other groups, so a scope on a parent group reaches members of its nested teams.
Group nesting is capped at 3 levels deep; members nested below that are not included.

RBAC Audit Logging

RBAC Audit logging is available on Professional and Enterprise plans only. Log exporting requires an Enterprise plan.
All role and permission assignments and revocations are logged for compliance, including any provided reason. Audit logs cannot be deleted by users regardless of role. Access audit logs via the Audit section in the management console or through the audit:read permission.

Role Permission Matrix

Permissions by Category

Requirements

Deleting a requirement is permanent and also deletes all guardrails associated with that requirement. This action cannot be undone.

Context

Scopes

Groups

Groups are tenant-owned sets of users referenced by GROUP requirement scopes. They are gated like scopes, since they’re only useful via scoping.

Guardrails

Findings

Reports

Users

Roles

Billing

Audit

Governance

Deleting a governance domain is permanent. Requirements mapped to the domain must be reassigned or explicitly unmapped as part of the deletion flow.

Integrations

Settings

Feature Flags

Marketplace

Approvals

Learn more about approval workflows.

Feedback

Company

Need help? Contact us at hello@zenable.io