How to Merge Two HIPAA Risk Analyses After an Acquisition

You combine two HIPAA risk analyses by treating the acquisition as the "environmental or operational change" the Security Rule already names, then rebuilding one analysis from the ground up: one inventory of every system and software component that touches ePHI across both companies, one risk scale that both old analyses are translated into, the acquired company's code, open source and vendors brought into scope, business associate agreements checked and re-papered, and one risk management plan with owners and dates. You do not staple the two documents together. Regulators look for one accurate and thorough analysis that matches the organisation as it exists now.

This post is for the compliance or GRC lead at a US digital health company who has just closed an acquisition and now owns two analyses that disagree. It covers what the rule requires, how to reconcile scales and inventories, software, vendors and BAAs, the proposed rule changes, and then how Safeguard handles the evidence side. This is general information, not legal advice; your counsel and your security official make the calls.

Key takeaways

• The acquisition is a trigger, not a calendar event. The Security Rule requires you to review security measures and documentation in response to "environmental or operational changes" (45 CFR 164.306(e), 164.308(a)(8), 164.316(b)(2)(iii)). Closing a deal that adds systems, people and ePHI is that change.
• One organisation needs one risk analysis. Rebuild the scope from both companies' ePHI flows, then translate both old risk registers onto one scale.
• Software is in scope. The acquired company's applications, their open source dependencies and the vendors behind them handle ePHI, so they belong in the analysis.
• BAAs follow the ePHI. Map which agreements cover which flows, which name the wrong legal entity, and which subcontractor chains now run through the combined company.
• The January 2025 Security Rule proposal is not law. Plan around the current rule until a final rule is published.
• Safeguard capabilities covered here, all GA: the Compliance and GRC suite with the HIPAA Security Rule framework, controls, evidence and risks (GA); SBOM generation and SCA with vulnerability management (GA); Third Party Risk Manager for vendors and SBOM requests (GA); the organisation hierarchy for running two companies in one tenant (GA); and the local runner in the Safeguard CLI for code you cannot hand to a cloud service (GA).
• Safeguard does not make risk decisions, sign BAAs or cover physical safeguards and workforce matters. Those stay with you.

The situation

The deal closed. The integration plan has a line that says "HIPAA: harmonise," and that line is yours.

You have two risk analyses. Yours was refreshed nine months ago, uses a five by five likelihood and impact matrix, and covers the patient app, the clinician portal and the data platform. Theirs was written by a consultant eighteen months ago, uses High, Medium and Low, lists systems by vendor name rather than by data flow, and says nothing about the open source packages in their mobile app. The two disagree on what counts as a system. One treats the cloud provider as the only business associate.

Meanwhile, engineering is already connecting the acquired product to your identity provider and data warehouse, creating new ePHI flows before anyone has assessed them. Legal is assigning contracts, so some BAAs now name an entity about to be merged away. And your customers, health plans and provider groups who rely on you as a business associate, want an updated security questionnaire for "the combined company."

A bad week looks like this: a customer asks for your current risk analysis and you send one that does not mention the product they just bought; a breach in the acquired stack is reported and nothing shows anyone looked at that system; an OCR data request arrives and the newest analysis on file predates the deal. None of these require bad faith, only another quarter of two documents side by side.

What the Security Rule actually requires

45 CFR 164.308(a)(1)(ii)(A) and (B): risk analysis and risk management

Under the security management process standard, 45 CFR 164.308(a)(1)(ii) lists four required implementation specifications. The first two are the ones that matter here:

• (A) Risk analysis (Required). Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity and availability of ePHI held by the covered entity or business associate.
• (B) Risk management (Required). Implement security measures sufficient to reduce those risks and vulnerabilities to a reasonable and appropriate level to comply with 164.306(a).

Two things follow. The analysis must cover ePHI "held by" the entity, which after closing includes what the acquired company holds. And a risk management plan built on an analysis that leaves out half the estate cannot show risks were reduced, because half were never identified.

Check (C) sanction policy and (D) information system activity review too: the acquired workforce and its logs now fall under yours.

164.306: flexibility, and the maintenance duty

