Risk Treatment: Mitigate, Accept, Transfer, or Avoid

TL;DR

The four treatment options are mitigate (reduce risk), accept (consciously bear it), transfer (shift to third parties), and avoid (eliminate the cause).
Most risks are mitigated. Acceptance is not a sign of negligence but a deliberate business decision when the risk level is justifiable.
Every treatment decision must be justified by a cost-benefit analysis and documented in the risk register.
Residual risk always remains. It must be reassessed and formally accepted by executive management.
A risk treatment plan with clear responsibilities, deadlines, and success criteria makes the difference between theory and practiced security.

Assessing risks is not enough: You must also act

The risk assessment gives you a prioritized list of your information security risks. Each risk has a value, a color in the matrix, and a risk owner. That is a solid foundation, but the decisive next step is missing: What exactly do you do now with each of these risks?

ISO 27001 requires a documented risk treatment plan in Section 6.1.3. That sounds bureaucratic, but it is the moment when your ISMS shifts from analysis to action. For every identified risk, you must make a deliberate decision: Which of the four treatment options fits, what measures do you derive, and what residual risk remains after treatment?

This article walks you through the four options with concrete examples, provides decision criteria, and shows the complete process from treatment decision to formal risk acceptance by executive management.

The four treatment options at a glance

ISO 27005 defines four fundamental strategies for dealing with identified risks. In practice, you will choose different strategies for different risks and sometimes combine multiple strategies for a single risk.

Option 1: Mitigate (reduce risk)

Mitigation is the most common treatment option and means: You take measures to reduce the likelihood and/or impact of the risk. The risk is not eliminated but brought to an acceptable level.

When does mitigation fit? When the risk is too high for acceptance, the cause cannot be fully eliminated, and suitable measures are available at a justifiable cost. This applies to the vast majority of information security risks.

Example phishing risk: Your company has an elevated risk of successful phishing attacks (risk value: 12, High). You cannot prevent phishing since the attackers control that. But you can reduce the likelihood by implementing an advanced email filter, conducting regular phishing simulations, and establishing a security awareness program. At the same time, you can reduce the impact through multi-factor authentication (no access even with compromised credentials), network segmentation (limited lateral movement), and a rapid incident response procedure.

After implementing all measures, the risk value drops from 12 to 6 (Medium). The remaining residual risk of 6 is acceptable and borne by executive management.

Example data loss from hardware failure: A single server without redundancy stores business-critical data (risk value: 15, High). Mitigation measures include setting up a RAID system for local redundancy, an automatic daily backup to separate storage, a weekly offsite backup, and regular restore tests. The risk value drops to 4 (Low) after implementation.

Option 2: Accept (consciously bear the risk)

Risk acceptance means: You deliberately decide not to take further measures and bear the risk at its current level. This is not capitulation or a sign of negligence but a rational business decision.

When does acceptance fit? When the risk is already in an acceptable range (typically risk value 1-4), when the cost of further measures significantly exceeds the potential damage, when the likelihood is extremely low, and existing measures are deemed sufficient.

Example natural disaster: The risk that an earthquake destroys your company's server room in northern Germany is at a risk value of 2 (Very unlikely x Low, because critical data is already backed up in the cloud). Any further measure here would be disproportionate. You accept the risk.

Example outdated test environment: An old test environment without security updates poses a theoretical risk (risk value: 3). The environment contains no production data and is isolated from the production network. Modernization would cost EUR 15,000 and two weeks of effort. The potential damage in an incident would be under EUR 2,000. Acceptance is the economically sensible decision.

Important: Risk acceptance must always be documented and approved by the responsible authority. A risk that nobody has consciously accepted is not an accepted risk but an ignored risk. The difference matters in an audit.

Option 3: Transfer (shift the risk)

Risk transfer means: You shift the financial impact of the risk wholly or partially to a third party. The risk itself does not disappear, but the economic consequences are shared.

When does transfer fit? When the financial impact upon occurrence would be very high, when complete mitigation is too costly or impossible, and when suitable transfer instruments are available on the market.

The most common forms of risk transfer in information security are:

Cyber insurance: A cyber policy typically covers costs for incident response, business interruption, data recovery, legal counsel, and in some cases ransom payments. The insurance does not eliminate the risk. A ransomware attack causes operational damage even with insurance. But it absorbs the financial shock and secures the company's existence.

