Organization Types, Roles & Responsibilities

Every organization that depends on software is an SBOM consumer. The operational steps for receiving and using SBOMs vary by structure, staffing, and regulatory context — but the relevance of SBOM data does not. The five types below reflect the range of organizations in the consumer ecosystem and describe how SBOM engagement applies to each.

Organization Types

Solo Operator — freelancers, independent consultants, sole practitioners

Solo operators — freelancers, independent consultants, and sole practitioners across every professional field — are software consumers. Every SaaS platform, cloud-hosted tool, and third-party application in their stack is software built from components. An SBOM provided by a vendor is a direct statement of what is in that software: which libraries, which versions, which dependencies.

SBOM relevance for this type

Solo operators have a direct stake in whether their vendors maintain SBOMs. When a vulnerability is disclosed in a widely used component, a vendor with a current, accurate SBOM can identify the exposure, assess impact, and communicate with precision. A vendor without one cannot. SBOM availability is therefore a meaningful criterion in vendor selection and renewal — accessible at any scale of operation.

Solo operators can and should ask vendors whether SBOMs are available for the software they purchase or subscribe to. Doing so creates market demand that advances SBOM adoption across the software ecosystem and provides a basis for evaluating vendor transparency before a security event makes that evaluation urgent.

If regulated: Solo practitioners handling protected health information operate as HIPAA covered entities.^[7] Those handling legal, financial, or other sensitive client data may face obligations under state or sector-specific rules. In each case, the ability to demonstrate that software vendors maintain transparent, documented component practices — including SBOM availability — is a meaningful component of a defensible risk posture.

Small Business — 2–20 employees, no dedicated IT function

Small businesses operate a mix of commercial packaged software and SaaS platforms — point-of-sale systems, practice management applications, HR tools, connected devices — often with IT managed by a third-party MSP. The absence of a dedicated security function does not reduce the relevance of SBOM data to this type; it shapes how SBOM engagement is structured.

SBOM relevance for this type

Small businesses are software consumers at meaningful scale. The vendors supplying their operational software carry component-level transparency obligations regardless of whether any individual customer asks about them. Requesting SBOMs or asking about SBOM availability at procurement is a legitimate and increasingly standard practice — one that creates a documented basis for comparing vendor software security practices and signals expectations to the market.

For small businesses with an MSP, SBOM-aware requirements can be incorporated into the managed services agreement directly, making the MSP the operational layer for SBOM intake without requiring dedicated internal technical staff. See Using an MSP or MSSP? below.

Cyber insurance and regulatory context: Cyber insurance questionnaires increasingly assess software inventory practices and vendor risk management. An organization that can reference SBOM availability from its critical software vendors is better positioned to answer those questions accurately. See the Compliance and Insurance Crosswalk below.

SaaS-Only Mid-Market — 50–500 staff, cloud-only, small or fractional IT team

A management consulting firm, staffing company, marketing agency, or regional healthcare system that runs no internal servers and purchases all software as SaaS. IT is either a small internal team or an MSP. There may be a security officer, often part-time or fractional.

SBOM relevance for this type

This type is where SBOM concepts become operationally visible even without direct SBOM file processing. Several scenarios drive engagement.

Incident response. When a high-profile vulnerability surfaces in a widely used component — Log4Shell and XZ Utils are established examples — an organization at this tier needs to determine whether any of its SaaS vendors are affected. Vendors with mature SBOM programs respond faster and with greater specificity; vendors without them issue slower, less precise communications. The quality of incident communication an organization receives is a direct indicator of vendor SBOM maturity.

FedRAMP customers. Organizations that purchase cloud services from FedRAMP-authorized vendors may, under OMB M-26-05,^[2] request SBOM data for the runtime production environment. This right can be exercised when a specific security question requires it.

Vendor due diligence. Organizations in this tier frequently run vendor security questionnaires through platforms such as OneTrust, Whistic, or SecurityScorecard when onboarding critical SaaS vendors. Including SBOM availability and format support in those questionnaires is a direct way to advance SBOM adoption and assess vendor supply chain maturity.

Regulated Entity — healthcare, financial services, utilities, defense

Medical practices, community banks, credit unions, broker-dealers, and regional utilities operate under regulatory regimes — HIPAA, Gramm-Leach-Bliley, SEC cybersecurity rules, NERC CIP, state-level privacy laws — that impose specific software security obligations. They typically have a compliance officer but may not have a dedicated security role.

SBOM relevance for this type

Regulation is the most direct entry point. A medical practice covered by HIPAA is required to maintain a risk analysis that accounts for the security of systems handling protected health information.^[7] A bank subject to the FTC Safeguards Rule must maintain an information security program with controls over service provider arrangements.^[3] Neither regulation specifies SBOM by name, but both require documented understanding of vendor software security. Received SBOMs are a primary artifact supporting that documentation.

