Application permissions
Risk Register for Jira Cloud relies on a layered permission model that combines Risk Register permissions with standard Jira administration, project, and issue permissions. This page explains how those layers work together and what access is required for common actions.
Key principle: Access to Risk Register features is not controlled by a single setting. Effective access depends on the combination of Risk Register global permissions, Jira global permissions, and Jira project or issue permissions.
Licensing matters: Some administrative actions also require an active Risk Register licence, even when the user already has the necessary Jira permissions.
Permission model overview
The permission model has three layers.
Risk Register global permission:
Create risk registersJira global permissions: principally Administer Jira
Jira project and issue permissions: principally Browse Projects, Administer Projects, Create Issues, and Edit Issues
How to read this page: If a user cannot perform an action, check all three layers. In many cases, the missing permission is a Jira project or issue permission rather than a Risk Register-specific setting.
How the layers work together
Different parts of the app are surfaced in different places in Jira, and each location affects how permission checks behave.
Application-level administration is tied closely to Jira administration permissions.
Project settings rely heavily on Jira project property access, which is governed by project-level permissions.
Registers and assessments depend on a mix of Risk Register visibility rules and the user’s ability to access the underlying Jira projects, filters, issues, and dashboards.
In practice, a user may be able to view a register but not configure it, or view an assessment but not edit it, depending on which Jira permissions they hold.
Permission matrix
Feature / action | Required permission | Notes |
|---|---|---|
View Risk Register application settings | Administer Jira | Application settings are exposed through a Jira administration page. This includes areas such as App Settings, Risk Models, Terminology, Tools, and Cloud Migrations. |
Change application settings | Administer Jira or System Admin | Requires an explicit backend permission check and an active Risk Register licence. |
View or manage risk models | Admin area for viewing; Administer Jira or System Admin to modify | Creating, updating, cloning, and deleting risk models require Jira admin permission and an active licence. Read APIs do not repeat the same check. |
Change terminology | Administer Jira or System Admin | Requires an explicit backend check and an active licence. |
View project Risk Register settings | In practice Browse Projects | The page reads the |
Change project Risk Register settings | Administer Projects for that project, or Administer Jira | The frontend writes directly to the Jira project property. Jira enforces this permission. |
Delete or reset project-specific settings | Administer Projects or Administer Jira | Uses the same Jira project property permission rule. |
Create a risk register | Create risk registers global permission, or Administer Jira or System Admin | Risk Register defines its own Jira global permission named |
Create a project-based risk register | Create risk registers | The current implementation does not effectively require Browse Projects as an additional permission. |
Create a filter-based risk register | Create risk registers and ability to see the Jira filter | The filter is explicitly checked against filters visible to the current user. |
View a project-based risk register | Browse Projects or Administer Projects on the project | Alternatively, a Jira administrator or a user explicitly named as a Risk Register administrator can view it. |
View a filter-based risk register | Ability to see the underlying Jira filter | Alternatively, a Jira administrator or named Risk Register administrator can view it. |
View a multi-project risk register | Access to every project in the register | The code requires Browse Projects or Administer Projects for every included project, unless the user is a Jira admin or explicitly a Risk Register administrator. |
Configure an individual risk register | Named Risk Register administrator, or Jira administrator | Administer Projects alone is not enough. An active licence is also required. |
Delete an individual risk register | Named Risk Register administrator, or Jira administrator | Uses the same effective permission rule as register configuration. |
Create a new risk or work item from a register | Create Issues in the relevant Jira project | This is explicitly checked before create functionality is offered. |
Assess or edit the risk assessment on an issue | Edit Issues | The app explicitly checks this before allowing assessment changes. The issue must also be editable in Jira and the app licence must be active. |
View an existing risk assessment | Normally, ability to view the issue | The assessment panel can display existing assessment data even where Edit Issues is not available. That permission applies to adding or editing, not just viewing. |
View Risk History | Ability to access the issue | The Risk History activity appears where the |
View Risk Register global list or page | No special Risk Register global permission | Individual registers are filtered based on each register’s own visibility rules. |
Dashboard Risk Matrix gadget | Standard Jira dashboard visibility and access to the underlying issues | There is no separate Risk Register-specific permission for the gadget itself. |
Important behaviours and edge cases
Project Admin is not enough for every action: For individual register configuration and deletion, Administer Projects alone does not grant access. The user must be either a named Risk Register administrator or a Jira administrator.
This distinction is especially important when delegating ownership. Being a Jira project administrator does not automatically make a user a Risk Register administrator for a given register.
Practical guidance
For Jira administrators
Use Administer Jira to manage application-wide settings.
Review who should have the
Create risk registersglobal permission.Confirm the app licence is active before troubleshooting admin functions.
For project administrators
Use Administer Projects to manage project-level Risk Register settings.
Ensure users also have Browse Projects, Create Issues, or Edit Issues as needed.
Do not assume project admin access grants register configuration rights.
Best practice: When setting up access, map the user’s real task to the exact action they need to perform. Granting broad Jira admin access is rarely necessary if the requirement is only to view, assess, or create risks in a specific project.