Roles and Permissions
CloudAnzen uses role-based access control to keep sensitive security and compliance work limited to the people who need it. Good role design helps you move faster because owners can complete their tasks without giving everyone full administrative access.
Role assignment should reflect what a person needs to do in the platform. A senior title does not always mean admin access is required, and a contributor may need action permissions for only a specific set of work.
Available Roles
| Role | Best fit | Typical responsibilities |
|---|---|---|
| Owner | Founder, security executive, or primary workspace owner | Organization-level access, billing, high-risk administrative changes, final ownership decisions |
| Admin | Security lead, compliance lead, or GRC operator | Team management, integrations, frameworks, controls, reports, and workspace configuration |
| Compliance Manager | Person running the compliance program | Controls, evidence, policies, risks, vendors, audits, readiness tracking |
| Contributor | Engineering, IT, HR, legal, vendor, or operations owner | Assigned Todo work, evidence uploads, remediation updates, request responses |
| Viewer | Executive, observer, or read-only stakeholder | Dashboards, reports, and shared materials without edit permissions |
Common Role Assignments
Use these examples as a starting point:
- Security or compliance lead: Admin or Compliance Manager.
- Infrastructure owner: Contributor, unless they also manage integrations.
- HR owner: Contributor for personnel controls, training, and policy evidence.
- Legal or privacy owner: Contributor or Compliance Manager depending on scope.
- Engineering manager: Contributor for change management, code review, and remediation tasks.
- Executive sponsor: Viewer unless they need approval or owner-level control.
- External auditor: Viewer or auditor-specific access where available, depending on the audit workflow.
Principle of Least Privilege
Give each user the minimum access needed to complete their work. This reduces accidental changes and makes audit trails cleaner.
Practical examples:
- Do not make every control owner an Admin.
- Do not give integration management access to people who only upload evidence.
- Use Viewer for people who only need dashboards or reports.
- Review Admin access periodically.
- Remove access for people who leave the project or company.
Permission Boundaries to Watch
Some areas are more sensitive than others:
- Integrations can expose infrastructure and identity configuration.
- Policies may include internal security commitments.
- Audits may include customer or auditor communications.
- Risks can include sensitive business impact details.
- Vendor records may include contracts, security reports, and review decisions.
- Trust Center content may become visible to customers.
Changing Roles
Owners and Admins can change a user's role from Settings -> Team. Click the role badge next to a user's name and choose the new role.
Before changing a role, check:
- Does this user still own active work?
- Will the new role remove access they need for assigned tasks?
- Should someone else receive their open assignments?
- Does the role change affect policy approvals, audit requests, or evidence ownership?
- Should the change be documented for audit purposes?
Offboarding Users
When someone leaves the company or no longer participates in compliance work:
Working with Auditors
Auditors usually need focused access to audit materials, not broad workspace administration. When possible, give auditors access only to the audit, evidence, reports, and requests relevant to their engagement.
For external auditors:
- Confirm which audit they are reviewing.
- Limit access to the engagement scope.
- Use audit requests to collect follow-up evidence.
- Keep comments and request responses inside the audit workspace.
- Remove access after the engagement closes if no longer needed.
Role Review Cadence
Review roles at least quarterly, and always before a major audit. During review, check:
- Admin and Owner users.
- Inactive users.
- Users with no current assignments.
- External users.
- Former employees or contractors.
- Users who changed job functions.
Custom Roles
Enterprise plan customers can create custom roles with more granular permissions. Custom roles are useful when you need to separate responsibilities such as integration administration, policy approval, risk management, vendor review, or audit collaboration.
Before creating custom roles, document:
- Which actions each persona needs.
- Which data each persona should not see.
- Who approves role changes.
- How often custom role membership is reviewed.
- Whether the role affects audit evidence or customer-facing materials.