A Critical Vendor Failed Our Review at Renewal. What Now?

When a critical vendor fails your security review and the business cannot switch this year, you do not have to choose between a clean approval and a termination. Approve conditionally: write each gap into a dated remediation plan inside the renewal, run compensating controls on your side, tighten monitoring with clear escalation triggers, keep a written exit plan, and have the residual risk accepted by someone with the authority to own it.

That is the realistic middle path, and in healthcare it is also the one the rules expect. HIPAA requires satisfactory assurances from business associates and asks covered entities to act when they know of a material breach. Federal and sector guidance on supply chain risk treats "accept with conditions" as a legitimate outcome, as long as it is a decision someone made on the record and not a default nobody signed.

This post is for the vendor risk or procurement lead at a US health tech company or digital health platform who has to sign that renewal. It covers what the rules say, a plan you can run with spreadsheets and email, templates, and, near the end, how Safeguard handles the same flow. Nothing here is legal advice; counsel and your privacy officer own the reading of your business associate agreement.

Key takeaways

• A failed review at renewal has five realistic outcomes: approve, approve with conditions, approve with conditions plus a shortened term, replace on a planned timeline, or terminate. Most "we cannot switch" cases land on the second or third.
• HIPAA (45 CFR 164.308(b), 164.314(a) and 164.504(e)) requires written satisfactory assurances from a business associate, gives you the right to terminate for a material violation, and expects you to take reasonable steps to cure a known material breach before termination, "if feasible".
• NIST CSF 2.0 GV.SC-07 asks that supplier risk be understood, recorded, assessed, responded to and monitored over the relationship, and GV.SC-10 asks for plans covering the end of the relationship. The HSCC HIC-SCRiM 2023 guide lists mitigate, transfer, accept and avoid as the four treatment options.
• Every gap becomes a line in a remediation schedule with an owner, a due date, the evidence that closes it, and the consequence if the date slips. Put the schedule in the renewal, not in a side email.
• Compensating controls on your side (tighter access, segmentation, logging, data minimisation, extra backups) are yours to run and evidence. Write them down with the same discipline you ask of the vendor.
• Risk acceptance is signed by a named executive with budget and authority, carries an expiry date, and is kept with your HIPAA documentation for six years.
• Safeguard's TPRM (GA) covers vendor records, SBOM requests, a vendor risk score, documented risk acceptance and remediation tracking, plus continuous monitoring with alerts. Mitigation records with expiry and approver (GA) and the Compliance and GRC suite with its Risks and Vendors tabs (GA) hold the decision trail.
• Safeguard does not negotiate the contract, enforce the vendor's plan or make the acceptance decision. Those stay with you.

The situation

The renewal is due in six weeks. The vendor runs something the business depends on every day: a clinical documentation platform, a patient engagement system, a claims or eligibility data pipeline, a data warehouse full of protected health information (PHI). Your annual review came back with real findings. Maybe the vendor could not produce a current penetration test summary. Maybe their software bill of materials (SBOM) showed components with known exploited vulnerabilities that have been open for months. Maybe multi factor authentication is still optional for their support staff, or their incident notification clause promises "prompt" notice with no number of days attached.

Then the business owner says it: "We cannot switch this year." Migration would take most of a year, clinicians are trained on the tool, and integrations are wired into everything.

The business wants a signature, security wants the findings fixed, and compliance wants a record that someone looked, decided and followed up. A bad week looks like this: you approve quietly to avoid a fight, the gaps stay open, and eight months later the vendor has an incident and the first question from leadership, customers or a regulator is "what did you know at renewal, and what did you do about it?"

The answer can be strong even when the vendor is weak. What protects you is a clear record that you found the gaps, required dated fixes, reduced your own exposure, watched closely and had a way out.

If you are earlier in the cycle, two related posts may help first: how to tier health software vendors by PHI risk and running a vendor security review for a new clinical software purchase. This post assumes the vendor is already in place and has just failed.

What HIPAA's business associate provisions require