Outsourcing to specialized service providers: When you outsource the operation of your servers to a managed service provider, you transfer part of the operational risks. The provider assumes responsibility for availability, patching, and monitoring per SLA. However, the overall responsibility for information security remains with you as the client. You must manage, monitor, and contractually secure the provider.

Contractual liability arrangements: Through IT security clauses in contracts, you can shift liability risks to suppliers or partners. A classic example: Your software vendor is liable per SLA for data losses caused by errors in their application.

Example risk transfer through cyber insurance: Your company has a residual ransomware risk of 6 (Medium). The maximum financial damage upon occurrence is estimated at EUR 300,000. A cyber insurance policy with EUR 500,000 coverage costs EUR 8,000 per year. The insurance significantly reduces the financial risk. The operational risk (business interruption, reputational damage) remains and must be addressed through other measures.

Common misconception about risk transfer: Many believe that outsourcing completely transfers the risk. That is not true. If your cloud provider is hacked and your customer data leaks, you are responsible to your customers and regulators, not the cloud provider. You can seek recourse from the provider afterward, but the initial responsibility lies with you. Risk transfer does not mean responsibility transfer.

Option 4: Avoid (eliminate the risk)

Risk avoidance is the most radical option: You completely eliminate the cause of the risk by abandoning or fundamentally changing the risky activity, system, or process.

When does avoidance fit? When the risk is so high that no treatment can reduce it to an acceptable level, when the risky activity does not provide sufficient business value, and when a lower-risk alternative is available.

Example legacy system: A 15-year-old ERP module processes customer data but no longer receives security updates. The vulnerabilities are known and cannot be patched. The risk level is rated at 20 (Critical). Mitigation alone cannot sufficiently reduce the risk. The decision: The legacy module is shut down and replaced by a modern system. The original risk is thus completely eliminated (although the new system naturally brings its own, generally much lower, risks).

Example BYOD ban: The use of private devices to access company data creates a hard-to-control risk (data loss, malware, missing encryption). Instead of implementing complex MDM solutions and policies, the company decides to completely ban BYOD and issue managed company devices instead. The BYOD risk is thus avoided.

Example dropping a cloud service: A SaaS tool processes highly sensitive engineering data but offers no end-to-end encryption and stores data outside the EU. Instead of mitigating the risk (which is only partially possible with a third-party provider), the company drops the service and uses an on-premises alternative.

Risk avoidance sounds attractive but comes at a price. You lose the benefits of the avoided activity or system. Therefore, avoidance applies in practice only to a minority of risks, typically when the risk is critically high and the alternative is economically viable.

Decision framework: When to choose which option?

Choosing the right treatment option is not a purely technical but a business decision. A structured decision framework helps make consistent and traceable decisions.

Decision criteria

Risk value: With a low risk value (1-4), acceptance is often the right choice. With a medium value (5-9), a cost-benefit analysis for mitigation is worthwhile. With a high value (10-16), mitigation is the norm, supplemented by transfer for the financial residual damage. With a critical value (17-25), you should first check whether avoidance is possible, and otherwise choose a combination of mitigation and transfer.

Cost-benefit ratio: The cost of treatment should be in reasonable proportion to the risk. A rule of thumb: If the annual cost of the measure exceeds the expected annual loss (probability x damage amount), the measure is economically questionable. This calculation is never exact, but it prevents obvious misallocations.

Feasibility: Some measures are technically easy but organizationally difficult (e.g., enforcing stricter password policies). Others are technically complex but organizationally uncritical (e.g., network segmentation). Consider both when deciding.

Time horizon: Some risks require immediate measures (an actively exploited vulnerability), others allow a medium-term implementation timeline (modernization of a legacy application). Urgency influences which options are realistic.

Decision matrix in practice

For a typical risk register with 25 to 40 risks, the following distribution often emerges in practice:

About 50-60% of risks are mitigated. These are risks where targeted measures can significantly reduce the risk value and costs are justifiable.

About 20-30% of risks are accepted. These are low risks where existing measures are sufficient, or risks where further measures would be disproportionately expensive.

About 10-15% of risks are partially transferred, typically through a cyber insurance policy or contractual arrangements with service providers.

About 5-10% of risks are avoided, through the decommissioning of outdated systems, abandoning risky practices, or fundamental architecture changes.

This distribution varies depending on the organization's maturity level. A company that is just building its ISMS will initially need to mitigate more. A mature ISMS with established measures has a higher proportion of accepted risks because the baseline protection is already in place.

Deriving and tracking measures

The treatment decision has been made. Now it is about deriving concrete, actionable measures from the abstract strategy and systematically tracking their implementation.

