21.1 Organizational Models and Ownership¶

Supply chain security spans organizational boundaries in ways that traditional security domains do not. When a vulnerable dependency affects your software, the discovery might come from a security team, the remediation falls to engineering teams, the risk assessment involves legal and compliance, and the communication requires coordination across product management and customer success. No single team owns the entire problem—yet without clear ownership, accountability fragments and response suffers.

Organizations that treat supply chain security as "someone else's job" consistently underperform those with explicit ownership models. Organizations with mature supply chain security programs typically demonstrate faster vulnerability remediation and more comprehensive risk management than those without formal programs. The difference is not primarily technical capability but organizational clarity: knowing who is responsible, who must be consulted, and who makes decisions when trade-offs arise.

This section examines how to structure supply chain security ownership, recognizing that no single model fits all organizations. Your choice depends on company size, culture, existing team structures, and the relative maturity of your security and engineering practices.

Where Does Supply Chain Security Live?¶

The first organizational question is where primary responsibility resides. Several models exist, each with trade-offs:

Security team ownership:

In this model, a centralized security team (often the Application Security or Product Security function) owns supply chain security strategy, tooling, and policy.

Organizations like financial institutions often use this model, where regulatory requirements demand centralized security oversight. The key to success is ensuring security teams have sufficient engineering context and that policies are developed collaboratively.

Engineering/Platform ownership:

Here, engineering teams—often the platform or developer experience organization—own supply chain security as part of their responsibility for the development platform.

Technology companies with strong platform engineering functions often adopt this model. Google's approach, where security is embedded in the developer platform rather than imposed externally, exemplifies this.

Shared ownership with clear interfaces:

Many organizations find that neither pure security nor pure engineering ownership works. Instead, they define clear interfaces:

• Security team: Policy, risk assessment, vulnerability intelligence, compliance
• Engineering/Platform: Tooling, integration, remediation workflows, developer experience
• Product teams: Implementation, prioritization within products, release decisions

This model requires explicit coordination mechanisms but often produces the best outcomes by combining security expertise with engineering context.

Risk/GRC ownership:

Some organizations, particularly in regulated industries, place supply chain security under Governance, Risk, and Compliance (GRC) functions.

This model works when supply chain security is viewed primarily through a vendor/third-party risk lens, but often requires strong technical partnership with security or engineering teams.

Centralized vs. Federated Models¶

Beyond team ownership, organizations must decide how authority and execution are distributed.

Centralized model:

A central team sets policy, operates tooling, makes decisions, and drives remediation. Product teams implement but do not define.

┌─────────────────────────────────────┐
│    Central Supply Chain Security    │
│    (Policy + Tooling + Decisions)   │
└─────────────────┬───────────────────┘
                  │
    ┌─────────────┼─────────────┐
    ▼             ▼             ▼
┌───────┐   ┌───────┐     ┌───────┐
│Team A │   │Team B │     │Team C │
│(Impl) │   │(Impl) │     │(Impl) │
└───────┘   └───────┘     └───────┘

This works well for: - Smaller organizations with limited security resources - Highly regulated environments requiring consistency - Organizations with immature security practices in product teams

Challenges include scalability, bottlenecks, and potential friction with autonomous engineering teams.

Federated model:

A central team sets policy and provides guidance, but product teams make decisions and operate tooling within their domains.

┌─────────────────────────────────────┐
│    Central Policy & Guidance        │
│    (Standards + Enablement)         │
└─────────────────┬───────────────────┘
                  │
    ┌─────────────┼─────────────┐
    ▼             ▼             ▼
┌───────┐   ┌───────┐     ┌───────┐
│Team A │   │Team B │     │Team C │
│(Full) │   │(Full) │     │(Full) │
└───────┘   └───────┘     └───────┘

This works well for: - Large organizations with multiple product lines - Companies with strong engineering cultures - Organizations where speed and team autonomy are paramount

Challenges include inconsistency, varying maturity levels, and difficulty maintaining visibility across teams.

Hybrid model:

Most mature organizations adopt a hybrid: centralized policy and shared infrastructure with federated execution and decision-making within guardrails.

┌─────────────────────────────────────┐
│    Central: Policy + Shared Tools   │
│    + Intelligence + Standards       │
└─────────────────┬───────────────────┘
                  │
    ┌─────────────┼─────────────┐
    ▼             ▼             ▼