Start with the regulation, because it shapes what "approve with conditions" can and cannot mean for a vendor that touches PHI. These are the current texts in the Electronic Code of Federal Regulations; the eCFR version history for 164.308 shows its last amendment dated 30 December 2016, so the 2013 Omnibus text is what applies today.

164.308(b): satisfactory assurances, in writing

Under 45 CFR 164.308(b)(1), a covered entity may let a business associate create, receive, maintain or transmit electronic PHI on its behalf only if it obtains "satisfactory assurances" that the business associate will appropriately safeguard the information. 164.308(b)(2) applies the same rule one level down: a business associate may use a subcontractor only with the same satisfactory assurances. 164.308(b)(3) makes the written contract or other arrangement a required implementation specification.

That second paragraph matters for health tech companies. If your platform is a business associate to hospitals or health plans, the vendor that failed your review is probably your subcontractor business associate. The obligations then run from you to them in the same shape as they run from your customers to you, and your own customers' agreements may require you to flow certain terms down.

164.314(a): what the contract must say

45 CFR 164.314(a)(2)(i) lists what the business associate contract must provide for electronic PHI. The business associate must comply with the applicable requirements of the Security Rule, must make its own subcontractors agree to the same, and must report any security incident it becomes aware of, including breaches of unsecured PHI as required by 164.410. 164.314(a)(2)(iii) applies those requirements to the contract between a business associate and its subcontractor.

Notice what is not in that list: a specific pen test cadence, a vulnerability remediation deadline, an SBOM, multi factor authentication for support staff. Those are reasonable things to require, but they come from your contract and your risk program, not directly from the regulation's contract clause. That is why renewal is the moment you have the most say.

164.504(e): cure, or terminate if feasible

The Privacy Rule's business associate standard is where the "what if they fall short" question is answered. 45 CFR 164.504(e)(1)(ii) says a covered entity is not in compliance if it knew of a pattern of activity or practice of the business associate that constituted a material breach or violation of the business associate's obligations, unless it took reasonable steps to cure the breach or end the violation and, if those steps failed, terminated the contract, "if feasible". 164.504(e)(1)(iii) applies the same rule to a business associate that knows of a material breach by its subcontractor.

164.504(e)(2)(iii) requires the contract to authorise termination by the covered entity if the business associate has violated a material term.

Two readings are worth keeping straight, and this is where your counsel earns their fee:

1. Not every failed security review is a "material breach" of the business associate agreement. A vendor can fail your internal bar (for example, no SBOM, or a weak pen test cadence) while still meeting the agreement as written. In that case the HIPAA cure or terminate rule may not be triggered at all, and your task is risk management under the Security Rule.
2. If a finding does amount to a known material breach (for example, the vendor is not reporting security incidents as the agreement requires), then you are expected to take reasonable steps to cure it. The words "if feasible" exist, but relying on them means documenting why termination was not feasible and what you did instead. A dated cure plan is the reasonable step.

Your own Security Rule obligations still apply

Your organisation still owes its own risk analysis and risk management. 164.308(a)(1)(ii)(A) requires an accurate and thorough assessment of risks to electronic PHI, and 164.308(a)(1)(ii)(B) requires security measures sufficient to reduce those risks to a reasonable and appropriate level. 164.308(a)(8) requires periodic evaluation in response to environmental or operational changes. A vendor that failed review is exactly such a change, and the compensating controls you add later in this post are how you show risk management happened.

Finally, 164.316(b)(2)(i) requires that Security Rule documentation be retained for six years from creation or from the date it was last in effect, whichever is later. Your acceptance memo, remediation schedule and evidence of follow up belong in that retention scope.

Your options when a business associate falls short

Put together, the rules leave you five practical options. The table below is the decision most readers actually face.

For a vendor the business truly cannot replace this year, the middle three rows are where you will be. The rest of this post is how to do them well.

What the HHS HPH CPGs and the HSCC supply chain guide expect

HIPAA tells you the legal floor. Sector guidance tells you what good looks like, and it is what a sophisticated customer, auditor or board member will compare you against.

HHS Healthcare and Public Health Cybersecurity Performance Goals

