Manufacturer Disclosure Review

Manufacturer Disclosure Review means you must collect and review each medical device manufacturer’s MDS2 and SBOM to confirm the device’s cybersecurity capabilities, known software components, and supportability risks before purchase and throughout the device lifecycle ¹. Operationalize it by building an intake checklist, defined acceptance criteria, and repeatable review/refresh triggers.

Key takeaways:

• Treat MDS2 + SBOM review as a procurement gate and an ongoing lifecycle control, not a one-time file collection ¹.
• Translate manufacturer disclosures into clear security requirements for configuration, network placement, patching, and compensating controls.
• Keep evidence that you reviewed, decided, and tracked follow-up actions tied to each device model and software component.

Manufacturer disclosure review is one of the fastest ways to reduce unknown risk in medical devices because it forces the organization to work from facts supplied by the manufacturer: how the device is secured, what software runs inside it, and what the manufacturer will support over time. HICP Practice 9.5 is direct: review manufacturer disclosure statements (MDS2) and software bill of materials (SBOM) for medical device cybersecurity capabilities ¹.

For a Compliance Officer, CCO, or GRC lead, the operational challenge is not “getting the document.” The challenge is building a repeatable review motion that reliably answers: Can this device be deployed safely in our environment, under our security standards, with realistic operational ownership? That requires defined intake steps, a consistent rubric for evaluating MDS2 and SBOM content, documented risk acceptance when gaps exist, and lifecycle triggers so the review stays current after patches, recalls, or changes in manufacturer support.

This page gives requirement-level implementation guidance you can drop into procurement, third-party risk management, and clinical engineering workflows without turning it into a multi-quarter project.

Regulatory text

Requirement (excerpt): “Review manufacturer disclosure statements (MDS2) and software bill of materials (SBOM) for medical device cybersecurity capabilities.” ¹

What the operator must do:
You need an operational process that (1) requests MDS2 and SBOM from the manufacturer (or the third party selling/servicing the device), (2) reviews both artifacts against defined cybersecurity expectations, and (3) uses the results to make deployment decisions and set ongoing security actions ¹. “Review” must be more than storing PDFs; it should result in a documented decision and assigned follow-ups.

Plain-English interpretation

• MDS2 tells you what the device can and cannot do securely. You’re looking for authentication options, logging, encryption, patchability, secure configuration capabilities, remote access controls, and constraints that will affect safe deployment.
• SBOM tells you what’s inside. You’re looking for software components, versions, and libraries so vulnerability management can identify exposures and prioritize response.
• Your job is to turn disclosures into controls. If the device can’t support your baseline requirements, you either reject it, require compensating controls, or document a formal risk acceptance tied to a clinical need.

Who it applies to (entity and operational context)

Applies to:

• Healthcare organizations acquiring, deploying, or operating medical devices connected to internal networks or handling sensitive data ¹.
• Health IT vendors involved in selecting, integrating, hosting, monitoring, or managing medical devices or connected device ecosystems ¹.

Operational contexts where this control matters most:

• New device procurement (including “like-for-like replacement” where cybersecurity has changed).
• Devices with remote service capability, cloud connectivity, or third-party monitoring.
• Network segmentation decisions (clinical VLANs, DMZ placement, restricted zones).
• Incident response and vulnerability management for device software components.
• Mergers, facility expansions, or device fleet standardization where legacy devices get re-evaluated.

What you actually need to do (step-by-step)

1) Define your intake requirement (procurement gate)

Create a simple standard: No connected medical device proceeds to purchase order until MDS2 and SBOM are received (or a documented exception is approved). Tie it to purchasing workflow checkpoints so it does not depend on individual heroics.

Implementation details:

• Update your sourcing checklist and contract intake to require MDS2 and SBOM as deliverables ¹.
• Specify acceptable formats (for example, PDF MDS2, machine-readable SBOM if available) as your internal standard. Keep format guidance flexible, but keep the requirement firm.

2) Assign ownership and build a RACI that matches reality

This control fails when everyone thinks someone else reviewed the documents.

A workable ownership model:

• Clinical Engineering / HTM: device inventory, model/version tracking, service relationships.
• Information Security: security review, network controls, vulnerability intake from SBOM.
• GRC/Compliance: process governance, evidence retention, exception/risk acceptance workflow.
• Supply Chain/Procurement: ensures documents are obtained and contractualized.
• Clinical Sponsor: confirms clinical necessity when security gaps require exceptions.

