...
This drop-down allows you to nominate an issue link type that defines how treatments are connected to risks. When this relationship is defined, treatments will appear beneath risks on the risk register page. If you leave the field blank, then treatments will not appear on the risk register page.
Users typically use this feature to record the treatment plans they have defined for their risks. Recording treatment plans in separate issues will enable you to quickly reference them in the main risk register view. It also enables you to track a separate priority and status for each treatment, and gives you auditing via Jira's issue history log.
...
This section allows you to control the risk matrix appearance. The Color of empty cells option determines whether empty cells on the risk matrix are filled with gray or with the appropriate risk color.
ENABLEMENT Old releases had an option to "enable" risk management. With the current release, users no longer explicitly enable risk management, neither at the app level nor at the project level. Whereas enabling risk management for a project previously generated an 'implicit' risk register, that is no longer the case. Instead, you explicitly create the risk registers that you want. For customers using the older version, any implicit risk registers were converted to explicit risk registers for any projects that had risk management enabled at the project level (overriding the app settings), or which contained one or more risks. |
|---|
...
A risk model defines the impact levels and probability levels that the application uses to assess risks. This page lists the risk models defined for your Jira instance.
There is one default risk model configured when you install the app. You can edit that risk model to shape it according to the standards followed by your organization. In addition to the default risk model, you can create as many project-specific risk models as you like. In each case, you nominate the projects to which the risk model applies. Using project-specific risk models, your organization can manage risk differently between projects or groups of projects. Each risk model can be assigned to multiple projects, but a project can only have one risk model. A project that does not have a project-specific risk model assigned will use the default risk model.
...
Clicking on a risk model opens up the risk model editing screen. The top portion of the screen is shown here:
The Clone button creates a new risk model that is configured the same way as the current model. If you clone a project-specific risk model, the result is a new risk model that has a name derived from the original (the name of the original risk model with “- copy” appended). The new risk model is not assigned to any projects by default. You must edit the new risk model to rename it, assign it to projects, and make whatever other changes are required. The changes that you make to the new risk model do not affect the original risk model.
...
Below the risk matrix is the Levels of risk list, which displays all of the risk levels associated with this model.
The drag handles (the double-horizontal lines) enable you to shift the order of the risk levels.
...
Clicking on the down-arrow enables you to edit details of the risk level.
The risk level Name can contain special characters.
...
Below the levels of risk list are the Impacts and Probabilities lists.
The drag handles (the double-horizontal lines) enable you to shift the order of the impacts or probabilities.
...
Clicking on the down-arrow enables you to edit details of an impact or probability.
The Name can contain special characters.
...
This page enables you to change generic Risk Register terms, allowing you to customize these to conform to your organizational norms. You can use non-English words if you wish.
Click Change terminology to edit these terms, which will be replaced in the risk register and matrix view, on the risk assessment panel, and in the cloud gadget.
...