HHS published voluntary Healthcare and Public Health (HPH) Cybersecurity Performance Goals (CPGs), aligned with the Health Industry Cybersecurity Practices (HICP) and with CISA's cross sector goals, to help healthcare organisations prioritise high impact practices. They come in two tiers: essential goals that set a floor, and enhanced goals for organisations ready to go further.

Vendor risk appears in both tiers. The essential goal "Vendor/Supplier Cybersecurity Requirements" asks organisations to identify, assess and mitigate risks associated with third party products and services. Two enhanced goals go further: Third Party Vulnerability Disclosure (processes to promptly discover and respond to known vulnerabilities in assets provided by vendors and service providers) and Third Party Incident Reporting (the same for security incidents or breaches across vendors and service providers). The CPGs are voluntary, but they state HHS expectations plainly, and a renewal is the natural place to turn them into terms.

HSCC Health Industry Cybersecurity Supply Chain Risk Management Guide (HIC-SCRiM 2023)

The Health Sector Coordinating Council's HIC-SCRiM guide, the 2023 edition being the current one on the council's site, is written for small to mid sized healthcare organisations building a supplier risk program. It is useful here for three reasons.

First, it treats the supplier relationship as a lifecycle that runs from pre contract work through to termination, including an end of relationship or exit checklist (for example, return of assets). A failed renewal is one point on that lifecycle, not an exception to it.

Second, it says the organisation must define how it treats identified supplier risk, with criteria for four options: mitigating risk by implementing compensating controls, transferring risk (for example through cyber insurance), accepting risk as "a business decision informed by an understanding of the risk vs the business value", and avoiding risk by finding an alternate supplier or solution. Those four map directly onto the decision table above.

Third, it supplies templates: a contractual language and requirements template (Appendix D) and example supplier cybersecurity KPIs to demonstrate contractual compliance (Appendix F). If you need contract language for the remediation schedule and do not have counsel's standard clauses yet, start there.

NIST CSF 2.0 and NIST SP 800-161 Rev. 1

The NIST Cybersecurity Framework 2.0 (CSWP 29, 26 February 2024) puts supply chain risk management in the Govern function under GV.SC. Four subcategories line up with a failed renewal:

• GV.SC-04: suppliers are known and prioritised by criticality. You need to show this vendor is critical, which is why you are accepting conditions instead of walking away.
• GV.SC-05: requirements to address supply chain risk are established, prioritised and integrated into contracts. The remediation schedule is that requirement.
• GV.SC-07: supplier risks are "understood, recorded, prioritized, assessed, responded to, and monitored over the course of the relationship". Every section below is one of those verbs.
• GV.SC-10: supply chain risk management plans include provisions for activities after the conclusion of a partnership or service agreement. That is your exit plan.

NIST SP 800-161 Rev. 1 (May 2022, with updates as of 1 November 2024) is the deeper federal reference on cybersecurity supply chain risk management. You need not adopt it wholesale, but it is the document to cite when leadership asks whether managing a supplier risk instead of avoiding it is a recognised approach.

Step by step: from a failed review to a defensible renewal

This sequence works with whatever tools you have. A shared spreadsheet, your contract management system and email are enough. The timeline assumes six weeks to renewal; compress or stretch it to fit.

