HIPAA Meets HITRUST: Supply Chain Depth

The Framework Gap Healthcare Inherited

The HIPAA Security Rule was finalized in 2003 and its core standards haven't changed since. In 2003, "software supply chain" wasn't a phrase anyone used. The rule at 45 CFR § 164.308(a)(1)(ii)(A) requires a risk analysis of "potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information" — a framing broad enough to cover supply chain, but not prescriptive enough to drive practice.

That gap is what HITRUST CSF exists to fill. Originally designed as a harmonized framework for healthcare, HITRUST CSF v11 (and the CSF 11.3 update released in 2024) maps HIPAA requirements onto specific, auditable controls, then adds dozens more that HIPAA never contemplated. For software supply chain specifically, HITRUST is now doing the heavy lifting.

This post walks through where HIPAA and HITRUST overlap on supply chain, where HITRUST goes beyond HIPAA, and how a covered entity or business associate can build a single supply-chain program that satisfies both.

HIPAA's Supply Chain Language

HIPAA's supply chain requirements are indirect. The relevant places are:

• § 164.308(a)(1) Security Management Process — requires risk analysis and risk management. In the 2024 NPRM, HHS proposed strengthening this language to require explicit evaluation of technology assets, which would include software components.
• § 164.308(b) Business Associate Contracts — requires that BAs protect ePHI and that contracts include security provisions. This is where supply chain accountability lives under HIPAA, but the rule doesn't specify what evidence a BA must produce.
• § 164.312(b) Audit controls — requires recording and examining activity in information systems containing ePHI. Without a component inventory, audit controls are incomplete: you cannot examine activity in components you don't know you have.
• § 164.310(d)(1) Device and Media Controls — historically read for hardware. OCR's 2023 guidance extended the interpretation to cover the software in medical devices.

What HIPAA does not require is a software bill of materials, a supplier risk assessment of specified depth, or a defined vulnerability SLA. That's where HITRUST comes in.

HITRUST CSF v11 Supply Chain Controls

HITRUST organizes controls into Control References within Control Categories. Supply chain appears in multiple categories:

• 05.02 External Parties — identification of risks related to external parties (CR 05.a), addressing security when dealing with customers (05.b), and addressing security in third-party agreements (05.c).
• 09.10 Monitoring — monitoring system use (09.aa), protection of log information (09.ac), and audit logging of third-party access.
• 10.04 Security in Development and Support Processes — acquisition of software and services (10.m), supplier service delivery management (10.n), and outsourced software development (10.o).

HITRUST CSF v11 specifically added enhanced language on software composition and vulnerability management. Control CR 10.m ("Outsourced Software Development") at implementation level 1 requires the organization to address third-party software acquisition security. At level 3, it requires component-level inventory and active monitoring of supplier security posture — which is functionally an SBOM program.

The Practical Overlap

Here is how I map the frameworks for a health-tech business associate.

HIPAA § 164.308(a)(1)(ii)(A) (risk analysis) ↔ HITRUST CR 03.c (risk analysis) and CR 05.a (identification of risks). The HITRUST risk analysis requires component-level scope identification; the HIPAA risk analysis inherits that scope.

HIPAA § 164.308(b) (BA contracts) ↔ HITRUST CR 05.c (addressing security in third-party agreements). HITRUST prescribes specific contract clauses — incident notification timelines, right to audit, security certifications — that HIPAA BA agreements can adopt wholesale.

HIPAA § 164.312(b) (audit controls) ↔ HITRUST CR 09.aa (monitoring system use). Both require visibility into what's running. HITRUST's implementation guidance covers container and microservice monitoring in a way HIPAA's 2003 language never could.

HIPAA § 164.308(a)(5)(ii)(B) (protection from malicious software) ↔ HITRUST CR 09.j, which in v11 explicitly references software composition analysis and vulnerability management tooling.

The SBOM-adjacent HITRUST controls that carry no direct HIPAA counterpart — and therefore represent the depth HIPAA alone would miss — are CR 10.m (acquisition of software), CR 10.n (supplier service delivery management), and CR 02.a (information security in the supply chain). These are where healthcare supply-chain rigor actually lives.

Medical Device Software

The software supply chain in healthcare has a sharp edge: medical devices. The FDA's 2023 cybersecurity guidance under Section 524B of the FD&C Act requires premarket submissions to include an SBOM for cyber devices. HITRUST has incorporated this expectation into its Medical Device Connectivity (MDC) insights module. HIPAA itself is silent on SBOMs for medical devices, but a hospital that operates devices is still subject to § 164.308 risk analysis — and that analysis must cover the devices.

The practical answer: a covered entity should demand SBOMs from device manufacturers under § 524B and its BA agreements, and incorporate the SBOMs into the continuous-monitoring controls required by HITRUST CR 09.aa.

Building the Integrated Program

I run supply-chain programs for healthcare clients with five artifacts, each serving both frameworks:

1. Supplier inventory — every BA and every software supplier, with tiering based on ePHI access. Satisfies § 164.308(b) and HITRUST CR 05.a.
2. Component inventory — an SBOM for every application that processes ePHI, covering direct and transitive dependencies. Satisfies HITRUST CR 10.m and supports § 164.308(a)(1)(ii)(A).
3. Vulnerability register — a live view of CVEs in deployed components, with risk rankings and SLA-tagged tickets. Satisfies HITRUST CR 10.k (control of technical vulnerabilities) and informs § 164.308 risk analysis.
4. Supplier review artifacts — SOC 2 reports, HITRUST certifications, or equivalent, refreshed on contract renewal. Satisfies HITRUST CR 05.c.
5. Medical device attestations — SBOMs from manufacturers under § 524B, plus patching cadence documentation. Satisfies the medical-device-specific HITRUST insights and FDA's postmarket expectations.

Each artifact has a HIPAA reference and a HITRUST Control Reference tagged in the GRC tool. When a HITRUST assessor samples the supplier inventory, the same record serves an OCR investigation.

Common Mistakes

Treating BA agreements as supply chain strategy. BA agreements transfer liability but don't reduce risk. Depth comes from component inventory and continuous monitoring.

Ignoring transitive open-source dependencies. A BA may not write the code, but if its application ships log4j-core indirectly, the covered entity carries the risk. The SBOM has to be transitive.

Annual snapshots. HITRUST CR 09.aa expects monitoring, not annual review. Vulnerability posture changes weekly; so should the inventory.

How Safeguard Helps

Safeguard generates SBOMs for every build, maintains a live component inventory with vulnerability and license metadata, and tags each finding to HIPAA Security Rule citations and HITRUST Control References in a single view. Supplier risk assessments pull real component-level data rather than questionnaire responses, so HITRUST CR 05.a evidence is current rather than self-reported. For medical device programs, Safeguard ingests manufacturer SBOMs under § 524B and tracks patching cadence against postmarket guidance. Policy gates enforce vulnerability SLAs aligned to HITRUST CR 10.k and produce audit logs that satisfy § 164.312(b).