45 CFR 164.306(b) gives you room. You may use any security measures that let you reasonably and appropriately implement the standards, and in choosing them you must consider your size, complexity and capabilities, your technical infrastructure, the cost of measures, and "the probability and criticality of potential risks to" ePHI. That last factor is why the scale you use matters: probability and criticality are what a risk scale measures.

164.306(e) then says you must review and modify security measures "as needed" to keep protection reasonable and appropriate, and update documentation under 164.316(b)(2)(iii). An acquisition is the clearest "as needed" you will see.

164.308(a)(8): evaluation after environmental or operational change

The evaluation standard at 45 CFR 164.308(a)(8) requires a periodic technical and nontechnical evaluation, first against the standards and then "in response to environmental or operational changes affecting the security of" ePHI. The evaluation and the updated analysis are different obligations, but you run them together: the evaluation says how well each company's policies meet the rule, the analysis says what risk remains.

164.316(b): documentation, retention and updates

45 CFR 164.316(b)(1) requires written (electronic is fine) policies and procedures and a written record of any action, activity or assessment the subpart requires to be documented. A risk analysis is one. 164.316(b)(2) then adds three required specifications: retain documentation for six years from creation or from when it was last in effect, whichever is later; make it available to the people who implement the procedures; and review it periodically and update it "in response to environmental or operational changes."

So do not delete the acquired company's old analysis. Keep both originals, mark them superseded with the date of the merged analysis, and retain them for six years from that date.

164.308(b) and 164.314(a): business associate assurances

45 CFR 164.308(b)(1) lets a covered entity permit a business associate to create, receive, maintain or transmit ePHI only if it obtains satisfactory assurances, in line with 164.314(a), that the business associate will safeguard it. 164.308(b)(2) applies the same rule one level down: a business associate may use a subcontractor only with the same kind of assurances.

45 CFR 164.314(a)(2)(i) sets what the contract must say. The business associate must comply with the applicable requirements of the Security Rule; ensure that subcontractors handling ePHI agree to comply through a compliant contract; and report security incidents it becomes aware of, including breaches of unsecured PHI under 164.410. 164.314(a)(2)(iii) applies the same terms to contracts between a business associate and its subcontractor.

For a digital health company this cuts both ways: you are your customers' business associate, and your vendors are your subcontractors. After the deal, every relationship on both sides needs a contract that names the right entity and carries the required terms.

What HHS guidance says about scope

HHS's Guidance on Risk Analysis Requirements under the HIPAA Security Rule, issued by OCR, describes the scope in plain terms: the analysis includes all ePHI the organisation creates, receives, maintains or transmits, in every form of electronic media, regardless of where it sits. It lists elements HHS expects to see: the scope; data collection on where ePHI is stored, received, maintained or transmitted; identification and documentation of threats and vulnerabilities; an assessment of current security measures; the likelihood of threat occurrence; the potential impact; the level of risk; final documentation; and periodic review and updates. The guidance does not prescribe a method or a scale, which is what makes merging two analyses possible: neither company's method was "the" method.

Why OCR is paying attention now

An accurate and thorough risk analysis is a required implementation specification under 45 CFR 164.308(a)(1)(ii)(A), and a post-acquisition gap is an easy way to fall short of it.

NIST SP 800-66 Rev. 2: how to structure the work

NIST SP 800-66 Rev. 2, published in February 2024 as "Implementing the HIPAA Security Rule: A Cybersecurity Resource Guide," is the most useful structure for a merged analysis because it separates the steps cleanly. Its risk assessment guidance walks through preparing for the assessment (scope, ePHI locations, sources of information), identifying realistic threats, identifying potential vulnerabilities and predisposing conditions, determining the likelihood that a threat exploits a vulnerability, determining the impact, determining the level of risk, and documenting the results. Its risk management guidance then covers responding to each risk: accept, mitigate, transfer or avoid, with the reasoning recorded.

For a merge, the early steps are inventory work you can split between the two teams, and the likelihood, impact and risk level steps are where the two scales become one. NIST also maps each Security Rule standard to key activities and sample questions, a ready checklist for 164.308(a)(8).

Step by step: merging two risk analyses