1. Confirm criticality and the switching constraint in writing (week 1). Ask the business owner for a short note: what the vendor does, what PHI it holds, how many users and patients depend on it, and the realistic migration time. This is your GV.SC-04 evidence and the "not feasible" record if HIPAA's cure rule is ever relevant.
2. Grade every finding (week 1). For each gap record the evidence, the risk to PHI (confidentiality, integrity, availability), and a severity. Separate "fails our bar" from "may breach the agreement". Send the second list to counsel.
3. Share findings with the vendor and ask for a plan (week 2). Give them the list and a deadline to respond with a fix, a date and the evidence they will provide. Vendors respond better to specific asks with dates than to a pass or fail verdict.
4. Decide the treatment per gap (week 2 to 3). For each finding choose mitigate (they fix it), compensate (you add a control), transfer (insurance or contract indemnity), or accept. Most real plans mix all four.
5. Design your compensating controls (week 3). For any gap the vendor will not close quickly, decide what you will do on your side, who runs it and how you will evidence it.
6. Write the remediation schedule into the renewal (week 3 to 5). The schedule, the evidence requirements and the consequences for missed dates go into an amendment or an exhibit to the contract, alongside any business associate agreement updates counsel recommends.
7. Set monitoring and triggers (week 4). Define what you will watch, how often, and which events cause escalation or invoke the exit plan.
8. Draft the exit plan (week 4 to 5). Data return format and timing, transition assistance, the candidate replacement list and the cost estimate. A plan you never use is still the reason the vendor takes the schedule seriously.
9. Get the residual risk accepted (week 5). The acceptance memo goes to the executive who owns the business outcome and has authority over the budget, with security and privacy sign off attached.
10. Sign, then calendar every date (week 6). Every remediation milestone, every review, the acceptance expiry, and the next renewal decision point go into a calendar someone actually reads.

A same day checklist

If you only have today, do these six things:

• Get the business owner's switching constraint in writing.
• Split findings into "fails our bar" and "may breach the agreement", and send the second list to counsel.
• Ask the vendor for a dated plan per finding by a fixed date.
• List the compensating controls you can switch on within 30 days.
• Book 30 minutes with the executive who will sign the acceptance.
• Open the renewal record and attach everything so far.

How to write the gaps into a remediation plan with dates and evidence

A remediation plan is only as good as its weakest line. "Vendor will improve vulnerability management" is not a line. "Vendor will remediate all critical vulnerabilities listed in Exhibit B and deliver a rescan report showing closure by 31 January 2027" is a line.

Every row needs six fields:

An illustrative remediation schedule

The rows below are illustrative examples with invented dates; replace them with your own findings.

Ask for evidence a third party could check: "we have MFA" is a statement, while a configuration attestation signed by a named vendor executive is evidence. Keep the interim control on the same row as the gap, because the risk does not wait for the due date. And tie each date to a contractual consequence (fee credits, audit rights, removal of standing access, a termination right tied to milestones); a missed date with no consequence is a suggestion. The HSCC guide's Appendix D is a starting point for clause language, and counsel decides the final wording.

For what to ask for alongside the plan, our post on what to re-request from a supplier at contract renewal covers SBOM and attestation requests in detail.

Which compensating controls you can run on your side

A compensating control is something you do that reduces the risk the vendor's gap creates. It is yours to run and yours to evidence. The HSCC guide lists implementing compensating controls as the first form of risk mitigation, and your HIPAA risk management obligation is the reason you need them.

Pick controls that reduce either the likelihood of the vendor's gap being exploited or the impact on your PHI if it is.

A compensating control only counts if someone runs it, so assign an owner per control, not a team. Controls also cost money and time; put that cost in the acceptance memo, because it is part of the true price of keeping this vendor.

What monitoring and triggers lead to escalation or exit

Conditional approval without monitoring is just approval with a longer memo. GV.SC-07 asks for monitoring across the whole relationship, and the HSCC guide expects you to confirm suppliers are meeting their contractual commitments.

What to monitor

• Milestone status. Each line of the remediation schedule, checked on its date and two weeks before.
• Vulnerability exposure. New critical vulnerabilities and CISA KEV additions affecting components the vendor ships to you, where you have an SBOM or component list.
• Incidents. Vendor incident notices, public breach reports, and your own alerts on unusual activity.
• Operational signals. Response times to your requests, missed SLAs, sudden staff or ownership changes, acquisition news.
• Your compensating controls. Whether they are still running. Access reviews and key rotations drift.

Triggers and what they cause

The exit plan

GV.SC-10 asks for provisions for the end of the relationship, and the HSCC guide includes an exit checklist. Even if you never use it, write down:

• What data the vendor holds, in what format, and how it comes back (format, timeline, verification of deletion afterward).
• What the transition looks like: parallel running, data migration, integration rewiring, user training.
• Two or three candidate replacements and a rough cost and timeline for each.
• The contract terms that make exit possible: termination for cause, transition assistance, data return and destruction (164.504(e)(2)(ii) already requires return or destruction of PHI at termination where feasible).

