Risk settings

The risk settings are your risk criteria. ISO 31000 (6.3.4) and ISO/IEC 27001 (6.1.2 a) ask you to define them before you rate anything. Every risk and every vendor is rated against them. The asset matrix is separate and keeps fixed thresholds. Owners and admins change the settings, and everyone else can read them. Every save creates a new version.

Define the criteria

1. Open Risks → Settings. Each tab holds one part of the criteria. One save covers all tabs.
2. On Likelihood, set 3 to 7 levels, lowest first, each with a name and a definition. A definition that says how often per year is easy to agree on, for example "once in ten years" or "several times a year".
3. On Impact, set 3 to 7 levels in the same way.
4. Still on Impact, add up to six impact categories, for example financial, legal, reputational, and operational. For each category, write what each level means. Then a "Major" legal impact and a "Major" financial impact are both defined. Each level can also have its own name and definition for opportunities, where it describes the benefit.
5. On Risk levels, set 2 to 6 levels, lowest first. Give each a name, a color, and the required response that the matrix and the risk show to the owner. Mark whether each level is acceptable.
6. Below the levels, set the review interval: how many months a risk may go without an approved review before the overview flags it. The range is 1 to 36 months, and the default is 12.
7. On Risk matrix, pick the level of every likelihood × impact cell. The matrix does not need to be symmetric. For example, a catastrophic impact can stay at a high level whatever its likelihood.
8. Select Review and save in the bar at the bottom. Give a reason for the change. The version history keeps it.

A dot on a tab marks unsaved changes. A red dot marks a level without a name. Discard removes the unsaved changes.

Watch out: a cell with a lower level than a cell with less likelihood or less impact is out of order. devguard outlines and reports it, because results stay comparable only on a consistent matrix.

Resize a scale

A rating is a position on the scale. So adding or removing a level of the likelihood or impact scale moves every stored rating.

1. Add or remove the level and select Review and save.
2. The save dialog shows a Move Existing Ratings step. It shows where each old level goes. By default, devguard spreads the old levels proportionally over the new scale. Change the mapping if needed.
3. Save. devguard moves the ratings of every risk, every vendor, and every captured vendor assessment in one step.

A residual acceptance stays valid only while its risk keeps the same level, and that level stays acceptable or not acceptable as before. A save that changes either withdraws the acceptance, and the owner accepts again. The result of the save says how many acceptances it withdrew.

Versions

Every save creates a new version with who saved it, when, and the reason. The History tab lists the versions. Reset to defaults loads the defaults into the form for you to check and save.

• The risk report prints the version in force.
• A risk or vendor review uses the version that was in force when it started. Its snapshots never change later.
• A residual acceptance records the level name and the version it was given under.

Reference

Defaults

A 5 × 5 matrix. Likelihood: Rare, Unlikely, Possible, Likely, Certain. Impact: Negligible, Minor, Moderate, Major, Critical. Levels: Low and Medium (acceptable), High and Critical (not acceptable), each with a required response. Review interval: 12 months. No impact categories.

Limits

What reads the criteria

• the register's level badges and level filters;
• the assessment matrix, the gap analysis cells, and the overview;
• the risk report;
• the vendor matrix and vendor ratings;
• the residual acceptance;
• the AI assistant's getRiskCriteria tool.

API

In the response, matrix[impact - 1][likelihood - 1] is the 0-based index of a rating's level in levels.

The PUT body takes:

• the whole criteria object;
• likelihoodMap and impactMap when a scale is resized: one entry per old level, naming its new position;
• a rationale;
• the base you edited from. The server compares it with the stored criteria and refuses the call with a conflict when someone saved in between.

PUT needs the right to manage the organization, so only owners and admins can use it. An organization token can read the criteria but not change them. Every save is written to the audit log.