Roles and permissions
The rights matrix
The twelve roles of the app and their rights, domain by domain. The table is generated from the app's rules, never written by hand.
The table below is produced when this documentation is published, from the app's table of rights: the same table the server reads to decide. It cannot say anything different from the rules.
How to read the rights
- A right is an action on a domain: read, edit, approve, export, manage. Manage includes the other four; edit, approve and export include read.
- Roles are additive: a person holds all the rights of all their roles. Gaining a role never takes a right away.
- Rights on one specific object (the owner, the assignee, the named reviewer or approver) are added to those of roles and remove none.
- A Jira administrator holds the rights of the Administrator role, with no grant.
| Domain | Administrator | Compliance manager | Reader | Contributor | Approver | Auditor | Risk and asset manager | Policy manager | People manager | Access review manager | Incident manager | AI manager |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Statement of applicability | manage | manage | read | no right | read, approve | read, export | read | read | read | read | read | read |
| Controls and evidence | manage | manage | read | on what is assigned | read | read, export | read | read | read | read | read | read |
| Risks and assets | manage | manage | read | no right | read, approve | read, export | manage | read | read | read | read | read |
| Vendors | manage | manage | read | no right | read | read | read | read | manage | read | read | read |
| Policies | manage | manage | read | no right | read, approve | read, export | read | manage | read | read | read | read |
| Management system | manage | manage | read | no right | read | read, export | read | manage | read | read | read | read |
| Personnel | manage | manage | no right | no right | no right | read | no right | no right | manage | no right | no right | no right |
| Access reviews | manage | manage | read | no right | read, approve | read, export | read | read | read | manage | read | read |
| Internal audits | manage | manage | read | no right | read | read, export | read | read | read | read | read | read |
| External audit | manage | manage | read | no right | read | read, edit, export | read | read | manage | read | read | read |
| Incidents | manage | manage | read | no right | read | read | read | read | read | read | manage | read |
| Artificial intelligence | manage | manage | read | no right | read, approve | read | read | read | read | read | read | manage |
| Tests | manage | manage | read | on what is assigned | read | read | read | read | read | read | read | read |
| Frameworks | manage | manage | read | no right | read | read | read | read | read | read | read | read |
| Audit log | manage | manage | no right | no right | no right | read, export | no right | no right | no right | no right | no right | no right |
| Settings | manage | no right | no right | no right | no right | no right | no right | no right | no right | no right | no right | no right |
| Roles and access | manage | no right | no right | no right | no right | no right | no right | no right | no right | no right | no right | no right |
R read · E edit · A approve · X export · M manage (includes read, edit, approve and export) · ◇ only on what is assigned to the person · – no right
The roles in one sentence
- Administrator: everything, settings and role management included. See the guide.
- Compliance manager: everything except settings and roles. See the guide.
- Reader: reads the screens, except people, the log, settings and roles, and with a reduced view of four registers (management system, policies, access-review campaigns, JSM Assets objects): see What a reader sees, register by register. This is the default access, until the administrator chooses "Contributor".
- Contributor: acts on the controls and tests assigned to them. See the guide.
- Approver: reads like a reader, but also sees every policy (drafts, submitted revisions, history); approves the statement of applicability, policies, AI systems, risks and access reviews. See the guide.
- Auditor: reads everything (people and log included), exports what an audit pack holds and answers the external audit's requests; it changes nothing else. Its grant is dated. See the guide.
- Domain managers (risks and assets, policies, people and vendors, access reviews, incidents, AI): read like a reader and manage their domain. The policies manager also manages the management-system registers.
What a reader sees, register by register
The table of rights says that a reader reads a domain. For four registers, what the server returns to them is shorter than what a manager sees, because the lines name people or accesses. The screen says so each time; it is not an empty register.
| Register | What a reader sees | Who sees everything |
|---|---|---|
| Management system (clauses 4 to 10), Context and interested parties screen | The counters at the top of the page. No register line: "The registers are restricted". | Whoever edits the management system: compliance manager, policies manager, administrator |
| Policies | The policies that are approved, in force and addressed to them, to read the text. No draft, no revision, no version history, no fingerprint, not the person who submitted the text, not the list of the other people of the audience, no templates. | Whoever edits or approves policies: every policy |
| A policy's acknowledgements ("Not yet accepted by", "Who accepted") | Only their own acknowledgements. No list of people. | Whoever edits the management system |
| Access reviews, a campaign's detail | The list of campaigns (dates, scope, progress) but not their detail, which names people and their accesses. A campaign they are a reviewer of opens, and shows only the accesses of the part of the scope entrusted to them. | Whoever manages access reviews (compliance manager, access-review manager, administrator): the whole campaign |
| Assets and Risks, objects read from JSM Assets | The light register alone; objects read from JSM Assets are neither listed nor named, even when the source is JSM Assets. | Whoever edits risks and assets (compliance manager, risk and asset manager, administrator) |
The other screens in read mode (statement of applicability, controls, evidence, risks, vendors, incidents, audits, tests, action plan) have no role-based reduced view. One exception depends on Jira rather than on the role: the title of an incident copied from a ticket is shown only to whoever can read that ticket.
The auditor is not affected by these reductions: it reads everything.
Separation of duties
The rule in the app's core covers four domains: the statement of applicability, policies, AI systems and risks. The author does not approve their own object. The server applies it to all four: the statement of applicability (authors are read from the log), to policies (the owner or the person who submitted) to AI systems (the designated approver is never the owner) and to risks (the owner of a risk neither accepts it nor records its acceptance). Someone who holds the Administrator role, or the Jira administrator right, may override it, so that a team of one can approve; the override is entered in the log. See Policies, AI governance and Risks.
Granting a role
Role: Administrator Granting to a person or a Jira group, the end date, the default access and custom roles (Advanced edition) are done from Settings › Access. The step-by-step is in Roles.
Good to know
The "Who can do what" tables of the screen reference compare three profiles (reader, compliance manager, Jira administrator). For the other roles (contributor, approver, auditor, managers, custom roles), the reference is the table above.
What the table does not say
- It does not say who holds which role in your installation.
- Some actions also depend on the edition (generating the audit pack needs the Advanced edition) and on the licence (without an active licence the app is read-only).
Was this page helpful?