Risk Avoidance: What It Is, When to Avoid a Risk and Real SaaS Examples

Short answer: Risk avoidance means removing a risk by not starting, or by stopping, the activity, data flow, vendor or technology that creates it. It fits when the risk sits above your appetite and no proportionate control brings it down. Typical examples are using a hosted payment page instead of storing card data, or not collecting PHI you do not need.

Related guides:

• Risk acceptance: when to accept a risk and what to document
• ISO 27001 risk treatment plan
• Risk register guide

Key takeaways

• Risk avoidance eliminates the source of a risk instead of reducing it. If the activity no longer happens, the risk no longer applies to you.
• NIST lists avoidance as one of its risk responses, alongside accepting, mitigating, sharing and transferring risk. ISO 27001 asks you to select treatment options in clause 6.1.3.
• Avoid a risk when it exceeds your appetite, when no cost-effective control reduces it enough, or when a law or contract effectively prohibits the activity in its current form.
• Avoidance has a price: lost revenue or features, and sometimes risk that moves to a vendor or another team. Record that trade-off.
• Log every avoidance decision in your risk register with an owner, rationale, evidence and a trigger to revisit it.

What is risk avoidance in risk management?

Risk avoidance is a risk response where you decide not to carry out, or to stop, the activity that gives rise to a risk, so the risk can no longer occur in that form.

Mitigation, transfer and acceptance work on the risk itself. Avoidance works on the activity, so the threat has nothing to act on.

NIST's guidance on cybersecurity risk in enterprise risk management describes avoidance as taking "actions to eliminate the activities or conditions that give rise to risk" in NIST IR 8286B-upd1, Table 1. In practice, avoidance can mean:

1. Not starting something: a new market, integration, data field or vendor.
2. Stopping something already running: retiring a feature, deleting a dataset, offboarding a vendor.
3. Redesigning something so the risky element disappears: moving card capture to a payment provider so card numbers never touch your servers.

Avoidance is not ignoring a risk: it changes the activity and records why.

Where does risk avoidance sit in NIST, ISO 31000 and ISO 27005?

Avoidance is a standard risk response in NIST guidance, and ISO 31000 and ISO/IEC 27005 place treatment decisions like it inside their risk management process.

NIST. The CSRC glossary entry for risk response, sourced from NIST SP 800-39 and SP 800-30 Rev. 1, defines it as "accepting, avoiding, mitigating, sharing, or transferring risk" So NIST's terms are accept, avoid, mitigate, share or transfer. NIST IR 8286B-upd1 groups these into four response types (accept, transfer, mitigate and avoid) and adds that avoiding risk "may be the best option if there is no cost-effective method for reducing the cybersecurity risk to an acceptable level."

ISO 31000. ISO describes the ISO 31000 family as general guidance on risk management. Treatment is a step in its process, and the detailed treatment options are in the paid standard text.

ISO/IEC 27005. ISO's page for ISO/IEC 27005:2022 describes a structured approach for "identifying, assessing and treating information security risks". ISO 27001 teams often use it as their method guide for choosing treatment options.

How does risk avoidance fit ISO 27001 clause 6.1.3 and the SoA?

ISO/IEC 27001:2022 clause 6.1.3 asks you to select appropriate risk treatment options, determine the controls needed, compare them with Annex A and produce a Statement of Applicability (SoA). An avoidance decision affects both the treatment plan and the SoA.

1. Treatment option. The risk owner records "avoid" as the selected option for the risk in your treatment plan.
2. Controls. Avoidance still needs actions, such as decommissioning a system, deleting data or changing a contract, each with an owner and date.
3. Statement of Applicability. The SoA lists necessary controls with justifications for including or excluding Annex A controls. If avoidance means a control is no longer needed, the exclusion justification should point to that decision.
4. Approval. Risk owners approve the treatment plan and accept any residual risk. With avoidance, residual risk is often low, but rarely zero.

One caution: avoidance in one area does not let you exclude a control that other risks still need. An auditor will expect each SoA justification to match your risk assessment. Our ISO 27001 Statement of Applicability guide covers the justification format.

When should you avoid a risk instead of mitigating it?

Avoid a risk when the value of the activity is lower than the risk it leaves behind after reasonable controls, or when the activity conflicts with a rule you cannot work around.

Use these decision criteria:

• Residual risk stays above appetite. After realistic mitigation, the risk still exceeds what leadership approved, so acceptance is off the table.
• Value is lower than the residual risk. The feature, data or market brings less benefit than the remaining exposure plus the cost of controls.
• No cost-effective control exists. This is the NIST IR 8286B-upd1 test: if you cannot reduce the risk to an acceptable level at a sensible cost, avoidance may be the best option.
• A law, regulator or contract effectively prohibits it. If a requirement forbids the activity, or you cannot meet its conditions, stopping is the safe path.
• A cheaper alternative achieves the same goal. You can meet the business need without the risky element.

If most boxes are unchecked, start with mitigation. Our risk mitigation strategies guide covers the control side.

What are good risk avoidance examples for SaaS and HealthTech?

The best risk avoidance examples remove a data flow, vendor or capability that the business does not truly need.

