Ownership should be layered. One executive is accountable for supply chain risk, a small central function sets rules and coordinates, and each engineering team owns the components in the software it ships. Security advises and measures, but it should not be the sole owner.
Why one owner is not enough
Third-party software touches procurement, legal, engineering, IT and security. NIST SP 800-161 Rev. 1 lists acquisition and procurement, information security, information technology, legal, program management and supply chain among the roles that should have defined responsibilities. It says ownership and accountability for supply chain risk ultimately lie with the head of the organization, and that ownership should be delegated to officials with executive authority over the affected missions or business operations.
In plain terms: someone senior has to answer for the risk, and that person has to be able to decide trade-offs between speed and safety.
A three layer ownership model
| Layer | Owner | Owns |
|---|---|---|
| Accountable | Executive sponsor (often CISO, CTO or a risk executive) | Risk appetite, budget, escalations |
| Coordinating | Central supply chain function or program office | Policy, standards, tooling, reporting, exception board |
| Operating | Engineering and product teams | Their dependencies, upgrades, fixes, exception requests |
NIST describes a central program management office that can chair working groups, host tools and templates, run supplier and product risk assessments, manage the risk register and report to leadership. It also says that office should include people from several functions, not solely security.
What each layer must not do
- The executive should not approve every exception personally. Delegate by risk level.
- The central team should not fix other teams' dependencies. It sets the standard and measures results.
- Engineering teams should not self-approve exceptions to their own blocked builds. See can the code owner approve their own exception.
Central or decentralized?
NIST notes the trade-off. An organization with tight budgets or strict requirements may centralize decisions and let a central office take on heavy work such as vendor risk assessments. An organization whose business units run with a high degree of autonomy may choose decentralized authority. There is no single right answer. Pick the model that matches how your company already makes decisions, or the structure will be ignored.
A practical hybrid: central policy and tooling, federated operations, central review above a risk threshold.
Try it yourself
Click through it at your own pace, or open it full screen. Look for the assignment step and ask which of the three layers would own it in your company.
Steps to put this in place
- Name the accountable executive in writing.
- Name a coordinating lead and two or three part-time representatives from engineering, IT, procurement and legal.
- Map every service or product to a team that owns its dependencies.
- Publish who approves what, by risk level.
- Review the model after two quarters and adjust.
Safeguard's asset discovery and SBOM and dependency scanning help establish which team owns which components, and policies and gates apply the rules that the owners agreed.
Quick check
Should the CISO own all supply chain risk?
The CISO can be the accountable executive, but engineering must own fixing its own components. Security alone cannot upgrade other teams' code.
Do we need a dedicated program office?
Not at first. A named lead with matrixed representatives can do the job until the volume of reviews justifies dedicated staff.
Sources
- NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices, PDF at nvlpubs.nist.gov
Last reviewed: 19 October 2026.
