---
title: 01.05 Mitigating a Risk
description: Walk a risk through mitigation planning — owners, planning date, effort and cost, current solution, the mitigation percent that drives residual risk, and…
---
[Skip to content](https://support.simplerisk.com/kb/01-05-mitigating-a-risk#main-content)
English
Show submenu for translations
[Customer portal](https://support.simplerisk.com/tickets?hsLang=en)
[](https://www.simplerisk.com/)
Open main navigation
Close main navigation
- English
Show submenu for translations
- [Customer portal](https://support.simplerisk.com/tickets)
- [Contact us](https://www.simplerisk.com/about-us/contact-us)
[Contact us](https://www.simplerisk.com/about-us/contact-us)
How can we help you?
- There are no suggestions because the search field is empty.
1. [SimpleRisk Knowledge Base](https://support.simplerisk.com/kb?hsLang=en)
2. [User Guide](https://support.simplerisk.com/kb/user-guide?hsLang=en)
3. [01 Risk Management](https://support.simplerisk.com/kb/user-guide?hsLang=en#01-risk-management)
# 01.05 Mitigating a Risk
## Walk a risk through mitigation planning — owners, planning date, effort and cost, current solution, the mitigation percent that drives residual risk, and the accept/reject sign-off that closes the loop.
## Why this matters
A reviewed risk that nobody plans to do anything about is a risk waiting to happen. Mitigation is the part of the workflow where the program decides what it's going to do, who's going to do it, when it's going to be done, and how much the work will reduce the risk. The plan is the thing the residual-risk score is computed from; without one, residual risk equals inherent risk and the dashboards show no improvement no matter how much real work the team has done.
The mitigation tab also enforces a discipline most programs need: separating "we hope this gets better" from "we have a named owner, a date, and a percent reduction estimate." The plan doesn't have to be detailed (a good first cut is two paragraphs and a date) but it has to exist, and it has to be on a single record the program can revisit. The other tabs of the risk view are for what the risk *is*; the mitigation tab is for what's being done about it.
The other thing worth knowing up front: SimpleRisk separates the **planning** of a mitigation from the **acceptance** of one. Planning is the first-line work of the risk owner or a delegate. Acceptance is a second-line sign-off that the plan, as written, is acceptable to the organization. The two permissions are separate (**Able to Plan Mitigations** and **Able to Accept Mitigations**), and the separation is what makes the workflow meaningful — a self-accepted mitigation is a self-graded test.
## Before you start
Have these in hand before you open the mitigation form:
- The **Able to Plan Mitigations** permission on your account. Without it, the mitigation tab is read-only and no **Edit Mitigation** button appears. (See [Permission Reference](https://support.simplerisk.com/kb/03-03-permission-reference?hsLang=en).)
- A risk that's been through management review. New submissions can be mitigated before review, but the workflow is cleaner when the score is locked in first — see [Reviewing and Approving Risks](https://support.simplerisk.com/kb/01-04-reviewing-and-approving-risks?hsLang=en). The risk also has to be open; closed risks can't have new mitigations planned against them.
- A named **Mitigation Owner**. The accountable person for *executing* the mitigation, who is sometimes (but not always) the same as the risk owner. The risk owner owns the risk; the mitigation owner owns the work to reduce it.
- A realistic **Planned Mitigation Date**. The date by which the mitigation will be in place, not "the date we'd like it to be done." Mitigations whose planned date has passed without an update show up on the dashboards as overdue, and that signal only works if the dates are honest.
- A defensible **Mitigation Percent** estimate. The percentage reduction the mitigation is expected to apply to the impact side of the risk score. SimpleRisk uses this number to compute residual risk; a 100% mitigation reduces the impact to zero, a 0% mitigation does nothing. Most plans land between 20% and 80%; anything claiming "100% mitigation" deserves a sanity check.
## Step-by-step
### 1. Open the right page
There are two paths into the mitigation form:
- **Risk Management → Review risk** opens the unified action queue. Click the **Mitigation** chip to narrow it to risks that still need mitigation planning — populated by risks that have been management-reviewed but don't yet have a mitigation — then use a row's **Plan Mitigation** action to jump straight to that risk's Mitigation tab. Use this when the program is working through the planning backlog.
- The risk's detail view at `/management/view.php?id={id}` exposes the **Mitigation** tab on every risk, regardless of where it is in the workflow. Use this when you're updating an existing mitigation or planning one for a specific risk you already have open.
Both paths reach the same form. The queue, filtered to Mitigation, is for batch work; the detail view is for individual edits.
### 2. Open the mitigation form
From the queue, click any row to open that risk's detail view at the **Mitigation** tab. From the detail view directly, click the **Mitigation** tab. What you land on is read-only: the mitigation's fields laid out in a stack of labeled cards — Mitigation strategy, Assignment, Mitigation solution, Mitigation controls, and, on installs with mitigation-specific custom fields configured, a Custom fields card. Click **Edit Mitigation** to turn every card into an editable form. The button only appears if you hold the **Able to Plan Mitigations** permission; without it, you can read the plan but not touch it.
### 3. Fill in who, when, and how much (Mitigation strategy and Assignment cards)
The Mitigation strategy card captures the shape of the plan:
- **Mitigation Submission Date** — read-only, stamped when the mitigation was first recorded.
- **Planned Mitigation Date** — when the mitigation will be in place. Date picker. Required for the mitigation to count as planned.
- **Mitigation Effort** — dropdown of effort categories, configurable per install (a stock install starts at *Trivial*). Used in dashboards that show effort-versus-impact tradeoffs.
- **Mitigation Cost** — dropdown of cost ranges (configurable per install). Used the same way.
- **Planning Strategy** — dropdown of strategy categories (also configurable; common seeded values are *Mitigate*, *Accept*, *Transfer*, *Avoid*). The selection records what kind of mitigation this is, not just how it's executed.
- **Mitigation Percent** — see step 5, below.
The Assignment card captures who's doing the work:
- **Mitigation Owner** — single-user picker. The person accountable for executing the mitigation. Defaults to the risk owner but is editable; in larger organizations the mitigation owner is often a different person from the risk owner (the risk owner is the business stakeholder; the mitigation owner is the implementer).
- **Mitigation Team** — multi-select. Teams whose work is involved in carrying out the mitigation.
### 4. Fill in the planning narrative and the linked controls (Mitigation solution and Mitigation controls cards)
The Mitigation solution card captures the substance of the plan, in three plain multi-line text fields:
- **Current Solution** — what's already in place that partially addresses the risk. The "before" state.
- **Security Requirements** — what the mitigation needs to deliver — the requirements the implementer is committing to meet.
- **Security Recommendations** — additional measures recommended above and beyond the requirements; the "above and beyond" list.
All three are free-form and effectively unlimited in length, but they're plain text — there's no formatting toolbar, so structure a longer plan with line breaks and short paragraphs rather than headings or bullet lists. Keep them concrete: "Quarterly access review for all admin accounts in the customer-data subsystem" beats "Improve access reviews."
The Mitigation controls card is where you pick the framework control(s) this mitigation relies on — the link that lets a control's failure surface against every risk depending on it. Search and select from the picker; each control you add gets its own expandable detail panel directly beneath it, in both read and edit mode, so you can check what a control actually requires without leaving the tab.
### 5. Set the Mitigation Percent
In the Mitigation strategy card, **Mitigation Percent** is the number that drives residual-risk math. Type the percentage the plan is expected to achieve. Conventions vary by program; ask your second line for the calibration anchors if you're not sure. The number affects every downstream report; getting it directionally right matters more than getting it precisely right.
A few rules of thumb most working programs land on:
- **0%** is the right number if no mitigation is planned (which is also the right time to consider whether this should be an accepted risk via the Planning Strategy field rather than a mitigated one).
- **20%–40%** is reasonable for a mitigation that improves controls but doesn't materially change the risk's surface area.
- **50%–70%** is reasonable for a mitigation that materially changes the risk's likelihood or impact (replacing a vulnerable system, adding a compensating control that addresses the dominant attack path).
- **80%–95%** is reasonable for a mitigation that addresses the dominant root cause but leaves residual exposure.
- **100%** is rarely correct. A mitigation that genuinely brings residual to zero is usually a risk that should be closed via the close workflow, not a mitigated open risk.
### 6. Save the mitigation
Click **Save**. SimpleRisk records the mitigation against the risk, moves the risk's status to *Mitigation Planned* if the risk is still *New*, recomputes the residual-risk score using the new **Mitigation Percent**, and writes an audit-trail entry noting the save. A risk in any other status keeps it, so saving a mitigation never reopens a closed risk or undoes a management review; to reopen a closed risk, use **Reopen Risk** from the risk's actions menu. The tab returns to its read-only view with the new mitigation visible and the residual score updated. **Cancel**, instead, discards whatever you changed and returns to the same read-only view showing the values the mitigation had before you opened it.
For programmatic mitigation submission (useful when integrating with a project-management tool that creates the mitigation plan elsewhere), the v2 API exposes the operation at `POST /api/v2/risks/{id}/mitigations` (POST creates, PATCH updates), with the same field set as the form. The current mitigation can be fetched at `GET /api/v2/risks/{id}/mitigations`.
### 7. Accept (or reject) the mitigation
A planned mitigation isn't a finalized one until a second-line user with the **Able to Accept Mitigations** permission signs off on it. At the time of writing, that sign-off doesn't yet have a button on the Mitigation tab itself — it's an active area of the redesign, and the on-tab Accept/Reject action is expected to return in an upcoming release. Until then, check with your SimpleRisk administrator for how your program is handling acceptance (some integrate it through the API, some track it as a manual step alongside the mitigation record).
The two-permission separation described at the top of this article — planning is first-line, acceptance is second-line — is the design intent regardless of which button or workflow carries it out. Don't let a temporary gap in the UI become a permanent gap in the discipline: if nobody with **Able to Accept Mitigations** is reviewing plans, the workflow has quietly collapsed into self-grading even if every other field on this tab is filled in correctly.
## Common pitfalls
A handful of patterns recur across customers when mitigation planning misfires.
- **Confusing risk owner with mitigation owner.** The risk owner is the business stakeholder accountable for the risk's outcome. The mitigation owner is the implementer accountable for getting the work done. They're often different people, and the form supports the split for a reason — collapsing them produces a workflow where the business owner is held accountable for technical work they can't actually perform, or vice versa. Use the two fields for what they're for.
- **Optimistic Mitigation Percent.** New users often anchor at 80% or 90% because that's what the plan "should" achieve. Six months later, when the residual scores have been driving prioritization decisions, the program discovers the percentages were wishful and the prioritization was wrong. Calibrate against your own history: when prior mitigations have actually shipped, did they reduce the risk by what the percent claimed? If not, anchor lower. Honest 30% beats hopeful 80%.
- **Plan with no Planned Mitigation Date, or a placeholder date.** A blank date doesn't appear on the overdue list because there's no date to compare to today. A "31 December 2099" placeholder also doesn't appear on the overdue list. Either pattern hides work the dashboards exist to surface. Pick a real date, even if the date is "best estimate, will refine." Update it when the estimate sharpens.
- **Mitigation as a place to write the risk description.** The **Current Solution** and **Security Requirements** fields aren't for explaining what the risk is — that belongs in the risk's submission and its Risk Assessment. Mitigation fields describe what's being *done*, not what's wrong. Repeating the risk description in the mitigation field clutters the audit trail and makes the actual plan harder to find.
- **No accept/reject step.** A program where the same person plans and accepts the mitigation isn't running the workflow as designed; it's running first-line work on both sides of the gate. The acceptance is the second-line confirmation that the plan is sufficient. If the program doesn't have a second-line reviewer, the workflow can be configured to skip acceptance — but the loss of independence should be acknowledged, not hidden.
- **Updating the mitigation without recording why.** Each save overwrites the prior mitigation values and writes an audit log entry, but the audit entry doesn't explain *why* the change was made. When the planned date slips or the percent gets adjusted, add a one-line note to **Current Solution** or **Security Requirements** explaining the change. Future you (or your auditor) will thank you.
- **Treating accepted mitigation as "the work is done."** Accepting a mitigation says the plan is acceptable; it doesn't say the plan has been executed. The work itself happens after acceptance and reaches "done" only when the implementer reports back. The Mitigation tab doesn't track execution status by default — that's what the [Tracking Risks Over Time](https://support.simplerisk.com/kb/01-06-tracking-risks-over-time?hsLang=en) review cycle is for.
## Related
- [What is a Risk Register and Why Every Program Needs One](https://support.simplerisk.com/kb/01-01-what-is-a-risk-register?hsLang=en)
- [Submitting a Risk in SimpleRisk](https://support.simplerisk.com/kb/01-02-submitting-a-risk?hsLang=en)
- [Risk Scoring Methodologies](https://support.simplerisk.com/kb/01-03-risk-scoring-methodologies?hsLang=en)
- [Reviewing and Approving Risks](https://support.simplerisk.com/kb/01-04-reviewing-and-approving-risks?hsLang=en)
- [Tracking Risks Over Time](https://support.simplerisk.com/kb/01-06-tracking-risks-over-time?hsLang=en)
- [Permission Reference](https://support.simplerisk.com/kb/03-03-permission-reference?hsLang=en)
- [FAQs](https://support.simplerisk.com/kb/faqs?hsLang=en)
- [SimpleRisk Extras](https://support.simplerisk.com/kb/simplerisk-extras?hsLang=en#main-content)
- [Vulnerability Management Extra](https://support.simplerisk.com/kb/simplerisk-extras?hsLang=en#vulnerability-management-extra)
- [Team Separation Extra](https://support.simplerisk.com/kb/simplerisk-extras?hsLang=en#team-separation-extra)
- [Import-Export Extra](https://support.simplerisk.com/kb/simplerisk-extras?hsLang=en#import-export-extra)
- [Administrator Guide](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#main-content)
- [00 About This Guide](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#00-about-this-guide)
- [01 Installation and Deployment](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#01-installation-and-deployment)
- [02 Upgrades and Maintenance](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#02-upgrades-and-maintenance)
- [03 Users and Permissions](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#03-users-and-permissions)
- [04 Authentication](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#04-authentication)
- [05 Customization](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#05-customization)
- [06 Configuring Risk and Compliance](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#06-configuring-risk-and-compliance)
- [07 Integrations](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#07-integrations)
- [08 The API](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#08-the-api)
- [09 Encryption and Data Security](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#09-encryption-and-data-security)
- [10 Workflows and Automation](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#10-workflows-and-automation)
- [11 Reporting and Auditing](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#11-reporting-and-auditing)
- [12 Operations](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#12-operations)
- [13 Reference](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#13-reference)
- [User Guide](https://support.simplerisk.com/kb/user-guide?hsLang=en#main-content)
- [00 Foundations of GRC](https://support.simplerisk.com/kb/user-guide?hsLang=en#00-foundations-of-grc)
- [01 Risk Management](https://support.simplerisk.com/kb/user-guide?hsLang=en#01-risk-management)
- [02 Compliance Management](https://support.simplerisk.com/kb/user-guide?hsLang=en#02-compliance-management)
- [03 Governance](https://support.simplerisk.com/kb/user-guide?hsLang=en#03-governance)
- [04 Asset and Data Inventory](https://support.simplerisk.com/kb/user-guide?hsLang=en#04-asset-and-data-inventory)
- [05 Threat and Vulnerability Management](https://support.simplerisk.com/kb/user-guide?hsLang=en#05-threat-and-vulnerability-management)
- [06 Assessments](https://support.simplerisk.com/kb/user-guide?hsLang=en#06-assessments)
- [07 Incident Management](https://support.simplerisk.com/kb/user-guide?hsLang=en#07-incident-management)
- [08 Audit and Reporting](https://support.simplerisk.com/kb/user-guide?hsLang=en#08-audit-and-reporting)
- [09 Day-to-Day SimpleRisk](https://support.simplerisk.com/kb/user-guide?hsLang=en#09-day-to-day-simplerisk)
- [10 Continuous Improvement](https://support.simplerisk.com/kb/user-guide?hsLang=en#10-continuous-improvement)
- [SimpleRisk User Guides](https://support.simplerisk.com/kb/simplerisk-user-guides?hsLang=en)
- [Troubleshooting](https://support.simplerisk.com/kb/troubleshooting?hsLang=en)
- [SimpleRisk Hosted](https://support.simplerisk.com/kb/simplerisk-hosted?hsLang=en)
- [How To videos](https://support.simplerisk.com/kb/how-to-videos?hsLang=en)
[](https://www.simplerisk.com)
Copyright © 2026, SimpleRisk, Inc.