A vendor that knows you have priced the migration tends to take its dates seriously.

If a vendor incident does happen while the conditions are in force, our post on what to do when a vendor tells you they were breached walks through the first days.

Who must accept the risk, and how it is recorded

The person who accepts the risk should be the person who owns the business outcome the vendor supports and has the authority to spend money to change it. Usually that is a business executive (a chief operating officer, chief medical or product officer, or the general manager of the line of business), with the CISO or security official and the privacy officer recording their view. The security team advises; it should not be the sole signer of a business risk it cannot fund away.

Your risk policy may set thresholds, for example low residual risk accepted by a director, high residual risk by an executive, and large volumes of PHI reported to a risk committee or the board. If you have no such policy, write one now.

What the acceptance record should contain

Store it where your HIPAA documentation lives. 164.316(b)(2)(i) requires six year retention from creation or last effective date, and an acceptance that is renewed is "in effect" until replaced, so the clock keeps moving.

One more habit: give every acceptance an expiry date and treat expiry as a new decision. Acceptances without dates become permanent by accident.

How Safeguard does this

Everything above works with spreadsheets. If you already run Safeguard, or want one place to keep the vendor record, the evidence and the decision trail, this is how the same flow maps onto the product. Each capability below is generally available (GA). Screens and actions are named only where Safeguard's docs show them.

1. Record the vendor and its tier in TPRM (GA). Third Party Risk Manager keeps a vendor directory with contacts, contract and SLA tracking, and risk categorisation. The TPRM docs describe a Critical tier for core business operations, with an SBOM required and refreshed quarterly. A vendor the business cannot replace belongs there.
2. Request an SBOM with a deadline. From the vendor record, the docs describe clicking Request SBOM, selecting the products, choosing a request template, setting a deadline and sending. The standard template asks for SPDX or CycloneDX with the fields EO 14028 expects. Request status moves through Sent, Viewed, In Progress, Submitted, Validated or Rejected, and automated follow ups go out 7 days before the deadline, at the deadline, and as an escalation 7 days after. Vendors can submit by email attachment, a secure upload portal, API or direct integration.
3. Let validation do the first pass. When an SBOM arrives, Safeguard checks the format, checks completeness against required fields, verifies the EO 14028 elements, runs an automatic vulnerability scan and notifies the requester. If it falls short, Request Revision sends the vendor the specific corrections. A missing or invalid SBOM becomes a dated line in your remediation schedule instead of a vague complaint.
4. Read the vendor risk score. TPRM's risk assessment scores each vendor from 0 to 100, where higher is better: 76 to 100 is low risk, 51 to 75 medium, 26 to 50 high and 0 to 25 critical. The score draws on vulnerability risk (critical and high counts, EPSS exploit probability and known exploited vulnerabilities), compliance risk from SBOM quality (EO 14028 coverage, missing fields, SBOM age and format validity), component risk (abandoned packages, license compliance, transitive depth) and operational risk (response time to your requests, update frequency, security incident history, contract compliance). Generate Report produces an executive summary, score breakdown, vulnerability details, compliance gaps and recommendations, which is a ready attachment for the acceptance memo. Comparative analysis puts vendors side by side if you are pricing an exit.
5. Document the acceptance where the finding lives. TPRM's Risk Assessment page describes a Risk Acceptance flow: review the finding, click Accept Risk, provide the business justification, set a review date and obtain the required approvals. That review date is your acceptance expiry.
6. Track the vendor's remediation commitments. The same page describes remediation tracking for requested fixes, vendor commitments, progress updates and verification status. Each row of your remediation schedule maps onto a requested fix and a commitment, and verification status is where the evidence lands.
7. Turn on continuous monitoring with your triggers. TPRM monitoring watches vendor SBOMs for new vulnerabilities, severity changes, exploit availability updates, CISA KEV additions and component health changes. In Settings, Monitoring, you configure alerts for a new critical CVE, a KEV addition, a risk score dropping below your threshold and an SBOM older than your threshold. Alerts go to email, Slack, Microsoft Teams, PagerDuty or a webhook. Periodic re-scans can run daily for critical vendors, or weekly, monthly or quarterly, and re-assessment can be triggered by new disclosures, major version updates, contract renewals and security incidents. The risk score dropping below threshold is a natural "escalate" trigger from the table above.
8. Keep compensating controls and exceptions on the record. When a vendor SBOM is analysed as a project, Safeguard's mitigation records (GA) cover the cases you will meet: Risk Acceptance (with an expiration date), Workaround Applied (including where compensating controls are in place), False Positive and Not Applicable. Each record carries a justification, an Approved By field, optional evidence and a scope. Safeguard notifies you 14 days and 7 days before an acceptance expires and on the day, expired mitigations show up for review, and every create, change, approval, expiry and revocation is logged with who and when. Mitigation reports export as PDF, CSV or Excel. TPRM also lets you view mitigations others have applied, which is useful context when you decide how to treat a vendor finding.
9. Hold the program view in the Compliance and GRC suite (GA). The suite has Risks and Vendors tabs alongside Controls, Evidence and Monitoring, so the vendor acceptance sits in the same place as the rest of your risk register and evidence. The HIPAA Security Rule is one of the frameworks for which Safeguard maps automated tests from the systems you connect, which helps when you want your own compensating controls (identity, access, logging) evidenced continuously rather than by screenshot.
10. Report on a schedule. TPRM scheduled reports run weekly, monthly, quarterly and annually; ad hoc reports export as PDF or Excel. Trend analysis shows risk score, vulnerability count and remediation velocity over time, which is what your acceptance owner will want at the expiry review.

