Risk Manager for Azure DevOps
Description
Risk Manager helps your team identify, assess, prioritize, and manage risks directly within your existing project workflow. Get a clear overview of your risks, understand their potential impact, track mitigation actions, and make better-informed decisions with visual risk matrices, configurable scoring, and actionable insights.
Risk Manager — User Guide
Risk Manager turns Azure DevOps work items into a working risk register. Risks stay ordinary work items, so queries, boards, links and permissions keep working; Risk Manager adds the scoring, the register views, the matrix and the exposure gauge on top.
Nothing is copied to an external database, and no risk score is written back to the work item — score, level, acceptance and change are calculated every time they are read.
Where Risk Manager appears
Surface | Where | Who uses it |
|---|---|---|
Setup, Risk scoring, Subscription | Organization settings (Collection settings on Server) → Risk Manager | Administrators, once |
Risk model for this project | Project settings → Risk Manager | Project administrators |
Risk Register | Boards → Risk Register | Everyone working with risk |
Risk Matrix and Risk Gauge widgets | Any dashboard → Add widget | Teams and stakeholders |
1. Set up the work item types and fields
Open Organization settings → Risk Manager → Setup.
Choose a process first
Risk Manager can only add types and fields to an inherited process — Azure DevOps does not allow system processes (Agile, Scrum, CMMI, Basic) to be changed. If the Process dropdown is empty:
Go to Boards → Process.
Open the ⋯ menu on Agile, Scrum, Basic or CMMI and choose Create inherited process.
Move the projects that should use it: on the inherited process, open Projects and change each project over.
Come back to Setup and pick the new process.
You need to be an administrator of the organization/collection to do this, and to create anything on the Setup page.
Pick which types hold risks and controls
Risk work item type and Control work item type say which types Risk Manager should inspect and create fields on. If the types do not exist yet, the two rows at the top of the table create them:
Risk — the work items managed as risks.
Control — work items managed as risk controls, linked to a risk with a Related link.
You do not have to create them. If you already track risks as Issues, Bugs or a custom type, select that type instead and Risk Manager adds the fields there.
Create the fields
The Fields and Link Types table lists everything Risk Manager recommends, grouped by what it is for. Each row shows one of:
Row state | What it means | Action |
|---|---|---|
✓ … exists and is on the Risk/Control work item type | Both halves are done: the field exists and it is on the selected type. | Nothing to do. |
Create | The field does not exist in the organization. | Creates it, with the recommended picklist values, and adds it to the type. |
⚠ … exists in the organization but is not on the Risk/Control work item type yet | Fields are organization-wide in Azure DevOps, so a field created for another process — or created and never put on the type — is only half done. | Assign to Risk work item type / Assign to Control work item type puts the existing field on the type. No duplicate is created. |
⚠ Recommended values not in its picklist | Your field exists but is missing some values. | Optional. Add them under Boards → Process if you want them. |
⚠ Conflict: a field named … already exists as … | The name is taken by a field of an incompatible type (for example a number picklist where a text picklist is expected). | No button is offered — nothing is overwritten. Rename or remove that field under Boards → Process, then check again. |
One click per row. Nothing on this page deletes or rewrites an existing field or value.
The checkmark always means created and assigned. A field that exists somewhere in the organization but is not on your Risk or Control type never counts as done — it shows the amber note and the Assign to … button instead.
One click per row. Nothing on this page deletes or rewrites an existing field or value.
The fields, by group:
Assessment —
Risk Impact,Risk Probability,Risk Category. The two axes of the matrix, and the category used for grouping, filtering and Readiness.Inherent risk —
Inherent Impact,Inherent Probability. The risk before controls.Residual risk —
Residual Impact,Residual Probability. What remains after them.Treatment —
Treatment(Accept / Avoid / Mitigate / Transfer),Treatment Plan,Contingency Plan.Controls (on the Control type) —
Control Effectiveness,Last Assessed,Assessed By,Assessment Note.Review —
Review Frequency,Review Date,Last Reviewed.Links — information only. Azure DevOps has no custom link types for extensions, so a mitigation action is a child of the risk, and a Control is a Related link.
Adding your own fields
Risk Manager is not limited to the fields above. Any picklist field on your risk type can be used as a probability or impact axis, and any field can be shown as a column.
To add one: Boards → Process → <your inherited process> → <your risk type> → New field, create it as a picklist with your own values, then select it in the register's Assessment section (below) or in a widget's configuration. Risk Manager reads the picklist values in the order the process defines them — put the values in order from lowest to highest, or use the order control in the register/widget configuration to flip it.
This is how you keep your own terminology: Inherent / Residual, Initial / Current, Gross / Net, or something else entirely.
2. Define your risk model
A risk model is three things: a score for every Probability × Impact combination, the levels those scores fall into, and the acceptance criteria that say which levels are acceptable.
Organization settings → Risk Manager → Risk scoring sets the model everyone inherits.
Project settings → Risk Manager lets one project override it when it genuinely needs a different model.
In the editor you:
Set the score for each cell in the grid — linear, or your own non-linear weighting.
Define levels (name, threshold, colour).
Mark each level Acceptable, Review required or Unacceptable.
Record a risk tolerance confirmation — who reviewed the thresholds against the organization's risk tolerance, and when.
Saving requires administrator permission on the collection. The same model then drives the register, every matrix, both widgets and every export.
3. Work in the Risk Register
Open Boards → Risk Register.
Create a register
A register is a saved view, not a copy of your data. It records which risks to show — projects, work item types, filters — and how to present them. Pick New register… in the register dropdown at the top, then work through the four sections of Configure:
Section | What it decides |
|---|---|
Identity & scope | Name, owners, which projects, which risk work item types, which types count as mitigation actions. |
Assessment | The primary assessment (a probability field and an impact field) and, optionally, a comparison assessment. The labels shown in the grid are yours to name. |
Which risks | State, tags, area path, iteration path, assigned to, title contains, and whether sub-risks outside the register still count. This is what gets fetched from Azure DevOps. |
Presentation | Default sort, grouping, density, whether the health band shows, whether the Readiness tab is offered. |
Configure the comparison assessment — for example inherent against residual — and you also get the Change column, the comparison matrix and the before/after marker on the gauge.
Owners can change what the register is. Everyone else can read it, filter it, add risks and edit them. It is a guard against accidental changes and a record of who to ask, not an Azure DevOps permission.
Create as many registers as you need — per project, programme, product, portfolio or framework. They are shared with everyone who can open the hub.
The five views
The tabs under the toolbar draw exactly the same rows. The health band and the filter bar sit below them and apply to all five, so filtering once changes every view.
View | Shows |
|---|---|
Register | Every risk as rows, grouped by acceptance, level, owner or nothing. |
Matrix | The same risks by probability and impact; with a comparison, the movement between the two assessments. |
Gauge | The same risks as one exposure reading. |
ROAM | The same risks by how they are handled — Resolved, Owned, Accepted, Mitigated. |
Readiness | How well the same risks support a framework, and which gaps cost the most. |
Clicking a matrix cell, a gauge level or a readiness gap hands those risks back to the grid as a removable filter.
Readiness is a gap finder, not an audit. It shows what your register's setup and data support for frameworks such as ISO 31000, ISO/IEC 27001, DORA or NIS2. Requirements Risk Manager cannot measure are marked Not supported and left out of the score. A high score is not a statement of compliance.
Two kinds of filter
The register's own filters (in Configure → Which risks) decide what is fetched from Azure DevOps. They are part of the register and shared.
The filter bar above the rows narrows what is already loaded — which is why filtering by level or acceptance is instant. Together with your columns, row detail and current view, it is remembered in your browser, for you alone.
Getting risks in, and working with them
+ Add risk creates a work item in the project you choose.
A risk can be broken into sub-risks. The parent shows the highest underlying exposure; nothing is averaged and the parent is never rescored behind your back.
Mitigation actions are ordinary child work items. Their progress is read back onto the risk.
Controls are work items of the Control type, attached with a Related link.
Edit owners, state, probability, impact and other fields directly in the grid — that edits the work item.
Details opens the panel beside the grid: the values behind each score, the trend, acceptance, treatment plan, mitigation progress and the sub-risk picture.
Taking it out
The ⋯ menu has Export to CSV… and Export report…. Both record when they were taken and every filter that was active, so a filtered register never leaves looking like the whole one. The same menu holds Refresh, Reset my view, Configure, Rename, Duplicate, Delete, Manage registers… and Help — how the Risk Register works.
4. Put risk on a dashboard
On any dashboard, choose Add widget and pick Risk Matrix or Risk Gauge.
Both widgets are configured the same way: title, projects, work item type, state, area path, iteration path, team, an optional risk hierarchy root, and the probability and impact fields (with the value order). Tick Compare with another risk assessment to get the second assessment, the change arrows and the total exposure figure — for example 206 → 109 ↓97 (-47%).
The gauge adds a Reading: exposure as a percentage of the maximum possible, as an average risk score, or as the total score across the widget's risks.
Widgets use the risk model of the project they read from, so a dashboard and the register always agree.
5. Troubleshooting
Symptom | Cause | Fix |
|---|---|---|
Setup shows No inherited process found | The project uses a system process. | Create an inherited process under Boards → Process and move the project to it. |
A field row offers no button | Someone without process permission is looking, the row is blocked, or the field name is taken by an incompatible type. | The row's note says which. Ask a collection administrator, or rename the conflicting field under Boards → Process. |
A field exists but risks do not show it | The field was created in the organization but never put on the Risk or Control type. | The Setup row shows an amber note; click Assign to Risk work item type (or … Control …). |
You do not have permission to change Risk Manager settings | Risk model saves need collection administrator rights. | Have an administrator save the model. |
Risks show Not assessed | Probability or impact is empty, or the register points at the wrong fields. | Fill the fields, or correct Configure → Assessment. |
No Change column | The register has no comparison assessment. | Add one in Configure → Assessment. |
A risk is missing from the register | It is outside the register's own filters. | Check Configure → Which risks, not the filter bar. |
The Readiness tab is gone | Its owner turned it off. | Configure → Presentation → Offer the Readiness tab. |
What is stored where
Risks, scores' source fields, links, mitigation actions — ordinary Azure DevOps work items. Risk Manager reads them and writes only what you edit.
Registers, the risk model, widget settings — Azure DevOps extension data, inside your organization.
Your columns, density, grouping and current view — your browser.
Scores, levels, acceptance, change, exposure — calculated on read. Never stored, never written back to the work item.
Risk Manager works with both Azure DevOps Services and Azure DevOps Server, and follows the host's light and dark theme.