Formulating concrete measures

A good measure is SMART: specific, measurable, achievable, relevant, and time-bound. Compare these two formulations:

Weak: "We should improve email security."

Strong: "By June 30, the IT department implements an email filter with sandbox analysis for incoming attachments. Success criterion: 95% of known malware samples are detected. Responsible: IT Manager. Budget: EUR 12,000/year."

The strong formulation leaves no room for interpretation. Everyone knows what needs to be done, by when, by whom, at what cost, and how success is measured.

Structuring the action plan

For each measure, you document the following information in the risk treatment plan:

The measure ID links the measure to the associated risk from the risk register. The description explains what exactly will be done. The responsible person is the individual who ensures implementation (not necessarily the same person doing the work). The deadline defines the date by which the measure must be implemented. The budget quantifies the expected costs (one-time and ongoing). The success criterion describes how the measure's effectiveness can be recognized. The status tracks progress (planned, in implementation, implemented, verified).

Prioritizing measures

With limited resources, you cannot implement everything simultaneously. Prioritize according to the principle of "greatest risk reduction per euro and time unit":

First the quick wins: measures with low effort and high impact. Example: activating multi-factor authentication for cloud services. This can often be done in a few hours and drastically reduces the risk of compromised credentials.

Then the strategic investments: measures with higher effort but very high impact. Example: network segmentation. This takes weeks but reduces the impact of almost all network-based attacks.

Finally the fine-tuning: measures that optimize existing controls. Example: fine-tuning the SIEM rule set to reduce false positives.

Tracking implementation

An action plan that nobody tracks is worthless. Establish a regular review cycle. Monthly, the ISB checks the status of all open measures and escalates delays. Quarterly, the ISB reports progress and open items to executive management. Annually, the entire risk treatment plan is reviewed as part of the management review.

Assessing and documenting residual risk

After implementing measures, residual risk always remains. No set of measures can reduce a risk to zero. The question is: How high is the residual risk, and is it acceptable?

What is residual risk?

Residual risk is the risk level that remains after all planned treatment measures have been implemented. It results from reassessing likelihood and impact taking into account the implemented measures.

An example makes this tangible: You had a ransomware risk with a risk value of 16 (Likelihood 4, Impact 4). After implementing network segmentation, an improved email filter, awareness training, and optimized backups, the likelihood drops to 2 and the impact to 3. The residual risk is 6 (Medium).

Documenting residual risk

In the risk register, you document the before-and-after assessment for each treated risk. This makes the value of the implemented measures visible and provides the basis for risk acceptance.

The documentation includes the original risk value (before treatment), the implemented measures, the new risk value (after treatment), the rationale for the reassessment (why has the value changed?), and the comparison with the defined risk acceptance level. In ISMS Lite, the before-and-after assessment is automatically documented on the risk, so the treatment success is visible at all times.

Defining the risk acceptance level

Before submitting residual risks for acceptance, you need a defined risk acceptance level. This is the threshold below which a risk is considered acceptable and requires no further treatment.

Typically, executive management determines: All risks with a value of 8 or less are generally acceptable. Risks between 9 and 12 require an individual justification for acceptance. Risks above 12 may not be accepted and must be further treated.

These thresholds are not rigid boundaries but guidelines. There can be good reasons to accept a risk with a value of 10 (e.g., when the cost of further measures exceeds the potential damage by a factor of ten). But these exceptions must be documented and justified.

Risk acceptance by executive management

ISO 27001 requires in Section 6.1.3 that risk owners approve the risk treatment plan and the remaining residual risks. In practice, this means: Executive management must consciously decide which risks they are willing to bear.

Why is formal acceptance so important?

Formal risk acceptance serves three functions. First, it ensures that executive management exercises its responsibility for information security and makes informed decisions. Second, it creates clarity and commitment: Everyone knows which risks are consciously borne and which still need treatment. Third, it is a central audit artifact. Auditors check whether residual risks are documented and approved by the appropriate authority.

Designing the acceptance process

The ISB prepares risk acceptance by creating a clear decision template. This contains a summary of all risks with their current status (treated, partially treated, accepted), a presentation of residual risks with justification, a highlight of risks that are above the defined acceptance level, and the ISB's recommendation for each risk.

Executive management reviews the template, asks questions, and makes their decision. This decision is recorded and documented in the ISMS. A simple format: For each residual risk, an entry with risk ID, description, risk value, justification for acceptance, and signature of the decision-maker. ISMS Lite maps this acceptance process digitally and generates a complete audit trail.