┌───────┐   ┌───────┐     ┌───────┐
│Team A │   │Team B │     │Team C │
│(Exec) │   │(Exec) │     │(Exec) │
└───────┘   └───────┘     └───────┘

In this model: - Central team provides scanning infrastructure, vulnerability intelligence, and policy frameworks - Product teams execute within those frameworks, making prioritization decisions - Escalation paths exist for exceptions and high-severity issues - Metrics roll up centrally for visibility

Microsoft's approach to supply chain security exemplifies this hybrid: central teams provide tooling and standards while product groups maintain responsibility for their supply chains within those standards.

The Role of an Open Source Program Office¶

Open Source Program Offices (OSPOs) have emerged as a key organizational structure for managing open source engagement. While OSPOs historically focused on license compliance and contribution policy, many now incorporate supply chain security.

OSPO responsibilities for supply chain security:

The TODO Group, a Linux Foundation project for OSPO collaboration, has documented how leading OSPOs integrate security. Their research shows that OSPOs with security responsibilities provide coordination that accelerates vulnerability response compared to organizations without such coordination.

OSPO placement options:

• Engineering/CTO organization: Emphasizes technical depth, developer relationships
• Legal/Compliance: Emphasizes license compliance, risk management
• Security/CISO organization: Emphasizes security aspects, vulnerability management
• Standalone/CEO-reporting: Emphasizes strategic importance, cross-functional mandate

Organizations without formal OSPOs should still designate ownership for the functions an OSPO would provide. Supply chain security does not require an OSPO, but it requires someone playing that coordinating role. When a major vulnerability emerges, having a clear point of coordination helps developers know where to turn for guidance and support.

Cross-Functional Collaboration Requirements¶

Supply chain security inherently requires collaboration across organizational boundaries. Effective programs map stakeholders and establish working relationships before incidents demand them.

Cross-functional stakeholder map:

Establishing collaboration mechanisms:

1. Working groups: Regular cross-functional meetings focused on supply chain security topics
2. Shared channels: Communication channels (Slack, Teams) where stakeholders can collaborate
3. Defined escalation paths: Clear processes for raising issues that cross team boundaries
4. Joint goals: Shared OKRs or metrics that create aligned incentives

Organizations with strong collaboration mechanisms respond faster to supply chain incidents. When the Log4Shell vulnerability emerged, organizations with established cross-functional relationships mobilized within hours; those without spent the first day figuring out who should be involved.

Defining Roles and Responsibilities: RACI Charts¶

RACI charts clarify roles for specific activities, reducing ambiguity about who does what. RACI stands for:

• Responsible: Does the work
• Accountable: Ultimately answerable for completion (one per activity)
• Consulted: Provides input before decisions
• Informed: Notified of outcomes

Sample RACI chart for supply chain security:

This is illustrative; your RACI will differ based on organizational structure. The key is explicit documentation that everyone references, not a chart that sits in a drawer.

Common RACI pitfalls:

• Multiple "A"s for one activity (dilutes accountability)
• No "A" for an activity (no one is ultimately responsible)
• Too many "C"s (consultation overload, slow decisions)
• RACI created but not referenced (documentation theater)

Review and update RACI charts regularly. Organizational changes, new tools, and evolving practices should trigger updates.

Executive Sponsorship and Visibility¶

Supply chain security programs require executive sponsorship to secure resources, resolve cross-functional conflicts, and maintain organizational priority. Without executive visibility, supply chain security risks being deprioritized when it competes with feature development.

Why executive sponsorship matters:

• Resource allocation: Security tooling, headcount, and training require budget approval
• Priority conflicts: When security and delivery timelines conflict, executives adjudicate
• Cross-functional authority: Executives can mandate collaboration across teams
• Risk acceptance: Material supply chain risks require executive-level decisions
• External accountability: Board, regulators, and customers expect executive ownership

Executive engagement model:

Metrics for executive communication:

Executives need different information than practitioners. Focus on:

• Risk exposure: How many critical/high vulnerabilities? Trending up or down?
• Remediation velocity: How quickly are issues addressed? SLA compliance?
• Coverage: What percentage of applications are monitored?
• Comparison: How do we compare to peers/benchmarks?
• Investment efficiency: What is the return on security investments?

When presenting to the board, executives need business risk context rather than technical details. They want to understand whether the organization is more or less at risk than last quarter, whether the program is improving, and what additional actions are needed.

Mergers, Acquisitions, and Organizational Change¶