These steps work with spreadsheets, a GRC tool or anything in between. Each produces an artifact for the documentation set.

Step 1: Declare the trigger and freeze the baseline (week 1)

Write a one page memo, signed by the security official named under 164.308(a)(2), that says:

1. The acquisition closed on a stated date and is an environmental and operational change under 164.306(e) and 164.308(a)(8).
2. A merged risk analysis will be completed by a stated date, and an interim risk management plan covers the period in between.
3. Both existing analyses remain in effect for their own scope until the merged analysis is approved, then are retained as superseded records under 164.316(b)(2)(i).

Then freeze copies of both analyses, asset lists, vendor lists and policy sets as your "before" evidence.

Step 2: Agree on one unit of analysis

Two analyses usually disagree because they count different things: one lists vendors, one applications, one data stores. Pick one unit and convert both into it.

The unit that holds up best is the ePHI flow: a path by which ePHI is created, received, stored, processed or transmitted, with the systems and parties on it. "Patient enters symptoms in the mobile app, data goes to the API, the clinical database, then the analytics pipeline" names every system and party, so threats, vulnerabilities and controls attach to the right place.

Step 3: Build one ePHI inventory

Interview both teams and pull from both companies' cloud consoles, identity providers, code hosts and contracts. For each flow record these fields.

Expect the acquired company's inventory to be thinner.

Step 4: Reconcile the two risk scales

You cannot rank a "High" against a "15." Build a translation, document it, and apply it to every inherited risk before you re-score anything. An illustrative example with invented numbers: Suppose your scale is likelihood 1 to 5 times impact 1 to 5, giving 1 to 25, with bands Low 1 to 6, Medium 8 to 12, High 15 to 25. The acquired company used qualitative High, Medium and Low for both likelihood and impact and combined them in a three by three grid.

A risk they rated Medium likelihood and High impact becomes 3 times 5, which is 15, High on your bands. Low and Low becomes 4, Low. Three rules make the translation defensible:

1. Translate first, re-score second. Record the translated score beside the original. Then re-score with current information and keep both. An examiner who sees a risk drop from 15 to 6 wants to see why.
2. Write down the definitions. Each likelihood and impact level needs a sentence that a third party could apply. "Impact 5: unauthorised disclosure of more than 100,000 patient records, or loss of availability of a clinical system for more than 24 hours" is better than "severe."
3. Do not average. Where both analyses scored the same risk differently, re-assess it on the merged definitions. Averaging hides the disagreement you need to resolve.

If neither scale is good, define a fresh one on the NIST SP 800-66 Rev. 2 structure and map both old registers into it.

Step 5: Deduplicate and re-score the register

Merge the two registers on the flow inventory. For every risk:

1. Attach it to one or more flow IDs.
2. Mark duplicates (the same threat and vulnerability on the same flow) and keep one record with both sources noted.
3. Re-score likelihood and impact on the merged definitions, using current control status.
4. Add risks neither analysis captured. Integration work is a frequent source: new network paths, shared credentials, temporary data copies for migration, and identity federation between the two estates.

Step 6: Bring the acquired company's software into scope

This is where most merged analyses are thinnest. For each application on an ePHI flow:

1. Get an SBOM. Generate one from source or the build in SPDX or CycloneDX. If no cloud tool can reach the acquired repositories yet, generate it locally.
2. Match components against known vulnerabilities. Use public sources such as the National Vulnerability Database, the GitHub Advisory Database, OSV and CISA's Known Exploited Vulnerabilities catalog, with EPSS for prioritisation.
3. Translate findings into risks, not just tickets. A known exploited vulnerability in a library that parses clinical documents on an internet facing service is a risk entry on the merged scale, attached to the flow. A low severity issue in a development tool is usually a ticket.
4. Record what you could not see. Closed source components, managed services and devices without SBOMs are gaps; list them as risks with "unknown component inventory" as the vulnerability.

Step 7: Bring the acquired company's vendors into scope

Build one vendor list across both companies and classify each vendor by whether it touches ePHI.

Tier vendors by the ePHI they touch and the criticality of the flow, then assess the top tier first.

Step 8: Run the 164.308(a)(8) evaluation on both policy sets

