Risk avoidance
Also known as: risk elimination, risk termination
Removing a risk entirely by not doing, or no longer doing, the activity that creates it.
Draft - this entry has not been reviewed yet.
Formal
The risk treatment option in which the organisation decides not to start, or to stop, the activity, system or data handling that gives rise to the risk, so the risk no longer exists.
In plain English
Like selling the trampoline because the children keep getting hurt - no more jumping, but also no more broken arms.
In practice
A fitness chain finds an old database of former members that nobody uses; rather than protect it, it deletes it - data it no longer holds cannot leak.
Why it matters
It is the only option that removes a risk completely, but it also gives up whatever value the activity had, so it suits risks that bring the business little gain.
How to put it into practice
The usual steps, in order. Adapt them to your organisation.
- Look through the risk register for risks above appetite where the activity behind them brings little value, such as unused data, legacy systems or features nobody needs.
- For each candidate, work out with the owner of the activity what the business would give up, and whether a changed form of the activity would be enough, which would be mitigation rather than avoidance.
- Have the activity owner or management make and record the decision to stop or not start the activity, with the reason taken from the risk assessment.
- Plan the exit in full, including data in backups, logs, exports, test environments and at SaaS providers, and align backup retention and deletion deadlines with it.
- Offer an approved alternative where people still need the function, so a ban on a tool does not push them into personal accounts and shadow IT.
- Carry out the deletion or shutdown and verify it, for example by searching for the data and checking that the system and its accounts are gone.
- Close the risk in the register with the evidence, and check that any replacement process has been assessed for new risks.
- Build avoidance into daily work with data minimisation and deletion deadlines in new projects, so data that is not needed is never collected.
Common pitfalls
- Deleting data in production while copies live on in backups, exports and test systems.
- Banning a tool without an approved alternative, which moves the risk into shadow IT instead of removing it.
- Calling it avoidance when the activity continues in a changed form without a fresh risk assessment.
Good guides
- NIST SP 800-39 - Managing Information Security Risk(opens in a new tab) · NIST
- Risk management guidance(opens in a new tab) · NCSC UK
- Sletning(opens in a new tab) · Datatilsynet (in Danish)
Technical deep dive
ISO 31000:2018 clause 6.5.2 lists avoiding the risk "by deciding not to start or continue with the activity that gives rise to the risk" as the first treatment option, and ISO/IEC 27005 and NIST SP 800-39 use the same concept under the name risk avoidance. It is distinct from another option in the same list, removing the risk source: uninstalling a vulnerable plugin while keeping the website removes a source, whereas shutting down the website avoids the risk. The practical test is whether the business activity itself stops or is not started; if it continues in a changed form, the treatment is usually modification rather than avoidance.
In information security, avoidance most often appears as data minimisation and decommissioning. GDPR Art. 5(1)(c) (data minimisation) and 5(1)(e) (storage limitation) push in the same direction: personal data that is never collected, or is deleted when no longer needed, cannot be breached, requested in an access request or held for ransom. Other common forms are retiring end-of-life systems rather than trying to harden them, not launching a service in a jurisdiction with incompatible legal requirements, disabling a feature class altogether (for example blocking macros in Office files from the internet instead of scanning them), and not storing payment card numbers at all so that the processing leaves the organisation's PCI DSS scope.
Avoidance has costs and traps. It gives up the value of the activity, so it suits risks where the activity has low benefit or where every other option leaves residual risk above appetite. It has to be complete to work: data deleted from production but still present in backups, logs, exports, test environments or a SaaS provider's retention is not avoided, only moved out of sight, so deletion should be verified and backup retention aligned. And prohibition without an alternative often displaces the risk rather than removing it: banning a popular file-sharing or AI tool without providing an approved equivalent typically drives use into personal accounts as shadow IT, where the organisation has neither visibility nor contractual control.
Because the decision usually has business consequences beyond security, avoidance is normally decided by the owner of the activity or by the management body, informed by the risk assessment rather than dictated by it. It is the only option that brings a risk to zero, but only for that specific risk; the organisation still has to check that the replacement process, if any, does not introduce new ones.
What to learn first
Everything this builds on, foundations first.
- CIA triad
- →Threat
- →Asset
- →Vulnerability
- →Impact
- →Likelihood
- →Risk
- →Risk assessment
- →Risk avoidance
Relationships
- A kind of
- Risk treatment
- Requires
- Risk assessment
- Don't confuse with
- Risk mitigationRisk acceptance
- Mitigates
- Shadow IT
Sources & further reading
Standards & official texts
- ISO/IEC 27005:2022 (8.2 - Risk treatment options)
Course material
- Cyber Security Fast Track - Kursuskompendium, Modul 5 og Ordliste (Risikohåndtering - eliminere)
Where this data comes from
This entry was drafted by an AI from the sources above and has not yet been checked by a person. Treat it as a starting point, and check anything important against the sources.
See the review queueSuggest a correction on GitHubThis term as JSON
Check yourself
Loading…