Once a risk is scored, someone has to decide what to do about it. Every risk method offers the same four choices, usually named mitigate, transfer, accept and avoid. They sound simple. In practice, teams pick "mitigate" for nearly everything, treat insurance as if it made a risk disappear, and accept risks without anyone with authority agreeing.
Each option is a different commitment. Each leaves different evidence, and each fails in a different way under audit. Choosing well means knowing what you are signing up for before the register says "mitigate" by default.
This article explains the four options, how the standards name them, what each one obliges you to do and record, and how to combine them.
Where the four options come from
ISO/IEC 27001:2022 clause 6.1.3 a) requires you to select appropriate risk treatment options, taking account of the risk assessment results. It does not list the options. That is left to supporting guidance.
ISO/IEC 27005, the guidance on information security risk management, has long described four options: modifying, retaining, avoiding and sharing risk. Its 2022 edition aligns its wording with the longer list in ISO 31000, which these four still cover. NIST's risk management guidance, SP 800-39, names the responses as accepting, avoiding, mitigating, sharing and transferring. The common four-word set maps onto both.
| Common term | ISO/IEC 27005 term | What you are doing | Evidence it leaves |
|---|---|---|---|
| Mitigate | Modification | Changing likelihood or impact with controls | Linked controls, actions with owners and dates, a lower target rating |
| Transfer | Sharing | Moving part of the consequence to another party | The contract or policy, and an assessment of what it covers |
| Accept | Retention | Keeping the risk at its current level, deliberately | A dated acceptance by someone with authority, with a review date |
| Avoid | Avoidance | Removing the activity or condition that creates the risk | The decision, and proof the activity stopped |
The names matter less than the rule underneath: every option is a decision, and every decision needs an owner and a record.
Mitigate: change the likelihood or the impact
Mitigation is adding or improving controls so that the risk is less likely, less damaging, or both. It is the right answer for most risks above your acceptance threshold, and it is the option auditors probe hardest.
A mitigation decision commits you to three things:
Specific controls. Name the control, not the intention. "Improve access management" is an aspiration. "Enforce SSO with MFA for the production cloud console" is a control.
A plan with owners and dates. Clause 6.1.3 e) requires a risk treatment plan, and clause 8.3 requires you to implement it. Every mitigation action needs someone responsible and a target date.
A re-rating. Once the controls are in place, rate the risk again. If the rating does not drop, either the controls address the wrong cause or the original rating was wrong.
The common failure is mitigation that never finishes. The register says "mitigate", the action has been open for a year, and the risk has been sitting at its original level the whole time. Untreated, that is an acceptance nobody signed. If an action slips, record the slip and decide again.
Transfer: move part of the consequence, not the accountability
Transfer, or sharing in ISO terms, moves some of the consequence to another party. The usual instruments are insurance and contracts.
Insurance can cover parts of the financial consequence: incident response costs, some third-party claims, business interruption, depending on the policy. It does not cover everything. It does not restore customer trust, and it does not discharge your regulatory obligations. Policies have exclusions, conditions and sub-limits, and some require specific controls to be in place for a claim to pay. Read the policy against the risk before recording it as transferred.
Contracts move consequence through indemnities, liability terms and service credits. A service credit for downtime compensates you a little; it does not keep your own customers online.
Outsourcing is often recorded as transfer, but it changes the risk more than it moves it. Hosting with a cloud provider removes some risks and creates a vendor risk in their place, which you then have to assess.
Accept: retain the risk on purpose
Acceptance means deciding to keep a risk at its current level. It is a legitimate choice, often the right one for low risks or risks where every treatment costs more than the harm it prevents. It is also the option most often recorded badly.
An acceptance that holds up has four parts:
It is informed. The person accepting understands the risk, its rating, and the treatments considered. ISO 31000 describes retention by informed decision, and the word informed is the point.
It is made by someone with authority. Clause 6.1.3 f) requires risk owners to approve the treatment plan and accept residual risk. Risks above your risk appetite should need more senior sign-off than risks inside it.
It is recorded. A name, a date, the rating accepted and the reasoning. "Discussed at the security meeting" is not an acceptance.
It expires. Every acceptance carries a review date. Conditions change, and an acceptance that never comes up again has quietly become permanent.
Acceptance also covers residual risk after other treatments. Every mitigated risk ends with some risk left over, and someone has to accept that remainder.
Avoid: stop doing the thing
Avoidance removes the risk by removing its source. You decide not to launch a feature, not to enter a market, not to collect a category of data, or to retire a system.
Avoidance is underused because it feels like losing. It is often the cheapest treatment on the list. A company that stops collecting dates of birth it never used has removed a risk no control could reduce as completely. A team that retires an old admin panel instead of patching it has avoided every future vulnerability in that panel.
The evidence for avoidance is the decision and proof it took effect: the data deleted, the system decommissioned, the feature removed from the roadmap. A risk marked "avoided" while the activity continues is not avoided.
Avoidance has costs too. If the activity is central to how the business makes money, avoidance is not available, and the risk has to be treated another way.
Combining options
Most real risks use more than one option. A typical pattern:
Mitigate the risk with controls until it is as low as is reasonable.
Transfer part of the remaining financial consequence through insurance or contract.
Accept the residual risk, recorded by the owner, with a review date.
For example, take a hypothetical company whose risk is a ransomware incident disrupting production. It mitigates with immutable backups, endpoint protection and tested restores. It transfers part of the financial impact through a cyber policy whose terms it has checked. The head of engineering accepts the residual risk of a short outage, with a review set for six months. Each step leaves its own record, and together they tell an auditor a complete story.
What the auditor will look for
When an auditor samples a risk, they follow the treatment decision. They expect it to match the rating under your method, using the scales described in risk scoring. They then look for evidence specific to the option chosen: implemented controls for mitigation, a real contract or policy for transfer, a dated acceptance for retention, proof of cessation for avoidance.
The most frequent gap is a decision with no trail behind it. The second is an acceptance signed by someone who did not own the risk. Both are cheap to fix when the treatment is decided, and expensive to explain six months later. The clause 6 walkthrough covers how treatment feeds the Statement of Applicability under ISO 27001.
How TrustLynce helps
TrustLynce's risk management module records the treatment option for each risk with its linked controls, actions, owners and dates. Acceptances are captured against the named owner with a review date, so expiring acceptances come back for a decision instead of becoming permanent.