Compare both companies' policies standard by standard, using NIST SP 800-66 Rev. 2's key activities as the checklist. For each standard, record which policy you keep, what changes, and when the acquired workforce will be trained. Gaps become risks in the register.

Step 9: Write one risk management plan with dates

For each risk above your acceptance threshold, record the treatment, owner, target date and the evidence that will prove completion. Accepted risks need a named approver and a reason tied to 164.306(b).

Step 10: Approve, publish internally, and set the next review

The security official approves the merged analysis and plan. Make it available to the people who implement the procedures (164.316(b)(2)(ii)). Set a review date and the events that would trigger an earlier one, such as a major integration milestone or a security incident.

A 90 day timeline you can adapt

How do you reconcile two risk scales and two asset inventories?

Pick one unit (the ePHI flow), map both inventories onto it, write down a translation from the old scales to one merged scale, translate before you re-score, and keep both scores for every inherited risk.

Two inventories rarely use the same names for the same thing. Match on technical identifiers (cloud resource IDs, repository URLs, domain names) rather than labels, and record merges explicitly ("their 'Core DB' is our 'clinical-prod-db', same instance"). Where both companies run a system doing the same job, keep both entries until one is retired; each carries its own risk until it is gone.

How do you bring the acquired company's software and vendors into scope?

Treat software as an asset class with its own inventory. For each application on an ePHI flow, the SBOM is the inventory, and vulnerability matching against it feeds the vulnerability step of the analysis. The merged vendor list, classified by ePHI access and tied to flows, feeds both the BAA review and the third party risks.

Plan for local scanning, because your tools may not reach the acquired repositories for weeks. Ask top tier vendors for SBOMs and vulnerability status for software that touches ePHI; the ones you do not get are themselves a documented risk.

Which BAAs must be updated or replaced?

Work through four groups. Each needs a decision from counsel.

For every agreement, bring counsel the parties, the ePHI flows it covers, the subcontractor and incident reporting terms, and any assignment clause. In the register, record only that the agreement exists, what it covers, and counsel's decision.

What is the status of the proposed HIPAA Security Rule changes?

HHS published a notice of proposed rulemaking, "HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information," in the Federal Register on 6 January 2025 (RIN 0945-AA22), with comments due by 7 March 2025. The Spring 2025 Unified Agenda lists the action at the final rule stage. As of this post's review date, no final rule has been published in the Federal Register, so the current Security Rule is still the rule you are measured against.

Among other changes, the proposal would:

• Require a written inventory of technology assets and a network map showing how ePHI moves through systems, reviewed at least every 12 months and when the environment or operations change.
• Spell out what the written risk analysis must contain, including a review of the asset inventory and network map, identification of threats and vulnerabilities, and documented likelihood and impact.
• Remove the distinction between "required" and "addressable" implementation specifications, with limited exceptions.
• Require business associates to verify at least once every 12 months, through a written analysis by a subject matter expert and a certification, that they have deployed required technical safeguards.
• Add specific technical controls, including encryption of ePHI at rest and in transit, multi factor authentication, vulnerability scanning at least every six months and penetration testing at least every 12 months, and a compliance audit at least every 12 months.

Since you are rebuilding anyway, building the inventory and network map now costs little and is good practice under the current rule. Just do not call them a current legal requirement.

What remains the covered entity's or business associate's own job?

Tools collect evidence. People decide. These stay with you:

• Risk decisions. Likelihood, impact, treatment and acceptance, recorded with reasons by named people.
• Policies. Choosing which company's policy survives, approving and enforcing it.
• Workforce. Training acquired staff, sanctions, and access during integration.
• Contracts. Negotiating and signing BAAs.
• Physical safeguards. Facility access, device and media disposal, workstation security.
• Notifications. Breach assessment and notification under the Breach Notification Rule.
• Sign off. One named security official owns the merged analysis.

How Safeguard does this

Safeguard handles the data side of the merge: one place for both companies' software inventory, vulnerability data, vendors, HIPAA controls, evidence and risks. Where the docs do not show a screen, the outcome is described instead.

1. Put both companies in one tenant with the organisation hierarchy (GA)

