A decision rights matrix lists the common supply chain decisions down one side and the roles across the top, and marks who decides, who must be consulted and who is told. It prevents two failures: everything waiting for security, or nothing being reviewed by anyone.
Why bother
Governance is mostly about authority. NIST SP 800-161 Rev. 1 says Level 1 governance structures let senior leaders make decisions and delegate decisions to the mission and operational levels. Delegation solely works when it is written down. If a developer cannot tell whether they may add a library, they will either ask in chat, or just add it.
Four roles in the sample
- Team: the engineering team that owns the service.
- Review group: the small group from security, engineering and legal that handles exceptions.
- Executive: the accountable executive or steering committee.
- Incident lead: the person running an active incident.
Sample matrix
D means decides, C means consulted, I means informed. This is a starting point to adapt, not a standard.
| Decision | Team | Review group | Executive | Incident lead |
|---|---|---|---|---|
| Add a package that passes all policy checks | D | I | ||
| Add a package that fails a policy check | C | D | I | |
| Use a new open source license class | C | D | I | |
| Upgrade across a major version | D | I | ||
| Accept a known vulnerability, short and low risk | D | I | ||
| Accept a known vulnerability, high risk or long | C | D | I | |
| Onboard a new critical software supplier | C | C | D | |
| Block a package during an incident | I | I | I | D |
| Change the policy itself | C | C | D |
How to use it
- Draft the matrix with the people who will live with it.
- Replace role names with real names or groups.
- Put it where developers look, usually next to the policy.
- Enforce what you can in the pipeline. A package that passes policy needs no human. A failure routes to the review group automatically.
- Review the matrix at least yearly. SSDF PO.1.1 gives an example of reviewing requirements at least annually or after major incidents.
Signs the matrix is wrong
- The review group approves nearly everything. Tighten the automated rules or loosen the thresholds so humans see fewer cases.
- Teams complain of week long waits. Delegate more, or add reviewers.
- Executives are approving routine items. Push decisions down.
Related reading: who can approve a vulnerability exception by severity and transitive dependencies policy.
Try it yourself
Click through it at your own pace, or open it full screen. Look at which changes pass on their own and which stop for a person.
Safeguard's policies, gates and guardrails can route a failing dependency change to the right reviewer and let a passing one through, so the matrix is applied on every pull request.
Quick check
Do all new dependencies need approval?
No. Pre-approved sources and passing policy checks can be automatic. Review the exceptions.
Who approves a new critical supplier?
An executive or steering group, with security, legal and procurement consulted.
Sources
Last reviewed: 19 October 2026.