Scenario	Risk avoided	How you avoid it	What remains
Taking card payments	Breach of stored card data and a large PCI DSS scope	Use a hosted payment page or embedded form from a PCI DSS compliant provider so card numbers never reach your systems	You still validate PCI DSS, often with a shorter questionnaire, and you manage the provider relationship
Patient intake form	Exposure of PHI fields you never use	Remove fields such as full date of birth or SSN when the product does not need them	Remaining PHI still needs HIPAA safeguards
High-risk vendor	Third-party breach or weak data handling	Drop the vendor, or choose one that does not need PHI access	Migration effort and a new vendor to assess
New market launch	Regulatory obligations you cannot yet meet	Delay or skip the launch in that jurisdiction	Lost revenue in that market
Risky feature	Abuse of a public file-sharing link or an unvetted AI integration	Disable or never ship the feature	Customer requests you must decline

Card data. PCI SSC's January 2025 update on SAQ A confirms that SAQ A applies to merchants whose account data functions are completely outsourced to PCI DSS validated and compliant third parties. Under the changes PCI SSC announced, effective 31 March 2025, those merchants also need to confirm their site is not susceptible to script attacks that could affect their e-commerce systems. So avoiding card storage shrinks scope, but does not remove PCI DSS obligations entirely.

PHI you do not need. Under 45 CFR 164.502(b), covered entities and business associates must make reasonable efforts to limit protected health information to the minimum necessary to accomplish the intended purpose of a use, disclosure or request. HHS explains the standard in its minimum necessary guidance. Data you never collect cannot be exposed.

What are the downsides of risk avoidance?

Avoidance costs you the opportunity the activity offered, and it can quietly move risk somewhere else.

• Lost opportunity. NIST IR 8286B-upd1 states that "the cost of the lost opportunity associated with such a decision should be considered as well." Skipping a market or feature has a revenue cost.
• Risk shifting. Outsourcing card capture moves part of the risk to your payment provider. You now depend on their security and availability, which is a vendor risk you must manage.
• Workarounds. If you ban a tool without offering an alternative, staff may use unapproved tools instead, creating shadow IT.

Before signing off, ask what new or changed risks the decision creates, and register them separately.

Risk avoidance vs mitigation, transfer and acceptance

The core difference is that avoidance removes the activity, while the other options keep the activity and change the risk around it.

Option	What you do	Activity continues?	Typical residual risk	SaaS example
Avoid	Stop or never start the risky activity	No	Low, but watch for risk shifted elsewhere	Hosted payment page instead of storing card data
Mitigate	Add or improve controls	Yes	Reduced to an approved level	Enforce MFA and encryption on the PHI database
Transfer (share)	Shift part of the consequences to a third party	Yes	Unchanged likelihood, reduced financial impact	Cyber insurance or contractual liability terms
Accept	Keep the risk and monitor it	Yes	Unchanged, within criteria	Low-risk internal tool without SSO, reviewed in 90 days

For the detail on the alternatives, see our risk mitigation guide and the risk acceptance guide linked above.

How do you document an avoidance decision in a risk register?

Record an avoidance decision like any other treatment: in the risk register entry, with an owner, rationale, actions, evidence and a review trigger.

Field	What to record
Risk ID and title	The reference and a short description of the risk
Activity avoided	The specific feature, data flow, vendor or market you will not pursue or will stop
Inherent risk score	Likelihood and impact before treatment
Treatment option	"Avoid"
Rationale	Why avoidance beats mitigate, transfer or accept, including the appetite, cost or legal criteria used
Opportunity cost	Revenue, features or customers given up
Shifted or secondary risks	New risks created, each linked to its own register entry
Actions and due dates	Decommissioning, data deletion, contract changes, configuration changes
Evidence	Deletion records, change tickets, vendor offboarding confirmation, updated data flow diagram
Risk owner and approver	Who decided and who has authority for that risk level
Revisit trigger	Events that reopen the decision, such as a new customer demand, a new vendor option or a regulatory change

Avoidance decisions age, so the revisit trigger matters.

How SecureSlate helps

SecureSlate's risk management module gives you one place to record risks, treatment decisions such as avoidance, owners and review dates. Multi-framework control mapping across built-in frameworks including ISO 27001, SOC 2, HIPAA and PCI DSS helps you see which controls an avoidance decision affects, so your treatment plan and SoA justifications stay consistent. When avoidance means dropping or replacing a supplier, vendor risk management tracks the offboarding and the new vendor's assessment. Agentless read-only cloud integrations help you collect evidence for related controls, and audit management keeps it organized for your auditor.

Start your free SecureSlate trial

FAQ

What is an example of risk avoidance?

A SaaS company that needs to take card payments uses a PCI DSS compliant provider's hosted payment page, so card numbers never pass through its own systems. It avoids the risk of storing card data, though it still has PCI DSS validation duties and a vendor to manage.

What is the difference between risk avoidance and risk mitigation?

Risk avoidance removes the activity that creates the risk, so the risk cannot occur in that form. Risk mitigation keeps the activity and adds controls to reduce the likelihood or impact to an acceptable level.

When should you avoid a risk?

Avoid a risk when it stays above your risk appetite after realistic controls, when the activity is worth less than the remaining risk, or when a law or contract effectively prohibits it. Weigh the lost opportunity before deciding.

Do I need to document risk avoidance for ISO 27001?

Yes. Clause 6.1.3 asks you to select appropriate risk treatment options and formulate a treatment plan, so an avoidance decision belongs in that plan. Keep any related SoA justifications consistent with it.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory or professional advice. Requirements vary by framework, industry and jurisdiction. Consult qualified advisors for your specific obligations.