Safeguard organises data as Tenant, then Organization, then Project, then Version. The docs describe organizations as logical groupings for separate business units with their own access boundaries. Create one organization for the acquired company alongside your existing ones: Settings › Organizations › + New Organization, enter a name, description and contact, then Create. Each organization can carry its own default policy, notification settings and data retention period.

Access follows the same structure. Roles are Tenant Admin, Manager, User and Viewer, with Managers limited to the organizations assigned to them. Invite the acquired team's compliance and engineering leads at Settings › Members › + Invite Member, assign them to their organization, and map SSO groups to roles at Settings › SSO › Group Mappings once identity is federated. An auditor or outside counsel can get a Viewer role for read only access. Settings › Audit Log records logins, project access, setting changes and role changes, which documents who could see what during the transition.

(The organization management docs also show /v1 REST examples; the docs state those endpoints are not yet available, so use the in app flow.)

2. Generate SBOMs for the acquired applications (SBOM generation and SCA, GA)

From Integrations, connect the acquired company's repositories (the docs cover the major Git hosts and generic Git URLs), container registries, or upload manifest files. Safeguard generates SBOMs in SPDX and CycloneDX, runs software composition analysis across the full transitive dependency tree, and matches components against NVD, GitHub advisories, OSV, CISA KEV and vendor bulletins, with EPSS for prioritisation (vulnerability management, GA). Scanning can repeat on push, on a schedule or on release, so the inventory stays current as integration changes the code.

Group the projects that sit on one ePHI flow into a Product so you see combined risk for that flow rather than per repository.

3. Use the local runner when the acquired code cannot leave its machines (local runner, GA)

Often nobody can grant a cloud service OAuth access to the acquired repositories yet. The local runner, built into the Safeguard CLI, runs scan jobs on a machine you control and uploads only the resulting SBOM and findings, never source code. All traffic is outbound HTTPS that the runner opens.

From the docs:

# macOS and Linux
curl -fsSL https://cli.safeguard.sh/install | bash

# then open the interactive terminal and sign in with /login
safeguard

For an unattended machine inside the acquired company's network:

safeguard runner start --workspace ./path/to/repo
safeguard runner status

The CLI asks before any command that changes something. The SBOMs and findings land in the acquired company's organization like any other project.

4. Switch on and review the HIPAA Security Rule framework (Compliance and GRC suite, GA)

The HIPAA Security Rule framework is on by default unless someone switched it off in Compliance › Manage. Open it from Compliance › Frameworks. Its page shows three kinds of coverage:

• Scan requirements. Each scan of a product checks a short set of HIPAA requirements against what the scan found, including the SBOM. Relevant ones for a merge include Risk Analysis Foundations (identifiable software components matched against known vulnerabilities, 164.308(a)(1)(ii)(A)), Business Associate Assurance (identifying the suppliers behind software in the ePHI chain, 164.308(b)) and Documentation Requirements (identifiable, dated documentation artifacts, 164.316).
• Controls. The Controls tab lists those scan requirements plus controls from Safeguard's catalog for HIPAA, including 164.308(a)(1) Conduct a Security Risk Analysis, 164.308(a)(8) Perform Periodic Security Evaluations, 164.308(b)(1) Manage Business Associate Contracts, 164.314(a) Establish Business Associate Agreements and 164.316(b)(1) Maintain Documentation. You evidence them with automated tests, uploaded evidence, policies or an attestation.
• Policy templates. HIPAA specific templates, including a HIPAA Business Associate Management Policy and a HIPAA Information Security Policy, plus adapted templates from the standard set. Use them as the starting point when you choose which company's policy survives.

The readiness score is the share of in scope requirements that pass, on a scan or on an attestation that names its evidence. The docs say it is Safeguard's assessment of what it can see, not an audit opinion or a certification. Treat it as a progress gauge for the merge.

5. Connect both companies' systems for automated evidence

Automated tests read connected systems (cloud accounts, identity providers, code hosts and others) and map results to HIPAA Security Rule controls. Open the framework, then its Connectors tab, to see which connectors answer its tests, which you have connected, and whether each connection is healthy. Run a test immediately with Run now on Compliance › Tests. Connect the acquired company's cloud accounts and identity provider alongside yours so evidence for both estates lands against the same controls.

