---
title: "Roles and permissions"
canonical: "https://support.appfire.com/space/RM/3496575012/Roles%20and%20permissions"
format: markdown
---
Appfire LiveRisk uses Jira permissions, LiveRisk roles, and ownership to control what users can see and do.

> ℹ️ Access is granted by **permissions, not role names**. LiveRisk provides standard Jira roles with the appropriate permissions, but you can grant the same permissions through your own Jira roles if needed.

Two permissions (**Jira settings** > **Work items** > **Permission schemes** > **LiveRisk Risk Management Permission Scheme** > **Permissions**) are central to LiveRisk:

![Appfire LiveRisk, Jira permissions page with LiveRisk-specific permissions highlighted.](media://e416e6b8-c121-4959-8ba3-03266c4d13e1)

- **Manage LiveRisk Risk Register** — provides access to the LiveRisk features used to run a risk register, including governance features and transitions.
- **Administer Projects** — provides access to the LiveRisk configuration available from the space settings.

Users also need the standard Jira permissions required to access and work in the space, such as **Browse Projects** and **Edit Issues**.

## How access works

A risk in LiveRisk is a Jira work item. Users can see a risk only when Jira allows them to view the underlying work item.

This applies to individual risk work items and aggregated views such as **Risk register** and **Live progress**. A user does not need to be the Risk Owner to see a risk if their Jira permissions otherwise allow them to view it.

Being a Jira site administrator, organization administrator, or space lead does not automatically provide access to LiveRisk features within a risk register. Jira determines access from the permission scheme associated with the space.

If an administrator needs to work within a risk register, add them to an appropriate LiveRisk role or grant the required permissions through another Jira role.

## LiveRisk roles

Shared configuration creates three Jira roles for LiveRisk (**Jira space settings** > **People**).

![Appfire LiveRisk, Permissions screen under space settings.](media://df674536-c290-4adc-b1f6-046f556dd22d)

| **Role** | **What this role is for** | **Default permissions** |
| --- | --- | --- |
| **LiveRisk Manager** | For users who manage and govern risks and configure the risk register, including sources, the risk matrix, categories, vulnerabilities, threats, and controls. | **Manage LiveRisk Risk Register** and **Administer Projects** |
| **LiveRisk Analyst** | For users who manage and govern risks but don't need to configure the risk register. | **Manage LiveRisk Risk Register** |
| **LiveRisk Service** | Used by the LiveRisk app for automated operations, such as risk imports and status transitions. This is a service role and isn't intended for users. | App operations |

LiveRisk roles are the default way to assign these permissions. If you use a custom Jira role instead, grant **Manage LiveRisk Risk Register** to users who need to run the risk register.

Grant **Administer Projects** as well if those users need to configure LiveRisk from the space settings.

## Permissions by area

### Manage LiveRisk Risk Register

**Manage LiveRisk Risk Register** provides access to the LiveRisk features used to run and govern a risk register.

It is required for:

- **Signals**
- **Candidate risks**
- **Dashboard**
- **Security posture**
- LiveRisk risk-management panels and actions
- Governance workflow transitions
- Management of the complete asset registry

All eight LiveRisk governance workflow transitions require **Manage LiveRisk Risk Register**. **Administer Projects** alone does not grant permission to perform these transitions.

### Administer Projects

**Administer Projects** provides access to the six LiveRisk configuration areas under **Space settings**:

- **Sources**
- **Risk matrix**
- **Risk categories**
- **Risk vulnerabilities**
- **Risk threats**
- **Controls**

The default **LiveRisk Manager** role has this permission. **LiveRisk Analyst** does not.

### Other LiveRisk views

Some LiveRisk views do not require **Manage LiveRisk Risk Register** simply to open them:

| **Area** | **Access** |
| --- | --- |
| **Risk register** | Available to users who can access the Jira space. Users see only the risks that their Jira permissions allow them to view. |
| **Live progress** | Available to users who can access the Jira space. The risks shown depend on their Jira permissions. |
| **Assets** | Available to users who can access the Jira space. Without **Manage LiveRisk Risk Register**, users see assets based on their asset ownership. **Manage LiveRisk Risk Register** is required to manage the complete asset registry. |

Access to a view doesn't override Jira permissions. For example, turning **My risks** on or off in **Risk register** changes which risks are displayed; it doesn't grant or remove access to the underlying Jira work items.

## Risk Owners

The assignee of a risk work item is its **Risk Owner**.

Only members of **LiveRisk Manager** or **LiveRisk Analyst** can be selected as a Risk Owner. The Risk Owner picker includes members of those two roles.

If an imported risk specifies an owner who is not a member of either role, the risk is imported without an assigned Risk Owner.

> ℹ️ Risk ownership does not provide exclusive visibility. Other users can still see the risk when their Jira permissions allow them to view the underlying work item.

## Asset Owners

The user assigned to an asset is its **Asset Owner**.

Asset Owners can:

- view and manage their assigned assets,
- view and manage all descendants of their assigned assets, and
- see the names of ancestor assets to understand where their assets sit in the hierarchy.

Ancestor assets are shown as read-only context. Asset Owners cannot view their details unless they have access through another role or permission.

Users with **Manage LiveRisk Risk Register** can manage the complete asset registry.

## Access when creating a risk register

When a site administrator creates a new risk register, LiveRisk automatically adds the following to the **LiveRisk Manager** role:

- the space lead,
- the user creating the risk register, and
- the LiveRisk app user.

This gives the space lead and creator the permissions needed to manage and configure the new risk register.

The **LiveRisk Analyst** role starts empty. Add users or groups to this role when they need to manage and govern risks without configuring the risk register.

> ✅ Creating a new risk register is recommended over converting an existing Jira space because conversion replaces the space's existing permission scheme.

## Access when converting an existing space

Converting an existing Jira space into a risk register replaces the space's existing permission scheme with the **LiveRisk Risk Management Permission Scheme**.

During conversion, LiveRisk automatically adds the following to the **LiveRisk Manager** role:

- the space lead,
- the user performing the conversion,
- the LiveRisk app user, and
- users and groups assigned to Jira's **Administrators** role in the existing space.

Other users and groups are not automatically carried over to a LiveRisk role. As a result, people who previously had access to the space may lose access after conversion, including access to existing non-Risk work items.

Before converting a space, review its current access and identify which users and groups need to be added to **LiveRisk Manager** or **LiveRisk Analyst** afterward.

## Jira-native editing

LiveRisk applies its permission and ownership checks to actions performed through LiveRisk pages and panels.

Users with Jira's **Edit Issues** permission may still be able to modify some underlying fields through Jira, the Jira REST API, or other Jira-native features. Jira records these changes in the work item's **History**.

Jira editing permissions do not grant access to restricted LiveRisk actions such as governance transitions or other features that require **Manage LiveRisk Risk Register**.

## AI access to Confluence

When AI-assisted scoring or treatment-plan generation uses Confluence content, access is evaluated using the permissions of the assigned Risk Owner.

The Risk Owner must have permission to view any Confluence content required by the AI-assisted action.