3) Review the MDS2 with a fixed rubric

Use a rubric so review outcomes are consistent across reviewers and sites.

Minimum rubric categories (turn into a one-page checklist):

• Identity & access: local accounts, role-based access, MFA support (if applicable), password policy support, default credential handling.
• Data protection: encryption at rest/in transit capabilities, key management constraints, PHI handling implications.
• Auditability: logs available, log export options, time sync support.
• Patch & vulnerability handling: update mechanism, maintenance windows, rollback capability, manufacturer vulnerability communication expectations.
• Connectivity & remote service: remote access methods, need for inbound ports, ability to restrict to approved endpoints, monitoring options.
• Hardening options: ability to disable unused services, remove unnecessary accounts, restrict USB/media, restrict admin interfaces.
• Safety and availability constraints: operational limitations that affect security controls (for example, patching constraints during patient care).

Output required: a recorded decision: approve, approve with conditions, or reject, with reasons and assigned actions.

4) Review the SBOM for operational security impact

The SBOM review should connect directly to vulnerability management and lifecycle support decisions.

What to do in practice:

• Normalize components into your tracking system. Extract key components and versions. If you cannot automate, capture the highest-risk components and major packages first.
• Map SBOM to vulnerability intake. Ensure your vulnerability process can match SBOM components to alerts and remediation tasks.
• Confirm supportability. If the SBOM shows components that are hard to patch in embedded systems, plan compensating controls (segmentation, monitoring, restricted access) and document ownership.

Output required: SBOM review notes and an action list (monitor specific components, request patch roadmap, impose segmentation, etc.).

5) Translate findings into deployment requirements

Your review should produce requirements that engineering teams can implement, such as:

• Network zone placement and firewall rules.
• Remote access method (approved tool, vendor access controls, session logging expectations).
• Identity approach (local accounts vs directory integration where feasible).
• Logging/monitoring requirements (forward to SIEM, retain locally, alerting expectations).
• Patch cadence expectations aligned to manufacturer guidance and clinical constraints.

6) Establish lifecycle triggers (so “review” stays current)

HICP’s summary expectation includes review “before procurement and during operation” ¹. Define triggers so you re-check disclosures when risk changes.

Common triggers to formalize:

• Major device software/firmware update.
• Manufacturer change in support status or end-of-support notice.
• New vulnerability affecting a component listed in the SBOM.
• Change in connectivity model (new remote service channel, cloud integration, new interface).
• Incident involving the device class.

7) Run exceptions like a real risk acceptance process

Some devices will not meet your preferred baseline. That’s normal. What auditors look for is whether exceptions are controlled.

Exception package should include:

• Clinical justification and alternatives considered.
• Specific gap (for example, cannot encrypt at rest, cannot export logs).
• Compensating controls you will implement.
• Named risk owner and review trigger (for example, at renewal, when a patch is released, or when support status changes).

8) Make it auditable: evidence, traceability, and change control

Build traceability from: Device model + version → MDS2/SBOM received → review performed → decision recorded → controls implemented → exceptions tracked → periodic/triggered re-review.

If you use a platform like Daydream, the practical win is centralizing MDS2/SBOM collection, mapping review outcomes to third-party and asset records, and generating an audit-ready evidence trail without stitching together email threads and shared drives.

Required evidence and artifacts to retain

Keep these artifacts per device model (and update when versions change):

• MDS2 file (as received) with date and source.
• SBOM file (as received) with date and source.
• Review checklist/rubric output (completed, dated, reviewer name).
• Decision record (approve/conditional/reject) and rationale.
• Compensating controls documentation (network diagram snippet, firewall rule request, monitoring ticket references).
• Risk acceptance/exception approvals with risk owner sign-off.
• Lifecycle re-review records triggered by updates/vulnerabilities/support changes.
• Contract language or procurement record showing MDS2/SBOM requirements were requested/required (where applicable).

Common exam/audit questions and hangups

Expect auditors (internal or external) to ask:

• “Show me that you reviewed MDS2 and SBOM before purchase for a sample of devices.” ¹
• “Who performed the review, and what criteria did they use?”
• “How do you ensure SBOM contents are acted on in vulnerability management?”
• “How do you handle devices where the manufacturer will not provide an SBOM or provides an incomplete one?”
• “How do you re-review during operation after changes?” ¹