Safeguard holds the evidence and the trail; your signed contract holds the obligation.

What Safeguard does not do

Be clear with your stakeholders about where the product stops.

• It does not negotiate or write your contract. The remediation schedule, consequences, BAA amendments and termination rights are drafted by you and counsel and signed in your contract process. Safeguard can track a commitment; it cannot make one binding.
• It does not enforce the vendor's plan. Automated follow ups and alerts remind and escalate. Whether a missed milestone leads to a fee credit, a shorter term or termination is your decision and your contract's mechanism.
• It does not make the acceptance decision. The Accept Risk flow and mitigation records capture a decision with justification, approvers and expiry. The judgment and the signature belong to your acceptance owner.
• Its view of the vendor depends on what the vendor shares. Risk scoring and monitoring work from the SBOMs, products and evidence the vendor provides. A vendor that sends a thin or stale SBOM produces a thin picture, which is why SBOM quality is itself a line in the schedule. Safeguard does not see inside the vendor's hosted environment or audit its internal controls.
• It does not run your compensating controls. Identity configuration, network restrictions, just in time support access, log ingestion and backups run in your own systems. Safeguard can hold the evidence and, for connected systems, map tests to the HIPAA Security Rule; your teams still operate the controls.
• It does not make HIPAA determinations. Whether a finding is a material breach under 164.504(e), whether termination is feasible, and whether an incident is a reportable breach are legal and privacy calls for counsel and your privacy officer.
• It does not fix the vendor's software. When the vulnerable code lives in the vendor's hosted service, the fix has to come from the vendor.

Common mistakes

1. Approving quietly to avoid conflict. It feels efficient, and it leaves no record that anyone decided anything. The record is the protection.
2. Remediation dates without consequences. A schedule with no contractual weight is a wish list. Tie each date to something that happens if it is missed.
3. Accepting risk with no expiry. Acceptances without dates become permanent. Always set a review date and treat it as a new decision.
4. Security signing the acceptance alone. Security can describe the risk. The business owner who benefits from the vendor and controls the budget should own accepting it.
5. Counting compensating controls nobody runs. If the control has no named owner and no evidence, it does not exist for the purposes of your risk analysis.
6. Confusing "fails our bar" with "breaches the BAA". They lead to different obligations. Get counsel's view on the second list early.
7. No exit plan because "we cannot leave". Even a rough plan with a cost estimate changes the negotiation and satisfies GV.SC-10.
8. Forgetting your own customers' terms. If you are a business associate, your customers' agreements may require flow down terms or notice. Check before you sign with the vendor.