Two caveats from the docs. Automated tests are switched on per workspace by the Safeguard team. And a passing result is evidence toward a control, not proof that the control is met on its own.

6. Hold the merged register in the Risks tab

The Compliance and GRC suite includes a Risks tab alongside Frameworks, Controls, Evidence, Monitoring, Tests, Policies, Questionnaires, Vendors, Trust Center and Connectors. Use it as the single register for the merged analysis: one entry per risk, linked to the controls and evidence that bear on it, with the treatment, owner and date from your plan. Safeguard records the risks; your team decides their scores and treatments. Promote only the vulnerability findings that matter on an ePHI flow, as in Step 6, and leave the rest in the engineering backlog.

7. Load the merged vendor list into Third Party Risk Manager (TPRM, GA)

In TPRM, go to Vendors and click Add Vendor, or bulk import: download the CSV template, fill it in, upload it, then review and confirm the import. Each vendor record holds company name, products used, primary contact, contract status (Active, pending, expired), risk tier (Critical, High, Medium, Low), SBOM status and last assessment date. TPRM can suggest a tier, which you can override with a documented justification.

Vendor Relationships tracks parent companies and subsidiaries, which helps when the acquisition means a vendor relationship now runs through a different entity. Contract Management links contract documents, start and end dates, SLA terms, security requirements and SBOM obligations to the vendor; record each BAA here with its status from your counsel review.

8. Request SBOMs from top tier vendors

From a vendor, click Request SBOM, choose products, a template and a deadline, and send; or use Bulk Request from Vendors. Requests move through Sent, Viewed, In Progress, Submitted, then Validated or Rejected, with automatic reminders before and after the deadline. Received SBOMs are checked for format and completeness and scanned for vulnerabilities.

TPRM's vendor risk score runs from 0 to 100 where higher is better, across vulnerability, compliance, component and operational risk, using EPSS and CISA KEV. Note that direction when you translate it into the merged register's likelihood scale.

9. Produce the documentation package

Use Reports › Create Report, select the framework, set scope and date range, then generate and export. Pair the export with the merged analysis, the scale translation, the risk management plan and the superseded originals, and retain the set for six years under 164.316(b)(2)(i).

Where Safeguard fits against each requirement

What Safeguard does not do

• It does not make risk decisions. Safeguard records risks, findings and evidence. Likelihood, impact, treatment and acceptance are judgements your security official makes and signs.
• It does not sign or interpret BAAs. TPRM stores contract records and status. Whether an agreement meets 164.314(a), whether it can be assigned and what replaces it are decisions for counsel.
• It does not cover physical safeguards or workforce management in full. Facility access, workstation placement, training delivery and sanctions sit outside its scope, apart from evidence it can read from systems you connect.
• It does not see software it cannot scan. Managed services, closed source products and devices without SBOMs stay gaps until a vendor provides an SBOM or you document the gap as a risk.
• It does not certify HIPAA compliance. There is no HIPAA certification, and Safeguard's readiness score is its assessment of what it can see, not an audit opinion.
• It does not give legal advice. Safeguard's own posture is designed for FedRAMP High with a SOC 2 Type II audit in progress; none of that transfers to your HIPAA program.

Common mistakes

1. Appending the acquired analysis as a chapter. Two analyses in one binder still have two scales. Rebuild on one inventory and one scale.
2. Averaging scores. When the two analyses disagree on a risk, re-assess it. The disagreement is information.
3. Dropping the originals. The superseded analyses are required documentation for six years.
4. Leaving software out because "the cloud provider handles security." The provider covers its layer. The application code and its open source dependencies are yours.
5. Treating every vulnerability as a risk entry. The register becomes unreadable. Promote findings that matter on ePHI flows.
6. Missing the transition flows. Migration copies, temporary shared credentials and new integrations are new ePHI flows, often created before anyone assesses them.
7. Forgetting the customer side of BAAs. The acquired company's customer agreements may name an entity that is going away.
8. No dates in the plan. A plan without owners and target dates does not show risks being reduced.
9. Waiting for integration to finish. Integration can take a year. The analysis must reflect the organisation as it is now.

