Run a dependency exception review board as a short, scheduled meeting with a fixed quorum, a standard request form, three allowed outcomes (approve with expiry, deny, defer for information), and a rule that requesters and their managers do not vote on their own cases. Log every decision.
Why a board and not a ticket
Some exceptions are routine and can be approved by a named owner using clear rules. A board is for the harder ones: higher risk, unclear compensating controls, or a supplier that matters to the business. SSDF practice PO.1.2 includes an example of establishing and following processes for exception requests, with periodic reviews of all approved exceptions. A board makes that review real.
Who sits on it
Three to five voting members is plenty.
- Security, for risk judgment.
- Engineering leadership from outside the requesting team.
- Product or business owner for the affected system.
- Legal or procurement when licenses or contracts are involved.
Add a secretary who prepares the pack and records outcomes. Set a quorum, for example three members including security.
The request pack
Every request should arrive in the same form. See what to put in a security exception request. In short: the component and version, the issue, the affected systems, why it cannot be fixed now, compensating controls, requested end date and the named owner.
Three outcomes
| Outcome | Meaning |
|---|---|
| Approve with expiry | Time limited, scoped to named assets, owner recorded |
| Deny | The team must fix or remove, with a due date |
| Defer | Specific missing information, a new date within a week or two |
Avoid open ended approvals. A decision without an end date is a permanent policy change that nobody agreed to. See how long should a vulnerability exception last.
A thirty minute agenda
- Review exceptions expiring in the next thirty days (10 minutes).
- Decide new requests, ordered by risk (15 minutes).
- Note any pattern, such as the same library appearing again (5 minutes).
Patterns matter. Five requests about the same unmaintained package is a signal to fund a replacement, not to keep approving.
Rules that keep the board honest
- The requester presents, then leaves the vote.
- Dissent is recorded in the log.
- Approvals that renew twice go to the steering committee.
- An emergency path exists, with review at the next meeting.
Try it yourself
Click through it at your own pace, or open it full screen. Notice what evidence about exploitability could strengthen or weaken an exception request.
Safeguard's reachability analysis and policy features can show whether a vulnerable function is actually called and record exceptions with expiry alongside the finding, which gives a board better inputs.
Quick check
How often should the board meet?
Every two weeks or monthly, depending on volume, with an emergency route in between.
Can the board approve permanently?
It should not. Use expiry dates and renewal reviews.
Sources
Last reviewed: 19 October 2026.