FAQ

What do you do when a critical vendor fails a security review but you cannot replace it?

Approve conditionally. Write each gap into a dated remediation schedule in the renewal with required evidence and consequences, add compensating controls on your side, monitor with clear escalation triggers, keep a written exit plan, and have the residual risk accepted by an executive with authority, with an expiry date.

Does HIPAA require me to terminate a business associate that fails my security review?

Not automatically. 45 CFR 164.504(e)(1)(ii) applies when you know of a pattern of activity that is a material breach of the business associate's obligations; then you must take reasonable steps to cure it and, if that fails, terminate "if feasible". Many failed reviews are gaps against your own standard rather than a material breach. Ask counsel which applies.

What should a business associate agreement require for security?

Under 164.314(a)(2)(i), the agreement must require the business associate to comply with the applicable Security Rule requirements, to bind its subcontractors to the same, and to report security incidents including breaches of unsecured PHI. Many organisations add specifics such as notice timelines, MFA, testing cadence and SBOM delivery through their contract, not because the regulation lists them.

How long do I keep vendor risk acceptance records under HIPAA?

The Security Rule's documentation standard, 164.316(b)(2)(i), requires retention for six years from creation or the date the documentation was last in effect, whichever is later.

What counts as a compensating control for a vendor gap?

Anything you run that reduces the likelihood or impact of the vendor's gap on your data: enforcing your own SSO and MFA, just in time support access, narrower API scopes, data minimisation, your own backups, log ingestion and monitoring. It counts only with a named owner and evidence.

What should trigger exiting a critical vendor?

Repeated missed milestones, refusal to provide agreed evidence, a security incident affecting your data that reveals the plan was not followed, or a known material breach the vendor will not cure. Define the triggers before you sign so the decision is not improvised.

Do the HHS HPH Cybersecurity Performance Goals apply to vendors?

The CPGs are voluntary goals for healthcare organisations, and vendor risk appears in them: vendor and supplier cybersecurity requirements among the essential goals, third party vulnerability disclosure and third party incident reporting among the enhanced goals. They are a good source of terms to write into a renewal.

Can Safeguard decide whether to accept a vendor's risk?

No. TPRM records the acceptance with justification, a review date and approvals, and tracks remediation and monitoring, but the decision belongs to your acceptance owner.

Fix the parts you build, not just the parts you buy

A failed vendor review usually prompts the same question about your own platform: what would your customers find if they reviewed you at renewal? The block below covers how Safeguard closes vulnerability gaps in the open source dependencies and container images you build and ship yourself, which is the side of the relationship you control.

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 shows Claude connected to the Safeguard MCP server with OAuth, where you choose which tools Claude can use. For a vendor risk lead, the same connection is a way to ask questions of the data your team already holds in Safeguard in plain language, with access limited to the tools you allow.

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

The second demo is a real Android session with the Safeguard mobile app, which is available today: you send work to a computer running the Safeguard CLI and approve commands on the phone with Allow once, Allow for turn or Deny. It is a picture of the approval habit this post argues for, where nothing changes without a named person saying yes.

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

Quick check

Sources

• eCFR: 45 CFR 164.308, Administrative safeguards
• eCFR: 45 CFR 164.314, Organizational requirements
• eCFR: 45 CFR 164.316, Policies and procedures and documentation requirements
• eCFR: 45 CFR 164.504, Uses and disclosures: Organizational requirements
• HHS Cyber Gateway: HPH Cybersecurity Performance Goals
• Health Sector Coordinating Council: HIC-SCRiM 2023
• NIST CSWP 29: The NIST Cybersecurity Framework 2.0
• NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices
• Safeguard docs: Third Party Risk Manager
• Safeguard docs: TPRM Risk Assessment
• Safeguard docs: TPRM Monitoring
• Safeguard docs: TPRM SBOM Requests
• Safeguard docs: Mitigations
• Safeguard docs: Compliance

To try the flows above, download Safeguard at safeguard.sh/download and read the docs at docs.safeguard.sh.

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