Safeguard
Supply Chain•

How do you write a supply chain risk appetite statement?

A supply chain risk appetite statement says how much third-party software risk you will accept and where tolerances sit. Here is a plain way to draft one.

Safeguard Security Team
3 min read

A supply chain risk appetite statement is a short, leadership-approved description of how much third-party software risk the organization is willing to accept to reach its goals, with measurable tolerances for the areas that matter. It turns "we care about security" into limits that teams can apply.

Appetite and tolerance are different

NIST SP 800-161 Rev. 1 treats risk appetite and risk tolerance as inputs to supply chain decisions, and includes an appendix on supply chain risk appetite and risk tolerance. In short, appetite is the broad level of risk leaders will accept in pursuit of objectives, and tolerance is the more specific, measurable boundary around it.

TermLevelExample wording
AppetiteBroad, qualitativeWe accept low risk from components in customer-facing authentication code, and moderate risk elsewhere
ToleranceSpecific, measurableNo known exploited vulnerability may remain in production beyond the agreed window without an approved exception

NIST also says decision makers are informed by the organization's risk profile, appetite and tolerance, and that processes should address when and how risk decisions escalate. The statement is how that escalation gets a trigger.

A five step drafting method

  1. List the objectives. Revenue, uptime, customer trust, regulatory standing. Appetite is always relative to goals.
  2. Pick four to six risk areas. Examples: vulnerable components, unmaintained components, license conflict, supplier concentration, build integrity.
  3. Write appetite per area. Use plain words such as low, moderate or high, and one sentence on why.
  4. Set tolerances you can measure. Time limits, counts, coverage. If you cannot measure it, you cannot enforce it.
  5. Define escalation. What happens when a tolerance is breached, and who is told.

A short sample

This is an illustration to adapt.

  • Vulnerable components: low appetite in internet-facing services. Tolerance: known exploited issues are fixed or covered by an approved exception within the window set in the remediation policy.
  • Unmaintained components: moderate appetite. Tolerance: each has an owner and a replacement plan.
  • License risk: low appetite. Tolerance: no component outside the allowed license list ships without legal review.
  • Build integrity: low appetite. Tolerance: production artifacts come from the standard pipeline.

Pitfalls

  • Vague words alone. "Low" without a tolerance cannot be tested.
  • Copying another company's numbers. Your business and systems differ.
  • No sign-off. If leaders have not approved it, teams will treat it as security's opinion.
  • Never revisiting. Review after incidents and at least yearly.

Try it yourself

Click through it at your own pace, or open it full screen. Look at how many findings drop out when reachability is considered, and how that affects which tolerances are realistic.

Safeguard offers policies and gates that can encode tolerances, and reachability analysis that helps separate exposure from noise, so a statement can be checked against what is actually running.

Quick check

Who approves a risk appetite statement?

The accountable executive or risk committee, not the security team alone.

How long should it be?

One page. If it grows, move detail into policy.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.