Yes, with adaptation. Agree a written limit on overdue security items, such as how many may be past their service level. When the limit is crossed, a pre-agreed policy shifts capacity from features to fixes until the count is back inside. The rule makes the tradeoff automatic instead of political.
The idea you are borrowing
Reliability teams use error budgets to balance stability with the pace of change. An example policy published by Google's SRE team says that if a service has exceeded its error budget for the preceding four-week window, all changes and releases halt, other than top priority issues or security fixes, until the service is back within its objective. It adds that the policy is not meant as punishment, and that it gives teams permission to focus on reliability when the data says it matters more than features.
The useful part is the permission. Nobody has to win an argument. The data triggers the shift.
Translate it to security
You need three things: a measure, a limit and a consequence.
| Element | Reliability version | Security version |
|---|---|---|
| Measure | Errors against an objective | Open items past their service level |
| Limit | Budget for the window | A count or share of overdue items you tolerate |
| Consequence | Pause releases, focus on reliability | Shift sprint capacity to fixes until under the limit |
Choose the measure carefully. Weight by exposure so a pile of low risk items does not trip the policy, while one overdue item on an exploited, internet facing service does.
Draft the policy in six lines
- Scope. Which services and which severities count.
- Measure. Items past their service level, counted weekly.
- Limit. The count that triggers action. Pick it from your own history.
- Action. The share of next sprint capacity moved to fixes, and which work yields.
- Exit. The count at which normal planning resumes.
- Escalation. Who decides if the data is disputed. The Google example names the CTO for this role.
Start soft. A first version that triggers once a quarter will be adopted. One that triggers every sprint will be ignored.
Make it fair
Teams resent a policy that punishes them for causes outside their control. Borrow the exemptions from the reliability example: the team may continue feature work if the cause was another team's frozen dependency, or if the cases counted were outside the policy's scope. For security, exempt items that are blocked by a vendor with no fix, as long as a formal exception exists. See what to do when a vulnerability has no fix available.
What to watch for
- Gaming. Teams may close items by raising exceptions. Audit exceptions for expiry and reasons, as in vulnerability exception metrics.
- Metric drift. Keep the definition of "overdue" fixed. See when does the SLA clock start.
- Cliff effects. A sudden full stop of features is hard to plan around. Move a share of capacity, not all of it.
How to introduce it
Pilot it with one willing team for a quarter. Share the data openly, review the triggers, and adjust the limit once. Then ask executives to endorse it, since the policy only works if leaders honor the shift when it triggers.
Safeguard's compliance and evidence automation and continuous monitoring give you a current count of items against their service levels, which is the measure this policy depends on.
Quick check
Is this the same as a code freeze?
No. It shifts a share of capacity to fixes under defined conditions and ends when the count is back within the limit, rather than halting all change.
Who should approve the policy?
Engineering leadership and the product owner jointly, with an executive sponsor who agrees to honor it when it triggers.
Sources
Last reviewed: 19 October 2026.