Supply chain security programs designed for steady-state operations face significant challenges during mergers, acquisitions, and major organizational changes. When two companies combine, they bring different supply chain security maturity levels, tooling, policies, and cultures. Without deliberate integration planning, the result is often the worst of both organizations—duplicated effort, security gaps, or lowest-common-denominator practices.

M&A supply chain security challenges:

M&A integration planning:

Effective integration begins during due diligence and extends through the first year post-acquisition.

Phase 1: Due Diligence (Pre-Acquisition)

Assess target company's supply chain security posture:

# Supply Chain Security Due Diligence Checklist

### Program Maturity
- [ ] Does target have formal supply chain security program?
- [ ] What maturity level (use framework from Section 21.5)?
- [ ] Who owns supply chain security?
- [ ] What is staffing/budget?

### Technical Capabilities
- [ ] What SCA tools are in use?
- [ ] Are SBOMs generated? What format and coverage?
- [ ] Is build provenance captured?
- [ ] Are releases signed?
- [ ] What dependency management practices exist?

### Risk Assessment
- [ ] Inventory of critical products and their dependencies
- [ ] Known vulnerabilities in target's products
- [ ] Recent supply chain security incidents
- [ ] Technical debt related to dependencies
- [ ] License compliance issues

### Gap Analysis
- [ ] Differences from acquiring company's standards
- [ ] Security capabilities that would be lost post-acquisition
- [ ] Critical gaps requiring immediate attention
- [ ] Integration complexity (tooling, process, culture)

Red flags in due diligence:

• No awareness of supply chain security (indicates broader security immaturity)
• Recent unaddressed supply chain incidents
• Critical products with severe known vulnerabilities
• Dependency on abandoned or high-risk packages
• No ability to produce SBOMs or dependency inventory
• Resistance to security questions

These findings don't necessarily block acquisition but inform valuation, integration planning, and risk acceptance.

Phase 2: Day 1-30 Post-Acquisition

Immediate stabilization and assessment:

Week 1: Stabilize - Extend monitoring to acquired company's products (dependency scanning, vulnerability alerts) - Establish communication channels with acquired team - Identify critical products requiring immediate attention - Apply emergency fixes if critical vulnerabilities discovered

Week 2-4: Assess and Plan - Complete detailed assessment of acquired products and dependencies - Interview acquired security/engineering staff to understand practices - Identify quick wins (enable dependency scanning, fix critical vulns) - Develop integration roadmap

Parallel operations decision: In early days, allow acquired company to continue existing practices while you plan integration. Forcing immediate change creates chaos.

Phase 3: Integration (Months 2-6)

Gradual integration aligned with broader organizational integration:

Integration sequencing principles:

1. Safety first: Extend monitoring and critical security controls immediately
2. Preserve what works: Don't replace acquired company's effective practices just for uniformity
3. Consolidate thoughtfully: Merge tooling and processes where it reduces complexity and improves security
4. Respect culture: Integration approaches for enterprise acquiring startup differ from startup acquiring startup

Integration approach by scenario:

Scenario A: Large acquiring small with strong security

Acquiring company (enterprise): Mature program, comprehensive tooling
Acquired company (startup): Minimal security, technical debt

Integration approach:
├── Month 1-2: Extend acquirer's monitoring to acquired products
├── Month 2-3: Migrate acquired products to acquirer's dependency registry
├── Month 3-4: Apply acquirer's policies with temporary exceptions for tech debt
├── Month 4-6: Systematic remediation of tech debt
└── Month 6+: Full integration into acquirer's program

Scenario B: Similar-size companies merging as equals

Both companies: Mature programs, different but effective approaches

Integration approach:
├── Month 1-2: Assessment of both programs' strengths
├── Month 2-4: Design unified program taking best of both
├── Month 4-6: Pilot unified program with select teams
├── Month 6-12: Gradual migration to unified program
└── Month 12+: Continuous improvement of merged program

Scenario C: Startup acquiring larger company's division

Acquirer (startup): Lean, modern tooling, high automation
Acquired (enterprise division): Process-heavy, older tools

Integration approach:
├── Month 1-3: Run parallel—don't disrupt acquired division's existing controls
├── Month 3-6: Assess what enterprise processes are compliance requirements vs. legacy
├── Month 6-9: Selective adoption of startup's automation where it improves efficiency
└── Month 9-12: Hybrid program balancing startup agility with enterprise compliance

