Finding and scoring risks is only half of the job. The third of the four questions, "what are we going to do about it?", is answered by a risk treatment decision for every entry. There are only four options, and the discipline of picking one explicitly is what separates a risk register from a list of worries.
The four options
| Option | What it means | ISO/IEC 27005 term | Example |
|---|---|---|---|
| Mitigate | Reduce likelihood or impact with controls | Risk modification | Add rate limiting and MFA to the login endpoint |
| Avoid | Remove the activity or design that creates the risk | Risk avoidance | Stop storing card numbers; let the payment provider hold them |
| Transfer | Share the risk with a third party | Risk sharing | Cyber insurance; contractual liability with a supplier |
| Accept | Knowingly retain the risk | Risk retention | Accept a low-likelihood denial-of-service risk on an internal tool |
Mitigate
The default for most risks: choose controls that lower likelihood, impact or both, then re-score to get the residual risk. A good mitigation is specific enough to become a ticket and to be verified: "verify the Stripe-Signature header on every webhook and reject events older than five minutes", not "improve webhook security". Our guide on writing a mitigation auditors accept goes into detail.
When the ideal control can't be built yet, a compensating control is a legitimate interim mitigation, as long as it actually breaks the attack path.
Avoid
The most underused option, and often the cheapest. If a feature, data field or integration creates a serious risk and little value, remove it. Data you never collect can't leak; an export endpoint that doesn't exist can't be abused. Avoidance is especially powerful early, during design, which is one of the strongest arguments for threat modeling before code is written.
Transfer
Transfer shares the consequences with someone else: an insurer, a supplier with contractual liability, or a provider who takes over a whole function (outsourcing card handling to a PCI-compliant payment provider reduces your own scope dramatically). Two caveats: transfer moves financial impact, not reputational or regulatory impact, and your customers will still hold you responsible. And some transfers create new risks of their own, which belong in the threat model as third-party risks.
Accept
Accepting a risk is a legitimate decision, not a failure, when the residual risk is within appetite or the cost of reducing it is out of proportion. It has to be done properly:
- By the right person: a risk owner with authority over the system and budget, not the engineer who found it.
- With a reason: why it's acceptable, in a sentence someone else can judge later.
- With a review date: threats and systems change, and an acceptance from two years ago is not a decision anyone made about today's system.
Worked example: Invoicely
Treatment decisions from the Invoicely risk register:
| Threat | Treatment | Decision |
|---|---|---|
| T2 IDOR on invoice endpoints | Mitigate | Ownership check in the data access layer, plus cross-tenant tests in CI |
| T3 Non-expiring PDF links | Avoid | Stop emailing raw storage links; send a link to the app that requires login or a short-lived signed URL |
| T4 Forged payment webhook | Mitigate | Verify webhook signatures and reject stale events |
| Card data theft | Transfer | Card numbers never touch Invoicely: Stripe's hosted fields collect them |
| T10 Mistyped email exposes invoice | Accept (partly) | Residual risk after the T3 fix is low; product owner accepts, review in six months |
The T3 decision is a good example of avoidance closing more than one threat: removing open links also shrinks T10.
The risk treatment plan
Standards such as ISO/IEC 27001 (clause 6.1.3) expect a risk treatment plan: the chosen option for each risk, the controls to implement, who is responsible, the timeline, and approval of the plan and the residual risks by the risk owners. A well-kept risk register with a treatment, owner and ticket for every entry is most of that plan already.
Common mistakes
- "Mitigate" with no specific control. If you can't write the ticket, you haven't decided anything yet.
- Accepting by default. Risks that sit in the register with no decision for months have been accepted by nobody. That's the worst outcome, and it's how registers turn into backlogs.
- Never considering avoidance. Ask "do we need this at all?" before designing controls for it.
Key takeaways
- Every risk gets one of four treatments: mitigate, avoid, transfer or accept. "We'll look at it later" is not one of them.
- Avoid is underused. Not building a risky feature, or not storing data you don't need, is often the cheapest fix.
- Transfer moves financial impact, not the incident. Your customers still blame you.
- Acceptance is legitimate when a named owner with authority makes it, with a reason and a review date.
Frequently asked questions
What are the four risk treatment options?
Mitigate (reduce the risk with controls), avoid (stop the activity that creates it), transfer (share it with a third party such as an insurer or supplier) and accept (retain it knowingly). ISO/IEC 27005 calls them risk modification, risk avoidance, risk sharing and risk retention.
What is the difference between risk mitigation and risk avoidance?
Mitigation keeps the activity and adds controls to reduce the risk. Avoidance removes the activity or design so the risk no longer exists, for example deleting a legacy export feature instead of securing it.
Is cyber insurance risk transfer?
Yes, partly. Insurance transfers some of the financial impact of an incident. It does not transfer reputational damage, regulatory liability or the operational disruption, and insurers increasingly require baseline controls before they will cover you.
When is it acceptable to accept a risk?
When the residual risk is within the organisation's risk appetite, or the cost of reducing it outweighs the benefit, and a risk owner with the authority to do so signs off with a documented reason and a review date.