An SBOM creates value only when it is delivered along the supply chain, but it is also sensitive material that contains trade secrets and attack surface. Without governance that determines who shares what, and how, excessive disclosure heightens risk, and excessive restriction forfeits value.

Access Control and Disclosure Scope

Access to SBOM data is managed through Role-Based Access Control (RBAC). Because access needs differ by stakeholder, general users are granted read-only access, administrators are granted edit and update access, and sensitive information is granted restricted access.

For disclosure scope, maintaining two versions is common practice.

• Public SBOM: Contains non-sensitive information that can be shared with all stakeholders.
• Private SBOM: Contains sensitive information, such as vulnerabilities, and only approved parties can access it.

Regulation reflects this distinction as well. The EU Cyber Resilience Act does not require an SBOM to be disclosed to the general public, but requires it to be retained in case market surveillance authorities request it. Amid the tension between consumers wanting a more complete SBOM and producers wanting to reduce disclosure, the public/private split is a practical device that reconciles the two.

Secure Sharing Channels

When delivering an SBOM, both integrity and confidentiality need to be preserved.

• Use a secure protocol such as HTTPS for transmission, and ensure integrity and confidentiality through digital signatures or encryption.
• Use a sharing platform equipped with access control and audit capabilities.
• Use API integration for automated exchange between systems, and dedicated repositories for industry- or community-level sharing.

Attach a digital signature to the document so recipients can verify its authenticity and check for tampering, and clearly mark which information is public and which is private.

Roles and Responsibilities

An SBOM program works only when multiple departments share responsibility for it. It should include an executive sponsor, project leads, systems and design engineers, procurement specialists, and operations personnel, adding IT, cybersecurity, and maintenance staff as security needs require. When roles are scattered, responsibility scatters with them, so establishing clear ownership is the starting point.

The key activities in building governance are as follows.

• Identify key stakeholders: Include representatives from development, IT operations, security, procurement, legal, and business leadership, and be sure to include a cybersecurity expert.
• Define responsibilities and assign ownership: Decide who will handle SBOM generation and consumption, vulnerability monitoring, supplier engagement, and security data management, and designate a cybersecurity expert as the program owner or co-owner.
• Establish a governance structure: A governance body with participation from stakeholders across the organization develops policies, standards, and processes, and implements data protection controls.
• Train and monitor: Train personnel on SBOM security requirements and secure data handling, and continuously assess the program’s security posture through regular audits, adjusting it to evolving threats and compliance requirements.

Sources

CISA (2024).Framing Software Component Transparency, Third Edition. CERT-In.Technical Guidelines on Software Bill of Materials (SBOM). Regulation (EU) 2024/2847 — Cyber Resilience Act, Annex I Part II. (all accessed: June 14, 2026)

This is stage 4 of the implementation roadmap. It brings the preceding clauses together to establish a governance framework across the full AI system lifecycle, and reviews it regularly to reflect emerging AI regulations (3.10).

1. Clause Overview

Governance is the framework that ties all the preceding clauses together to ensure the AI system’s lifecycle is developed, deployed, and managed responsibly from end to end. Where policy (3.1) sets the principles and license obligations (3.5) and the AI SBOM (3.9) build individual processes, governance manages these so they keep operating consistently through regulatory change and model replacement.

3.10 requires an AI governance framework, policies, and practices. The specification emphasizes compliance with emerging AI laws such as the EU AI Act, the Hiroshima AI Process, and China’s Global AI Governance Initiative, and addresses ethical considerations, risk management, and transparency together. The core is to review a framework, once built, periodically so it reflects the latest regulation and model changes.

2. Activities to Perform

• Write a governance framework document that spans the full AI system lifecycle.
• Include emerging AI regulation tracking, risk management, transparency, and ethical considerations in the framework.
• Have a procedure for periodically reviewing and updating the framework.
• Monitor the risks that come with the ongoing use of AI systems and training data.
• Reflect events such as model tree changes, regulatory enforcement, and OSAID classification changes in governance.([Guide Recommendation])

3. Requirement and Verification Material

4. How to Comply with Each Verification Material, with Samples

3.10.1 AI Governance Framework and Periodic Review Procedure

How to Comply

The governance framework covers three things: tracking emerging regulation to derive obligations, monitoring the AI system lifecycle, and a procedure for periodically reviewing the framework itself. Because regulation changes quickly, the framework must be a living system built for updates, not a fixed document.

The three axes the specification names differ in character. The EU AI Act imposes concrete, article-level obligations; the Hiroshima AI Process runs voluntary transparency reporting; and China’s initiative is closer to a policy declaration. Governance distinguishes these differences and tracks each accordingly.

The table below lists the major regulations to track from an AI SBOM perspective. The full regulatory matrix and its ISO/IEC 42001 context are covered inISO/IEC 42001 Guide — Organizational Context and Leadership.

Table 1. Major AI regulations intersecting with AI SBOM (as of 2026-06)

Lifecycle monitoring means placing governance checkpoints along the flow from development to retirement. The figure below shows lifecycle governance built around the AI SBOM.

Figure 1. Lifecycle governance built around the AI SBOM

Considerations

• Assign regulatory-tracking responsibility: Specify in governance who tracks emerging regulation and derives obligations from it. The EU AI Act’s obligations expand in stages in August 2026 and 2027, so manage the timing.
• Manage model tree changes: When an imported model moves to a new version or a parent model is replaced, license obligations can change. Register the change as a governance review event.([Guide Recommendation])
• Update OSAID classification: The distinction between “open source AI” and “open weight” (OSAID 1.0) affects model licensing judgments. Include classification changes in the periodic review.
• State the review cycle: Review model and dataset changes quarterly, and regulation and the overall framework annually. Record the review completion date and reviewer.
• Connect to other clauses: Governance ties together the regulatory review under the transparency obligation (3.6) and the lifecycle management under the AI SBOM (3.9) from above. Connect them rather than building duplicate procedures.

Sample (Governance Framework and Annual Review Plan)

Below is a sample of the core part of a governance framework document and periodic review plan. This document becomes verification material 3.10.1.

## AI Governance Framework
### 1. Scope and Purpose
Manages licensing, transparency, risk, and regulatory compliance across the full
lifecycle of an AI system — intake, development, deployment, operation, and
retirement.
### 2. Governance Structure
- AI Governance Lead: approves the framework, makes the final call on regulatory obligations
- Regulatory Tracking Owner: monitors emerging AI regulation, derives obligations
- AI SBOM Verification Owner: runs the generation, review, and approval procedure
- Legal: interprets non-standard licenses and regulation
### 3. Periodic Review Plan
| Frequency | Review Item | Owner | Deliverable |
|------|----------|------|--------|
| Quarterly | Model/dataset changes, model tree licensing | AI SBOM Verification Owner | Change review record |
| Semiannual | Non-standard license classification, OSAID updates | Legal | Updated classification |
| Annual | Regulatory enforcement schedule, overall framework, policy alignment | AI Governance Lead | Revised framework |
### 4. Change Management
When a model tree change, new regulation taking effect, or a license policy change
occurs, convene an ad hoc review rather than waiting for the periodic review. Record
the review outcome and action taken in the change history.

5. References

• Policy foundation:3.1 Policy
• Transparency obligations and regulatory review:3.6 Transparency Obligations
• AI SBOM lifecycle management:3.9 AI SBOM
• Full regulatory matrix and ISO/IEC 42001 context:ISO/IEC 42001 Guide — Organizational Context and Leadership