FAQ

Do I need a new HIPAA risk analysis after an acquisition?

You need an updated one covering the combined organisation. The Security Rule ties updates to environmental or operational changes (164.306(e), 164.308(a)(8), 164.316(b)(2)(iii)), and an acquisition that adds systems and ePHI is one.

Can I keep two separate risk analyses if the companies stay separate legal entities?

If both remain separate covered entities or business associates, each has its own obligation. Once ePHI flows, systems or staff are shared, one analysis of the combined environment is easier to defend. Ask counsel how the deal structure affects this.

How long do I have to finish the merged risk analysis?

The rule does not set a deadline. The expectation is that the analysis is accurate and current. Set a realistic date, document it in a signed trigger memo, and run an interim plan for known high risks in the meantime.

Are open source dependencies part of a HIPAA risk analysis?

Yes, when they are part of software that creates, receives, maintains or transmits ePHI. The analysis covers potential vulnerabilities to ePHI, and vulnerable components in that software are among them. An SBOM is the practical inventory.

Which BAAs need to change after a merger?

Look at four groups: the acquired company's customer BAAs, its vendor BAAs, your vendors that will now receive new ePHI, and any interim arrangement between the two entities. Check the named entity, the 164.314(a)(2)(i) terms and any assignment or change of control clause, then take each to counsel.

Is the 2025 HIPAA Security Rule proposal in effect?

No. HHS published the proposal on 6 January 2025 and comments closed on 7 March 2025. As of this post's review date, no final rule has been published. The current Security Rule applies.

What does NIST SP 800-66 Rev. 2 add to the HIPAA risk analysis?

It gives a structured method: prepare, identify threats, identify vulnerabilities and predisposing conditions, determine likelihood, impact and level of risk, and document the results, followed by risk management guidance and key activities per Security Rule standard. It is guidance, not a requirement, which makes it a neutral basis for merging two methods.

Can a GRC tool produce the risk analysis for me?

A tool can hold the inventory, findings, evidence and register. The scope, the judgements and the sign off are still yours.

Further reading on the blog

• Add software dependencies to your HIPAA risk analysis
• HIPAA risk analysis vs risk management
• How to merge two dependency policies after a merger
• Security integration plan after an acquisition

Once the merged inventory is in place, the acquired company's applications usually bring a backlog of vulnerable open source dependencies onto ePHI flows, and each one that matters becomes a dated line in your risk management plan under 164.308(a)(1)(ii)(B). The quickest way to close those lines is to move each component to a fixed version, or to a fixed build when upstream has none, and to show the rescan as evidence.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. The same connection lets a compliance lead ask plain language questions of the merged estate, such as which acquired projects carry critical findings.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal: the route for acquired repositories no cloud service can reach yet.

Click through it at your own pace, or open it full screen.

To try it on the acquired company's code, download the app and CLI at https://safeguard.sh/download and read the setup guides at https://docs.safeguard.sh/docs .

Quick check

Sources

• 45 CFR 164.308, Administrative safeguards (eCFR)
• 45 CFR 164.306, Security standards: General rules (eCFR)
• 45 CFR 164.314, Organizational requirements (eCFR)
• 45 CFR 164.316, Policies and procedures and documentation requirements (eCFR)
• HHS, Guidance on Risk Analysis Requirements under the HIPAA Security Rule
• NIST SP 800-66 Rev. 2, Implementing the HIPAA Security Rule: A Cybersecurity Resource Guide
• Federal Register, HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information (NPRM, 6 January 2025)
• Unified Agenda entry, RIN 0945-AA22 (reginfo.gov)
• Safeguard docs: HIPAA Security Rule framework
• Safeguard docs: HIPAA Security Rule and connectors
• Safeguard docs: Compliance
• Safeguard docs: Compliance frameworks
• Safeguard docs: Organization and user management
• Safeguard docs: Generate SBOM
• Safeguard docs: Local runner
• Safeguard docs: TPRM vendor management
• Safeguard docs: TPRM SBOM requests

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.