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:
--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 byGROUP 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.
audit:read permission.
Role Permission Matrix
Permissions by Category
Requirements
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
Integrations
Settings
Feature Flags
Marketplace
Approvals
Learn more about approval workflows.
Feedback
Company
Need help? Contact us at hello@zenable.io