Partly. The reliability error budget gives product and operations teams a shared, objective limit for risk, which ends arguments about opinion. A security risk budget can borrow the structure, a limit agreed in advance with a defined consequence, but security harm is harder to measure, so use it for exposure windows, not breaches.
What an error budget does
The Google SRE book describes the problem the budget solves. Product teams are judged on velocity, which rewards pushing code fast. Reliability teams are judged on stability, which rewards resisting change. Each side sees different information, so the two argue.
The fix is an objective metric agreed by both sides. The two teams jointly define a quarterly error budget based on the service level objective, and the budget says how unreliable the service is allowed to be within a quarter. The book says this removes politics from negotiations about how much risk to allow.
Security has the same tension. Delivery teams are rewarded for shipping, security teams for lowering risk, and each argues from different facts.
What would a security risk budget look like
The idea is a limit agreed in advance that triggers a known response when crossed. Examples that stay measurable:
| Budget | Example limit | Response when exceeded |
|---|---|---|
| Exposure window for exploited issues | Agreed maximum days an exploited issue may stay open | Pause feature work on the affected service until it is fixed |
| Overdue high risk items per service | Agreed maximum count | Review the backlog and add capacity |
| Exceptions past expiry | Zero | Escalate to the owner and approver |
Keep the thresholds your own. The numbers should come from your risk, history, and capacity, not from a template.
Where the analogy breaks
- Reliability has a clean measure, such as the share of failed requests. Security harm is rarer and harder to see, so you must measure exposure as a proxy.
- A reliability budget can be spent on purpose, by shipping risky changes. Spending a security budget on purpose is harder to justify when the risk includes active attackers.
- Counting breaches as the measure punishes the wrong thing and hides near misses.
Because a budget is a target, Goodhart's law applies. DORA's guidance warns against setting a metric as a goal without counter metrics. Pair each budget with a signal that exposes gaming, such as severity changes and exception age.
How to try it
- Pick one budget, for example the exposure window for exploited issues.
- Agree the limit with both delivery and security leads in writing.
- Define the consequence before anything breaches the limit.
- Pair it with two counter metrics.
- Review it each quarter and change it only by agreement.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice how filtering to reachable issues shrinks the list, which is what makes a budget on exposure small enough to manage.
Safeguard's reachability analysis and policies can help narrow exposure to issues that matter, which makes limits like these easier to set and enforce. A free scan is available at https://gold.safeguard.sh/scan.
Quick check
Is a risk budget the same as an SLA?
Not quite. An SLA sets a deadline for each item. A budget sets an agreed limit across a period and says what happens when it is crossed.
Should a breach count against the budget?
It is better to budget exposure, which you can measure and control, and to treat a breach as an incident for review.
Sources
- Google SRE book, Embracing Risk
- DORA, software delivery performance metrics and common pitfalls
- Goodhart's law (Wikipedia)
Last reviewed: 19 October 2026.