Hangups that stall reviews:

• Documents exist but are not tied to the exact model/version deployed.
• MDS2 reviewed by security, SBOM ignored by vulnerability management.
• Remote service access approved informally without documented conditions.

Frequent implementation mistakes and how to avoid them

1. Mistake: Treating the control as “collect documents and file them.”
   Fix: Require a decision record and action list for every review, even if the action is “no gaps found.”

2. Mistake: Reviewing only at purchase, then never again.
   Fix: Add lifecycle triggers tied to updates, support changes, and vulnerability events ¹.

3. Mistake: No clear owner for follow-up actions.
   Fix: Put owners on the action list (network team, HTM, security operations) and track closure like any other risk item.

4. Mistake: Accepting “marketing security sheets” in place of MDS2/SBOM.
   Fix: Procurement language should ask specifically for MDS2 and SBOM, with an exception process if the manufacturer cannot provide them ¹.

5. Mistake: SBOM received but not operationalized.
   Fix: Convert SBOM components into entries your vulnerability process can monitor. If tooling cannot ingest the SBOM, record high-risk components manually and create watch items.

Enforcement context and risk implications

No public enforcement cases were provided in the available sources for this specific HICP practice. Treat the risk as operational: without MDS2/SBOM review, you can deploy devices that cannot be secured to your standards, cannot be monitored, or cannot be patched safely. That increases the chance of unmanaged vulnerabilities, unsupported embedded components, and remote access pathways you did not design for.

Practical execution plan (30/60/90 days)

First 30 days (Immediate stabilization)

• Add MDS2/SBOM request language to procurement intake for connected medical devices ¹.
• Publish a one-page review checklist (rubric) and decision outcomes.
• Stand up an evidence repository tied to device models and versions (even if it is a structured folder + register).
• Pilot the process on a small set of in-flight purchases and one high-risk existing device.

Next 60 days (Operational adoption)

• Formalize RACI across HTM, security, procurement, and GRC; document who signs off.
• Integrate review outputs into network/security workflows (standard firewall patterns, remote access conditions, monitoring tickets).
• Define exception workflow with risk owner approvals and compensating controls.
• Start building SBOM-to-vulnerability workflow, either via tooling ingestion or a manual “top components to monitor” register.

By 90 days (Lifecycle maturity)

• Expand coverage to the full device intake pipeline, including replacements and upgrades.
• Add lifecycle triggers to your change management and vulnerability management playbooks ¹.
• Run a tabletop audit: sample devices, pull evidence, confirm traceability from receipt to decision to implemented controls.
• If scale is a problem, evaluate workflow tooling (including Daydream) to centralize third-party artifacts, reviews, and audit-ready reporting.

Frequently Asked Questions

Do we need both MDS2 and SBOM for every medical device?

HICP Practice 9.5 calls for reviewing both MDS2 and SBOM for medical device cybersecurity capabilities ¹. If a manufacturer cannot provide one, document the gap, pursue alternatives, and run a formal exception with compensating controls.

What if the manufacturer says the SBOM is confidential?

Ask for the most detailed SBOM they can provide under NDA and record the restrictions. If you still cannot get it, document the request/denial and increase reliance on segmentation, monitoring, and contractual vulnerability notification expectations ¹.

Who should sign off on the review decision?

Security should sign off on cybersecurity acceptability, HTM should confirm operational/service feasibility, and the clinical owner should approve any risk acceptance tied to patient care needs. GRC should ensure the process and evidence are complete and retained.

How do we handle devices already deployed without MDS2/SBOM on file?

Triage by connectivity and criticality, then backfill by requesting current MDS2/SBOM from the manufacturer and documenting your review results ¹. Where disclosures cannot be obtained, document an exception and tighten compensating controls.

What does an auditor want to see for “review,” not just collection?

A completed rubric/checklist, a dated decision record, and proof that required conditions were implemented (tickets, network rules, monitoring configuration). They will also test whether you re-review after changes during operation ¹.

How detailed does the SBOM review need to be?

Detailed enough that your vulnerability management can identify and act on exposed components listed in the SBOM. Start with the components most likely to drive patching or compensating controls, then improve depth as tooling and process mature.

Footnotes

1. HICP 2023 - 405(d) Health Industry Cybersecurity Practices