Roles and permissions
Roles
The twelve roles of the app, how to grant them from Settings › Access, and how the server checks the rights.
The app knows twelve roles: six standard roles and six domain managers. The rights of each, domain by domain, are in the rights matrix. This page explains how roles are granted and how they are checked.
The twelve roles
| Role | What it allows |
|---|---|
| Administrator | Everything, roles and settings included. Jira administrators have the same rights. |
| Compliance manager | Manages everything except roles and settings. |
| Reader | Reads the screens, with a reduced view of a few registers (see the matrix). Changes nothing. |
| Contributor | Sees and works on what is assigned to them only: their tasks, evidence, controls, tests. |
| Approver | Reads like a reader and sees every policy; approves the statement, policies, AI, risks and access reviews. Writes nothing. |
| Auditor | Reads everything (log and files of the people included), exports the audit pack and answers the external audit's requests. A dated grant that ends by itself. |
| Risk and asset manager | Manages the risk register and the asset inventory. |
| Policy manager | Manages the policies and the registers of the management system. |
| People manager | Manages people, training, vendors and the external audit's requests. |
| Access review manager | Creates and closes access review campaigns. |
| Incident manager | Manages the incident register. |
| AI manager | Manages the register of AI systems and their assessments. |
Roles are additive: a person holds all the rights of all their roles, of their Jira groups and of the default access. Gaining a role never takes a right away.
Who holds what by default
- Everyone who can open the app has the installation's default access. Until someone changes it, it is "Reader": they read the screens, with the reduced view described in the rights matrix.
- A Jira administrator holds the rights of the Administrator role, without any grant, and is never locked out of the app.
- For every other role, a grant is needed.
Granting a role
Reserved for the administrator
Only the Administrator role (or the Jira administrator right) manages roles. The "Settings" menu entry only appears to Jira administrators.
- Open the "Settings" page, then the "Access" tab (the other tab is "General").
- Under "People and groups", click "Grant a role".
- In "To whom", choose "A person" or "A Jira group". For a person, type two letters in "Search for a person" (only active people of your Jira appear) and pick them. For a group, enter its name as it is spelled in Jira.
- Choose the "Role": the "Standard roles", then, if your edition includes them, the "Custom roles".
- "Valid until" is optional, except for the auditor: that role requires an end date, 366 days at most.
- Click "Grant".
In the "People and groups" table, "Change the date" moves or removes the end date (except for the auditor, who always keeps one) and "Remove" deletes the grant. A grant whose date has passed shows "Expired" and gives no right any more.
Every grant, date change and removal is entered in the log and listed under "Grants trail" (identifiers only; the full detail is in the audit log).
Seeing what a role allows
Under "Roles", each role is described in a sentence. "Show the matrix" opens, for that role, the domain-by-domain table: it is the table the server generates, the same as the one in the rights matrix.
Custom roles (Advanced edition)
Good to know
Custom roles are part of the Advanced edition. The standard roles, the managers, groups and the auditor are in every edition.
Under "Custom roles", "Create a custom role" builds a role with one level per domain: "None", "Read", "Read and edit" or "Read, edit and approve". Each level includes the ones before it. The identifier starts with custom_ and never changes. The administration (roles and settings) is never part of one: a custom role cannot manage roles. A role that is still granted cannot be deleted.
Default access
Under "Default access", choose what everyone has without a granted role:
- "Reader: reads most registers (today’s behaviour)": the reduced view of four registers is described in the rights matrix;
- "Contributor: sees only what is assigned to them". This is stricter: with no role, nobody sees the registers, only their own tasks, controls and tests.
Review of the access to NexusGRC
Under "Review of the access to NexusGRC", "Launch a review of the access to NexusGRC" creates a campaign in the Access reviews module: everyone who holds a role is put in front of you, to confirm or remove. You are its reviewer; you pick the "To finish before" date. Jira groups are not expanded: their members are reviewed with the groups in a Jira campaign, and the screen tells you how many grants to a group were not expanded.
How the rights are checked
- The server checks the right on every call. Hiding a button on screen is never the only protection. Several screens also say who an action is reserved to, with a sentence such as "Reserved to compliance managers and administrators."
- The Jira administrator right is asked of Jira with the identity of the person calling; it is never read from the browser. If Jira does not answer, the app does not take the person for an administrator: the action fails without changing anything, unless a role already granted is enough.
- Rights on one specific object (the owner, the person it is assigned to, the named reviewer or approver) are added to those of the roles and never remove any.
- Without an active licence the app is read-only for everyone, whatever the role; some actions also depend on the edition.
Was this page helpful?