Medical device manufacturers selling into the U.S. market face a direct SBOM mandate under FDA Section 524B, applicable to any “cyber device” submitted for premarket approval after March 29, 2023.^[4] Small device manufacturers are not exempt. They must supply SBOMs for their own devices and engage with the SBOM practices of the component suppliers in their supply chain.

Development Organization — internal engineering, DevSecOps, dedicated security staff

Software companies, technology-forward enterprises, financial institutions with in-house engineering teams, and startups both produce and receive SBOMs. This type has — or can build — dedicated roles for security, engineering, and compliance.

SBOM relevance for this type

This type engages with the full receiving workflow: direct SBOM ingestion, format validation, vulnerability correlation, VEX/CSAF intake, ITAM record linkage, and SBOM-informed audit documentation. The What To Do page covers the operational detail for this type, including the technical receiving workflow, roles and responsibilities, and the phased program model.

This section covers only the receiving end. Production and distribution responsibilities are addressed in their respective sections of this guide.

The majority of small and mid-market organizations outsource IT management to a managed service provider (MSP) or managed security service provider (MSSP). In these arrangements, SBOM intake — requesting SBOMs from vendors, receiving and validating them, correlating them against vulnerability data — operationally sits with the MSP, not the customer.

This creates a gap that is largely unaddressed in current SBOM guidance: who owns SBOM practice in a managed-services arrangement?

An SBOM received from a vendor and stored without being processed against vulnerability feeds or VEX statements has no operational value. If the MSP is performing vulnerability management, received SBOMs must land in the MSP’s tooling. If the MSP is not conducting SBOM-aware vulnerability management, the artifacts are inert.

SBOM-specific questions to ask your MSP or MSSP:

Do you request and ingest SBOMs from software vendors operating in my environment?
When a vulnerability is disclosed in a widely used component, how do you determine which software in my environment is affected, and what is your response timeframe?
Do you use software composition analysis tooling to correlate vendor software against current vulnerability feeds?
Do you receive and process VEX statements from vendors to filter and prioritize vulnerability findings?
Are received SBOMs and related VEX statements retained and available to me on request?

CISA’s guidance on SBOM management for operational use^[5] is the reference framework for MSPs developing SBOM-aware capability. In regulated sectors, the expectation that an MSP tracks vendor software at the component level — not only at the patch level — is increasingly a requirement rather than a differentiator.

Compliance and Insurance Crosswalk

The table below maps common regulatory and insurance frameworks to their requirements relevant to SBOM practice and describes how SBOM receiving supports compliance. Organizations subject to these frameworks should treat SBOM program development as a direct compliance activity, not merely a security enhancement.

Framework	Who it covers	What it requires relevant to SBOM	How SBOM receiving supports compliance
FTC Safeguards Rule (GLBA)^[3]	Financial institutions including auto dealers, tax preparers, mortgage brokers	Written information security program; service provider oversight requiring contracts with appropriate safeguards	Received SBOMs document the component composition of vendor software; SBOM-informed contracts establish enforceable transparency requirements
HIPAA Security Rule^[7]	Covered entities and business associates handling PHI	Risk analysis; technical safeguards; business associate agreements	Received SBOMs support risk analysis for software handling PHI; BAAs can specify SBOM delivery as a vendor obligation
FDA Section 524B^[4]	Manufacturers of “cyber devices” submitted for premarket clearance/approval	SBOM in premarket submission; post-market vulnerability monitoring	Direct SBOM mandate; component supplier SBOMs are required inputs to a compliant premarket submission
PCI DSS v4.0^[8]	Any entity storing, processing, or transmitting cardholder data	Req. 6.3: security of externally developed software; Req. 12.8: third-party service provider management	Received SBOMs provide the component-level visibility required for externally developed software security assessment
NIST CSF 2.0^[6]	Voluntary, but referenced by many regulations and insurers	“Identify” function: asset management, risk assessment; “Respond”: incident response	Received SBOMs operationalize software asset management within the Identify function and accelerate incident response
CIS Controls v8 IG1^[9]	Baseline controls appropriate for small organizations	Control 2: Inventory and control of software assets; Control 16: Application security practices	Received SBOMs provide component-level detail supporting software asset inventory requirements
SEC Cybersecurity Rules^[10]	Public companies	Annual disclosure of cybersecurity risk management; material incident disclosure	Received SBOMs support documented vendor software risk management and improve the accuracy and speed of material incident scoping
EU Cyber Resilience Act	Manufacturers placing products with digital elements on the EU market	SBOM obligation for products in scope; vulnerability reporting; 10-year retention	Component supplier SBOMs are required inputs to a compliant product SBOM; receiving capability is a prerequisite
Cyber insurance	Any insured organization	Questionnaires increasingly cover software inventory practices, vendor risk management, and incident response	SBOM records from vendors document software component transparency; SBOM-aware vendor contracts and VEX monitoring directly address common questionnaire categories