What is risk mitigation?
Risk mitigation, also called risk reduction, is the treatment that lowers a risk by putting controls in place. The organization keeps doing the activity that creates the risk but makes the harmful event less likely, less damaging when it happens, or both. It is by far the most common treatment: most day-to-day security work, from patching to backups, mitigates one risk or another.
Reducing likelihood and reducing impact
Every control works on one side of the risk equation or the other:
- Lower likelihood: patching, MFA, email filtering, network segmentation, least privilege, secure baselines and security awareness training all make a successful attack less probable.
- Lower impact: offline or immutable copies of data, encryption at rest, redundant systems, keeping less data in the first place, and a practiced response plan all limit the damage when an attack gets through.
A sound plan uses both, because no preventive control is perfect. Mitigation draws on every control type: preventive controls stop events, detective controls find them quickly and corrective controls restore normal operations. When the preferred control isn't possible, such as patching a legacy system its vendor no longer supports, a compensating control like isolating that system on its own network segment mitigates the risk instead.
Mitigation has to be proportionate and real
Two tests decide whether mitigation is the right answer. The first is cost: a control should cost less per year than the expected loss it removes, which quantitative analysis shows with annualized loss expectancy. The second is effectiveness: a control reduces risk only if it works as intended. MFA enforced for staff but not for the admin portal, or backup copies stored where the same domain admin account can delete them, leave the risk higher than anyone thinks. Mitigation rarely takes a risk to zero, so the residual risk still has to be compared with the organization's appetite and formally accepted by the risk owner.
Example: mitigating email account takeover
A firm's risk register rates takeover of staff email accounts as high, with likelihood 4 and impact 4. The risk owner approves a mitigation plan with owners and dates: phishing-resistant MFA for all staff within 60 days, conditional access that blocks sign-ins from unmanaged devices, alerts on new mailbox forwarding rules and shorter session lifetimes. Once the controls are verified, the risk is re-rated at likelihood 2 and impact 3, a residual score of 6, which is within the firm's appetite and is formally accepted.
Risk mitigation vs. the other treatments
| Treatment | What happens | Example |
|---|---|---|
| Mitigate | Controls lower likelihood or impact; the activity continues | Patch servers and segment the network |
| Transfer | Part of the financial impact or the work moves to another party | Outsource payment processing under a contract with indemnification |
| Avoid | The activity that creates the risk stops | Stop storing card numbers after each payment |
| Accept | The risk is knowingly carried, with sign-off | Keep an old meeting-room display until next year's refresh |
Insurance is the classic trap: it softens the financial blow, so it can look like mitigation, but neither the likelihood of the event nor the outage changes, so it is transfer. Turning off one risky feature in a system that keeps running is mitigation; shutting the system down is avoidance.
Risk mitigation on the CompTIA Security+ exam
Mitigation is one of the four risk treatments in SY0-801 objective 5.2. Scenario verbs such as implement, deploy, patch, harden, segment or monitor signal mitigation. Don't confuse it with the mitigating controls in objective 4.1: that objective is about choosing specific controls for a scenario, such as segmentation, access controls or application allow lists, while objective 5.2 treats mitigation as a risk management decision. The distractors are the other three treatments, especially transfer when insurance appears among the answers.