Tooling consolidation decisions:

Cultural integration considerations:

Supply chain security culture often reflects broader organizational culture:

Startup culture indicators: - Move fast, fix later approach - Minimal process, heavy automation - Direct dependency on public registries - Developers make security decisions - Pragmatic risk acceptance

Enterprise culture indicators: - Deliberate process, change controls - Multiple approval layers - Curated internal registries - Security team gatekeeps decisions - Risk-averse, compliance-focused

Cultural integration strategies:

• Fast to slow: Startup acquiring/merging with enterprise
• Respect compliance requirements (they're often non-negotiable)
• Introduce automation gradually to improve efficiency without losing control
• Frame agility improvements as reducing risk, not accepting more risk

• Demonstrate that speed and security can coexist

• Slow to fast: Enterprise acquiring startup

• Don't immediately impose enterprise process overhead
• Distinguish genuine requirements from legacy process
• Let startup's good automation practices influence enterprise
• Provide fast-track paths for low-risk changes

Phase 4: Stabilization (Months 6-12)

Unified program operating with clear ownership:

• All products monitored under unified program
• Tooling consolidation decisions implemented
• Policies harmonized with documented exceptions
• Staff integrated with clear roles
• Metrics tracked across full portfolio
• Knowledge transfer complete

Success metrics for M&A integration:

Common M&A integration mistakes:

Carve-out and divestiture considerations:

When divesting a business unit or product, supply chain security has reverse challenges:

Divestiture planning: - Identify which dependencies are shared vs. divested-business-only - Determine if divested business can maintain dependency registries - Transfer SBOMs and security documentation - Establish transition support period for security questions - Ensure divested business has security staff or access to expertise

Example integration timeline (enterprise acquiring startup):

Month 1:  Emergency response
          ├── Extend dependency scanning
          ├── Fix critical vulnerabilities
          └── Establish communication

Month 2-3: Assessment and planning
          ├── Full dependency inventory
          ├── Integration roadmap
          └── Quick wins implemented

Month 4-6: Active integration
          ├── Migrate to common registry
          ├── Implement unified policies
          └── Tool consolidation decisions

Month 7-9: Refinement
          ├── Address tech debt systematically
          ├── Staff fully integrated
          └── Processes harmonized

Month 10-12: Stabilization
           ├── Unified metrics and reporting
           ├── All products meeting standards
           └── Integration complete

Recommendations for M&A integration:

1. Include supply chain security in due diligence: Discover issues before acquisition, not after
2. Extend monitoring immediately: You can't secure what you can't see
3. Assess before consolidating: Understand what each org does well before forcing uniformity
4. Sequence integration thoughtfully: Critical security controls first, process harmonization later
5. Preserve what works: Don't replace effective practices just for consistency
6. Support acquired staff: Integration is stressful; support teams through the transition
7. Track integration progress: Measure coverage, remediation, and policy compliance through integration
8. Plan for 12 months: Full integration takes time; plan for gradual progress

M&A creates both risk and opportunity for supply chain security. Acquisitions can bring new products with unknown dependencies and technical debt, but also new talent, tools, and practices. Thoughtful integration planning turns M&A challenges into opportunities for program improvement.

Recommendations¶

We recommend the following approaches to organizational design for supply chain security:

1. Establish clear ownership: Assign primary accountability for supply chain security to a specific team or role. Ambiguous ownership leads to gaps and finger-pointing.

2. Choose a model that fits your culture: Centralized models work in compliance-driven environments; federated models work in engineering-driven cultures. Hybrids often provide the best balance.

3. Designate OSPO functions or create a formal OSPO: Whether formal or informal, someone should coordinate open source policy, provide guidance, and serve as the central point of contact.

4. Map stakeholders explicitly: Document who is involved in supply chain security and what their interests are. Establish collaboration mechanisms before you need them.

5. Document RACI: Create and maintain a RACI chart for key supply chain security activities. Review it when organization or process changes occur.

6. Secure executive sponsorship: Identify an executive sponsor who will champion the program, allocate resources, and resolve cross-functional conflicts.

7. Communicate in executive terms: Translate technical metrics into business risk language. Focus on trends, comparisons, and action items rather than raw data.

Organizational models are not permanent. As your supply chain security program matures, revisit your structure. What worked for initial implementation may not work at scale; what works for one product may not work across a diverse portfolio. Treat organizational design as an ongoing practice, not a one-time decision.