Common pitfalls

Blanket acceptance: Executive management signs a list without engaging with the risks substantively. This is formal compliance without real value. Better: A 30-minute briefing in which the ISB presents and discusses the five most critical residual risks.

Missing escalation: A risk is above the acceptance level, but nobody escalates it. The ISB has the obligation to actively bring such cases to executive management's attention. If executive management then decides to accept the risk anyway, that is their right. But they must be given the opportunity to make this decision consciously.

Outdated acceptance: The risk landscape changes, but the acceptance declarations still date from last year. Risk acceptance must be renewed regularly, at least annually as part of the management review.

Cost-benefit analysis: Acting economically wisely

Information security is not an end in itself but serves to protect business operations. Every investment in security measures must be measured against this standard. A structured cost-benefit analysis helps you set the right priorities.

Capturing the cost of a measure

The total cost of a security measure consists of various components:

One-time costs: Procurement (software licenses, hardware), implementation (internal effort, external consultants), employee training, migration and conversion of existing processes.

Ongoing costs: Maintenance and updates, operational effort (administration, monitoring), license costs (annual), training costs for new employees.

Indirect costs: Productivity loss during implementation, increased complexity of the IT landscape, reduced usability (e.g., MFA prompt at every login).

Assessing the benefit of a measure

The benefit of a security measure can be measured by the risk reduction. How much does the measure lower the risk value? What potential damage is prevented or reduced?

A simplified calculation example: Without the measure, the expected annual loss from a risk is EUR 200,000 (probability 20% x damage EUR 1,000,000). With the measure, the expected annual loss drops to EUR 30,000 (probability 3% x damage EUR 1,000,000). The measure thus saves an expected EUR 170,000 per year. If the measure costs EUR 50,000 one-time plus EUR 10,000 annually, it pays for itself within a few months.

When the calculation does not add up

Sometimes the cost-benefit analysis reveals that a measure is not economically sensible. This happens, for example, when a risk has high impact but extremely low probability, or when the only available measure is disproportionately expensive.

In such cases, check whether partial mitigation combined with acceptance or transfer is more sensible. Perhaps an 80-percent solution at one-fifth the cost will suffice, and you cover the rest through insurance. Or you consciously accept the remaining risk because the marginal benefit of further measures is too low.

Risk treatment as an ongoing process

Risk treatment is not a one-time exercise but a cycle that repeats and refines continuously.

The annual risk cycle

In the first quarter, you review the risk assessment. Have threats changed? Have new vulnerabilities become known? Have assets or business processes changed? You update risk values accordingly.

In the second quarter, you review the risk treatment. Have all planned measures been implemented? Are they working as expected? Do new measures need to be defined? You update the risk treatment plan.

In the third quarter, you prepare the management review. You create an overview of the risk situation, progress on measures, and residual risks. Executive management performs risk acceptance.

In the fourth quarter, you integrate insights from audits, incidents, and the management review into the next cycle. What worked well? What needs to be improved?

Event-driven reassessment

In addition to the regular cycle, certain events trigger an immediate reassessment: a security incident in your organization or a comparable company, the disclosure of a critical vulnerability in software you use, significant changes to the IT infrastructure (cloud migration, new ERP system), organizational changes (merger, new business areas, site relocation), or new regulatory requirements.

Frequently asked questions about risk treatment

Do I really have to treat every risk?

No. You must make a deliberate decision for every identified risk. But that decision can be "acceptance." Not every risk requires active measures. What matters is that the choice is documented and justified.

Can I combine multiple treatment options?

Yes, and that is often sensible. A typical example: You mitigate a risk through technical and organizational measures (reduce likelihood), transfer the financial residual damage through insurance, and accept the remaining operational residual risk. Combining different options is not a sign of indecisiveness but of thoughtful risk management.

Who decides on the treatment option?

The risk owner makes the treatment decision, advised by the ISB. For risks above the acceptance level, executive management must be involved. The ISB coordinates the process and ensures that all decisions are documented.

How often must I review the risk treatment?

At least annually as part of the regular risk cycle and the management review. Additionally, on an event-driven basis for security incidents, significant changes, or new threats.

Conclusion: Deliberate decisions instead of knee-jerk reactions

Good risk treatment is not characterized by choosing the most expensive measure for every risk. It is characterized by making a deliberate, justified, and documented decision for every risk. Sometimes the best decision is a technical measure, sometimes insurance, sometimes shutting down a system, and sometimes accepting the risk.