Users & roles
Cerynix enforces role-based access control on every request, server-side — the UI hides actions you cannot perform, but the backend is the actual gate. There are five fixed system roles per organization (no custom roles yet). This page is the full permission matrix; for the click-by-click invite flow during initial setup, see the install guide's user step.
The five roles
| Role key | Name | Description |
|---|---|---|
admin | Organization Administrator | Full access to the organization, members, settings and all modules. The only role with org:manage, members:manage, settings:manage, webhook:manage and token:manage. |
security_manager | Security Manager / CISO | Owns the compliance programme: controls, evidence, risk, nonconformities/CAPA, management review, tasks, suppliers, incidents, connectors, reports. Cannot manage members or organization settings. |
it_manager | IT Infrastructure Manager | Executes remediation: assesses controls, writes evidence, owns assets/exposure and tasks, manages connectors. Narrower than Security Manager — no approvals, no management review, no report generation. |
auditor | Auditor / Consultant | Read-only across every module, plus audit-log visibility, report generation and AI assistant use. Cannot write, approve, or manage anything. |
executive | Board / Executive | Oversight: dashboards, reports, control approval, risk acceptance and nonconformity residual-risk acceptance — deliberately the only non-admin role with acceptance authority. |
apps/api/app/services/rbac.py — the single source of
truth the backend actually enforces, not a separately-maintained description that
can drift from the code.
Full permission matrix
admin holds every permission below (omitted from its own
column for brevity — assume ✓ everywhere). A blank cell means that role does not
have the permission; the UI hides the corresponding action for that role, and the
API rejects it (403) even if called directly.
| Permission | Security Manager | IT Manager | Auditor | Executive |
|---|---|---|---|---|
| Organization & members | ||||
org:read | ✓ | ✓ | ✓ | ✓ |
org:manage | — | — | — | — |
members:read | ✓ | — | ✓ | — |
members:manage | — | — | — | — |
settings:manage | — | — | — | — |
| Onboarding | ||||
onboarding:manage | ✓ | — | — | — |
| Controls | ||||
control:read | ✓ | ✓ | ✓ | ✓ |
control:assess | ✓ | ✓ | — | — |
control:manage | ✓ | — | — | — |
control:approve | ✓ | — | — | ✓ |
| Evidence | ||||
evidence:read | ✓ | ✓ | ✓ | — |
evidence:write | ✓ | ✓ | — | — |
evidence:delete | ✓ | — | — | — |
evidence:approve | ✓ | — | — | — |
| Risks | ||||
risk:read | ✓ | ✓ | ✓ | ✓ |
risk:write | ✓ | — | — | — |
risk:accept | ✓ | — | — | ✓ |
| Tasks | ||||
task:read | ✓ | ✓ | ✓ | — |
task:write | ✓ | ✓ | — | — |
task:delete | ✓ | — | — | — |
| Assets & exposure | ||||
asset:read | ✓ | ✓ | ✓ | ✓ |
asset:write | ✓ | ✓ | — | — |
finding:read | ✓ | ✓ | ✓ | ✓ |
finding:write | ✓ | ✓ | — | — |
finding:delete | ✓ | — | — | — |
| Nonconformities & CAPA (ISO 27001 Clause 10.1) | ||||
nonconformity:read | ✓ | ✓ | ✓ | ✓ |
nonconformity:write | ✓ | ✓ | — | — |
nonconformity:approve | ✓ | — | — | — |
nonconformity:risk_accept | ✓ | — | — | ✓ |
| Management review (ISO 27001 Clause 9.3) | ||||
management_review:read | ✓ | — | ✓ | ✓ |
management_review:write | ✓ | — | — | — |
| Connectors | ||||
connector:read | ✓ | ✓ | ✓ | — |
connector:manage | ✓ | ✓ | — | — |
connector:delete | ✓ | — | — | — |
| Suppliers & incidents | ||||
supplier:read | ✓ | ✓ | ✓ | ✓ |
supplier:write | ✓ | — | — | — |
incident:read | ✓ | ✓ | ✓ | ✓ |
incident:write | ✓ | ✓ | — | — |
| AI assistant (AURA) | ||||
ai:use | ✓ | ✓ | ✓ | ✓ |
ai:manage | ✓ | — | — | — |
| Webhooks & API tokens | ||||
webhook:manage | — | — | — | — |
token:manage | — | — | — | — |
| Dashboards & reports | ||||
dashboard:read | ✓ | ✓ | ✓ | ✓ |
report:read | ✓ | ✓ | ✓ | ✓ |
report:generate | ✓ | — | ✓ | ✓ |
| Audit | ||||
audit:read | ✓ | — | ✓ | — |
| Immutable audit snapshots (Audit Room) | ||||
audit_snapshot:read | ✓ | — | ✓ | — |
audit_snapshot:create | ✓ | — | — | — |
it_manager
can raise a nonconformity but not approve its effectiveness review or accept residual
risk on it (segregation of duties — the role that executes remediation does not also
sign off on it); auditor can read a sealed audit snapshot but
not create one (an auditor verifies the record, they do not produce the thing they
audit); only admin can manage webhooks or API tokens (both are
organization-wide automation surfaces, treated the same as member/settings management).
Inviting & managing members
Go to Settings → Members (/settings), or
POST /orgs/current/members directly. Only
admin can manage members (a Security Manager can read the
list but not change it).
- Click Invite member and enter the email, full name, role and a temporary password (minimum 10 characters, enforced server-side).
- A new email creates a user account, consuming a licensed seat (checked
against the edition's
max_userslimit — see the license activation step). An existing email on the instance is added to this organization instead; a duplicate membership is rejected. - Communicate the temporary password over a secure channel; have each user change it and enrol MFA on first login.
Each invited user appears in the Members table with their role; a member.invited audit event is recorded.
Guardrails
- The system refuses to demote the last remaining admin — every organization keeps at least one.
- You cannot remove your own membership, and you cannot remove the last admin (even as that admin).
- Every member and role change is audited (visible under Auditability).
- Access is enforced server-side on every request from the matrix above — the console only hides actions you cannot perform; it does not gate them.
Enterprise SSO, MFA & SCIM
Configured under Settings → Security & SSO (all roles keep the same five system roles; SSO/SCIM control how accounts are provisioned, not what a role can do):
- TOTP multi-factor authentication with backup codes — available to every user regardless of edition.
- SAML SSO (including optional signed AuthnRequests), OpenID Connect and LDAP/Active Directory sign-in — require the Enterprise edition.
- SCIM 2.0 provisioning — a copyable tenant base URL and least-privilege
API-token auth to wire Azure AD, Okta or OneLogin; Users and Groups support
equality filters, pagination and full lifecycle sync. SCIM resources return
ETags; IdPs can send
If-Matchfor safe updates andIf-None-Matchfor cache revalidation. Requires Enterprise. - Audit-ledger integrity verification — recomputes the hash chain on demand (see Auditability).