Risk mitigation
Also known as: risk reduction, risk modification
Lowering a risk by adding controls that make it less likely to happen or less harmful if it does.
Draft - this entry has not been reviewed yet.
Formal
The risk treatment option in which controls are chosen and put in place to reduce the likelihood, the impact, or both, until the remaining risk falls within the risk appetite.
In plain English
Like putting a rubber mat in the shower and a grab bar by the bath - you still wash, but a fall is less likely and less bad if it happens.
In practice
After fraud attempts, an unemployment fund requires a second case officer to approve any change of a member's bank account and has staff call the member back first; the risk moves from high to medium.
Why it matters
It is by far the most used option and the one most security work is about, but a risk is never removed this way - some always remains.
How to put it into practice
The usual steps, in order. Adapt them to your organisation.
- For each risk to be reduced, note whether it is driven mainly by likelihood or by consequence, since that decides which kind of control will help.
- Select controls from any source, such as the CIS Controls or NIST SP 800-53, and combine preventive, detective and corrective types instead of relying on prevention alone.
- Compare the selection with ISO 27001 Annex A, and record in the Statement of Applicability which controls you use against the risk.
- Estimate the expected residual risk and the cost of each control, and stop adding controls where the extra cost exceeds the reduction in expected loss.
- Where the preferred control is not possible, such as patching a legacy system, document a compensating control like isolation and extra monitoring together with the gap it covers.
- Implement each control with a named owner and a deadline, and track progress in the risk treatment plan.
- Test that each control works in practice, for example with restore tests, coverage metrics or a penetration test, before lowering the residual rating.
- Recheck the controls at least once a year and after incidents, and pass any residual risk still above appetite on to acceptance or transfer.
Common pitfalls
- Lowering the risk rating as soon as a control is bought or listed, before it has been shown to work.
- Relying only on preventive controls against an impact-driven risk such as ransomware.
- Adding layer after layer of controls long after the extra cost has stopped paying off.
- Undocumented compensating controls that nobody remembers to maintain.
Good guides
- The 18 CIS Critical Security Controls(opens in a new tab) · Center for Internet Security
- NIST SP 800-53 Rev. 5 - Security and Privacy Controls for Information Systems and Organizations(opens in a new tab) · NIST
- SoA-dokumentet(opens in a new tab) · Styrelsen for Samfundssikkerhed (in Danish)
Technical deep dive
ISO/IEC 27005 calls this option risk modification, and ISO 31000:2018 clause 6.5.2 splits it into changing the likelihood and changing the consequences, alongside removing the risk source. The distinction matters for control selection. Likelihood-reducing controls act before an event: patching, MFA, network segmentation, application allow-listing and secure configuration. Consequence-reducing controls act during or after it: offline backups with tested restores, immutable logging, encryption of data at rest so stolen media is less harmful, and incident response and continuity plans. A risk dominated by impact, such as ransomware against a critical system, is rarely brought within appetite by prevention alone, because no preventive control is perfect.
ISO/IEC 27002:2022 tags each of its 93 controls with attributes, including control type (preventive, detective, corrective) and cybersecurity concept (identify, protect, detect, respond, recover), which makes it possible to check that a treatment plan does not rely on a single type. ISO/IEC 27001:2022 clause 6.1.3 b) requires the organisation to determine all controls necessary to implement the chosen treatment, from any source; c) to compare them with Annex A to verify that no necessary control has been omitted; and d) to produce a Statement of Applicability listing the necessary controls, whether they are implemented, and the justification for including or excluding each Annex A control. Annex A is a checklist against omission, not a catalogue that must be adopted wholesale.
The expected effect of each control is an assumption until verified. Assurance practice distinguishes design effectiveness, whether the control as specified would address the scenario, from operating effectiveness, whether it actually worked over a period, the difference behind SOC 2 Type I and Type II reports. Residual ratings should be based on evidence such as test results, coverage metrics and incident data, not on a control merely being listed. Compensating controls are used when the preferred control is not feasible, for example extra monitoring and network isolation around a legacy system that cannot be patched, and should be documented with the gap they cover.
Mitigation shows diminishing returns: the first controls against a risk usually remove most of the likelihood cheaply, and each further increment costs more. Defence in depth justifies layering, but beyond the point where marginal cost exceeds the marginal reduction in expected loss, acceptance or transfer of the remainder is the rational choice. Unlike transfer, mitigation changes the risk itself; unlike avoidance, the activity continues.
What to learn first
Everything this builds on, foundations first.
- CIA triad
- →Threat
- →Asset
- →Vulnerability
- →Impact
- →Likelihood
- →Risk
- →Security control
- →Risk mitigation
Relationships
- A kind of
- Risk treatment
- Requires
- Security control
- Don't confuse with
- Risk transferRisk avoidance
- Used with
- Statement of Applicability (SoA)
Sources & further reading
Standards & official texts
- ISO/IEC 27005:2022 (8.2 - Risk treatment options)
Course material
- Cyber Security Fast Track - Kursuskompendium, Modul 5 og Ordliste (Risikohåndtering - reducere)
Where this data comes from
This entry was drafted by an AI from the sources above and has not yet been checked by a person. Treat it as a starting point, and check anything important against the sources.
See the review queueSuggest a correction on GitHubThis term as JSON
Check yourself
Loading…