The risk assessment is done. The spreadsheet has forty items, each with a likelihood and impact rating, and the action column says the same thing for all of them: implement a control. The budget covers ten. Six months later the auditor asks who decided that the other thirty could wait, and nobody can point to that decision.
That is what mitigation chosen by reflex looks like. In cybersecurity, risk treatment means choosing among four options, and risk mitigation strategies cover only one of them. Choosing between them is a management decision, not a technical one, so it has to be recorded in a way that holds up in front of the board and the regulator.
What is risk mitigation and how does it differ from risk assessment?
Risk mitigation means selecting and implementing controls that reduce risk to a level the organization finds acceptable. NIST defines it as prioritizing, evaluating and implementing the appropriate risk-reducing controls recommended from the risk management process. The definition assumes that controls come out of the risk management process, which means they follow assessment rather than replace it.
Risk assessment answers the question of how big the risk is, meaning which assets are threatened, by what and with what impact. The methods of that assessment, from asset inventory to scoring, are described in the article on cybersecurity risk assessment, and the general stages in the piece on what IT risk analysis is. Risk treatment answers the next question: what are we going to do about it.
Both activities are parts of one cycle, which the glossary describes as risk management. In practice they are often confused, because the same spreadsheet holds both the assessment and the action plan. The difference matters for accountability, though: the security team can prepare the assessment, but the decision on which risk the company takes on is made by someone with the right mandate.
What are the four risk treatment options?
The four risk treatment options are acceptance, avoidance, mitigation, and transferring or sharing the risk. NIST defines risk response as exactly that: accepting, avoiding, mitigating, sharing or transferring risk. NIST SP 800-39, published in 2011, lists five responses and their combination; sharing and transfer are usually grouped together, hence four options.
These two responses share a similar mechanism: part or all of the consequences move to another organization. The names vary, with “risk reduction” instead of “mitigation” and “risk retention” instead of “acceptance”, but the substance of the decision stays the same.
The most important observation in NIST SP 800-39 concerns order. The document describes mitigation as the response for the portion of risk that cannot be accepted, avoided, shared or transferred. Mitigation is therefore not the default answer, but what remains when the other options are not enough or make no sense.
The same publication also describes combining responses over time. The NIST example: in an emergency, an organization accepts for a limited time the risk of an unfiltered connection to an external communications provider, then avoids it by cutting the connection. In the near term it mitigates the risk by searching for malware and evidence of unauthorized access from the period of the unfiltered connection. In the long term it applies controls that let it handle such connections more securely. A risk decision is rarely a one-off.
Key takeaways:
- Risk treatment is a choice: acceptance, avoidance, mitigation, or transferring or sharing the risk.
- According to NIST SP 800-39, mitigation covers the portion of risk that cannot be accepted, avoided or transferred.
- Responses can be combined over time, for example a short acceptance followed by a target control.
- Every decision needs an owner and a review date.
When is risk acceptance the right decision?
Risk acceptance is the right decision when the risk is within the organization’s risk tolerance. That is the definition in NIST SP 800-39. Acceptance does not mean neglect, but a conscious judgment that the cost of further action exceeds the benefit or that the risk is small enough for the company to absorb.
The precondition is knowing the tolerance, the limit above which the organization does not want to take on risk. Without it, acceptance becomes an excuse. If the board has never said what downtime, data loss or financial impact it considers bearable, every system owner sets that limit their own way.
NIST notes that organizations can accept low, moderate or even high risk if compelling business needs justify it. The decision to take on high risk should, however, be made at a sufficiently senior level, not in a team that will not bear its consequences.
A good acceptance has three elements: a justification, the person who signed it and a date for the next review. An acceptance without a date turns into oblivion, and a risk accepted for the duration of a system migration can survive in the register for years after the migration ends.
When is it better to avoid a risk than to reduce it?
It is better to avoid a risk when it exceeds the organization’s tolerance and effective controls are impractical or too expensive. NIST SP 800-39 describes avoidance as eliminating the activities or technologies that are the basis for the risk, or changing them so that the unacceptable risk does not arise.
In IT, avoidance usually looks mundane. The company switches off a service nobody uses any more that is still reachable from the internet. It drops an integration that would require opening access to the finance system for an external application. It does not keep data it does not need, and data it does not have cannot leak.
Avoidance is often underrated because it means giving up something that someone in the company considers necessary. The security team would rather propose another control than question the point of the activity. Yet retiring an outdated system often costs less than years of securing it.
It is worth remembering that avoiding one risk can create another. Turning off a Remote Desktop (RDP) service exposed to the internet in favor of VPN access removes the direct exposure of that service, but remote work then depends on the VPN gateway, which has to be patched and protected. That is no reason not to avoid, only a reason to assess the new situation from scratch.
What does risk mitigation look like in practice?
Risk mitigation in practice means implementing technical, organizational or process controls that reduce the likelihood of an event or limit its impact. NIST SP 800-39 also calls it risk reduction and stresses that the measures depend on the organizational level at which the decision is made.
The same document gives examples from three levels: common controls at the organization level, process re-engineering at the business process level and new or enhanced safeguards at the system level. For an IT reader this means that mitigation is not only a tool. A procedure for confirming a supplier’s bank account change is also mitigation, and often a cheaper one than another filter.
Controls are worth choosing according to what they act on. Some prevent the event, such as multi-factor authentication. Some shorten detection time, such as log monitoring. Some limit the impact, such as backups isolated from the production network. A plan built only on prevention leaves the company with no answer to the event that could not be prevented.
Mitigation also has a cost that does not end with the purchase. A control has to be maintained, updated and checked to see whether it still works. A control that nobody tests looks the same in the risk register as one that works, and the difference only shows after an incident.
Do cyber insurance and outsourcing transfer the risk?
Insurance transfers the financial consequences of a risk (within the sum insured, the deductible and the exclusions), and outsourcing shares responsibility for handling the risk. Neither of them removes the risk itself. NIST SP 800-39 explicitly states that risk transfer reduces neither the likelihood of harmful events occurring nor their consequences. A policy can cover part of the cost of an incident, but it will not prevent the incident.
NIST distinguishes two variants. Risk transfer shifts the entire responsibility, for example the financial liability, to another organization, and insurance is the typical example. In practice a policy has limits, so part of the consequences stays with the company anyway. Risk sharing shifts only a portion of it, usually to an organization better equipped to handle it. Outsourcing security services is more often sharing than transfer.
In practice, three questions are worth asking about cyber insurance. What does the policy exclude, and which controls does it require as a condition of payout? Who pays for downtime that cannot be priced in the contract? What about obligations to the regulator and customers, which no policy takes over? We cover choosing a policy in the article on cyber attack insurance.
The same goes for outsourcing: a contract can shift the duty to respond onto the supplier, but accountability to data subjects and to the supervisor stays with the company. Transfer without oversight of the supplier only moves the risk to a place you cannot see.
What should you do with residual risk?
Residual risk, the risk that remains after controls are in place, has to be consciously accepted or put through another decision. No control brings risk down to zero, so every mitigation in practice ends with accepting what is left.
The most common mistake is closing the item in the register at the moment the control is implemented. The risk is marked as “handled”, even though nobody has assessed how much of it remains. A year later nobody knows whether the control works and whether the residual risk is still within tolerance.
Good practice is a reassessment after implementation and a separate sign-off for the residual risk. If it stays above tolerance, it goes back on the table with the full list of options: another control, transferring part of the impact or giving up the activity that creates it.
Residual risk also has to be watched over time. Threats, systems and people change. Indicators that show whether a control still works, such as the share of accounts with a second factor enabled or the result of a backup restore test, are a better signal than an annual spreadsheet update.
What do GDPR and NIS2 require in risk treatment?
GDPR and NIS2 require security measures to match the risk and the organization to be able to demonstrate it. As of 13 November 2026, Article 32(1) of the GDPR requires the controller and the processor to implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk.
Article 32(2) GDPR adds that in assessing the appropriate level of security, account is taken in particular of the risk of accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data. The provision gives examples of measures (pseudonymization, encryption, the ability to restore availability, regular testing), but makes their selection depend on the risk.
The NIS2 Directive in Article 21(1) requires Member States to ensure that essential and important entities take appropriate and proportionate technical, operational and organizational measures that provide a level of security appropriate to the risk, taking into account, among other things, the cost of implementation. Article 21(2) lists among the mandatory elements policies on risk analysis and policies and procedures to assess the effectiveness of cybersecurity risk-management measures.
That last point links directly to residual risk: NIS2 expects not only a decision, but also a check that the chosen measures work. The risk management process is also described in ISO 31000:2018 (guidelines on risk management) and ISO/IEC 27005:2022 (guidance on managing information security risks).
How do you choose the right risk treatment option?
You choose the right risk treatment option by comparing the risk with the organization’s tolerance first, and only then the cost and feasibility of each option. The matrix below does not replace a risk assessment, since it assumes the assessment exists, but it structures the decision and shows what trail it should leave.
| Situation after risk assessment | First option to consider | Condition that must be met | Typical trap | Evidence for the auditor |
|---|---|---|---|---|
| Risk is within tolerance | acceptance | tolerance approved by the board | acceptance without a review date | signed acceptance with justification and date |
| Risk above tolerance, activity unnecessary or outdated | avoidance | business owner agrees to withdraw it | withdrawal without checking dependencies | withdrawal decision and confirmation of shutdown |
| Risk above tolerance, activity necessary | mitigation | the control really lowers likelihood or impact | implementation without reassessment | implementation plan and reassessment result |
| Financial impact exceeds what the company can bear | transfer (e.g. insurance) | known exclusions and policy conditions | treating the policy as a control | policy, conditions and list of requirements met |
| No skills or resources to handle the risk | sharing (e.g. external service) | contract with a measurable scope and oversight | belief that accountability moved to the supplier | contract, supplier reports, reviews |
| Urgent risk, target solution needs time | combination over time | every stage has an owner and a deadline | temporary acceptance with no end | stage plan with dates and status |
| Residual risk remains after implementation | residual acceptance or another decision | reassessment after implementation | closing the item when the control goes live | residual assessment and separate sign-off |
The matrix works best as a column in the existing risk register rather than a separate document. Each item then gets not only a rating, but also the chosen option, an owner, a review date and evidence.
Key takeaways:
- Compare the risk with tolerance first, and only then the cost of the options.
- A policy and a supplier contract transfer responsibility; they are not controls.
- Every decision, acceptance included, leaves evidence: a signature, a justification and a review date.
How can nFlo help with risk treatment?
In the area of governance, risk and compliance, nFlo helps move from risk assessment to decisions that hold up in front of the board and the auditor. Within the ISO/IEC 27005 service we put the information security risk management process in order, from asset identification to risk treatment and formal acceptance of residual risk.
The reviews, audits and consulting in the area of risk analysis service ends with a risk register with likelihood and financial impact ratings and a risk treatment plan with a cost-benefit analysis. As a result, every decision, from acceptance to transfer, has a justification that can be presented to the board.
If you want to check whether risk decisions in your organization meet GDPR and NIS2 expectations, contact us.
What else is worth knowing about risk mitigation?
How does risk mitigation differ from risk management?
Risk management is the whole cycle: identification, analysis, evaluation, treatment and monitoring. Mitigation is one of the decisions at the treatment stage, alongside acceptance, avoidance, and transferring or sharing the risk.
Does cyber insurance replace security controls?
No. NIST SP 800-39 states that risk transfer reduces neither the likelihood of an event nor its consequences. A policy can cover part of the financial loss, but it does not restore systems, protect data or relieve the company of its obligations to the regulator.
Who can accept a risk in a company?
A person with the authority to decide at the given risk level, usually the risk owner. Under Article 20 of the NIS2 Directive, management bodies of essential and important entities are to approve cybersecurity risk-management measures and oversee their implementation, so acceptance of high risk should go to that level.
How often should risk treatment decisions be revisited?
After every significant change in the environment, after an incident and periodically, in line with risk reviews. This applies in particular to acceptances granted for a limited time and to residual risk after controls are in place.
Does every risk have to be mitigated?
No. A risk within the organization’s tolerance can be consciously accepted, and an activity that creates unacceptable risk is sometimes better withdrawn. Mitigation makes sense where the risk cannot be accepted, avoided or transferred.
