Short answer: you are, at least in part, no matter what the contract says. HIPAA lets a covered entity delegate the work of handling patient data to a business associate, but not the obligation. If that vendor's environment is compromised, your practice still has notification duties, still faces the reputational fallout, and still has to explain to patients why a company they never heard of had their Social Security numbers.
That is not a hypothetical this month. Unlimited Technology Systems LLC (UTS), a revenue cycle management and practice management software provider based in the Cincinnati/Montgomery, Ohio area, disclosed a breach affecting 3,803,750 individuals. An unauthorized third party obtained files between October 5 and October 10, 2025, and UTS identified the activity on October 19, 2025, according to SecurityWeek's reporting. Exposed data included names, addresses, phone numbers, emails, Social Security numbers, medical record numbers, diagnoses, dates of service, insurance policy numbers, claims and benefits information, and scanned government IDs. Full medical records and imaging were not involved, and no threat group has claimed responsibility.
UTS notified HHS in late July 2026, and the HHS Office for Civil Rights breach portal lists the entry with a submission date of July 21, 2026 — roughly nine months after the October 2025 intrusion. That gap matters most, because the timeline is not academic: it sets the clock on when your patients find out, and it is a clock the business associate controls, not you.
I look at vendor relationships from a procurement chair, not a legal one, so I will not pretend to interpret case law. What I can tell you is what happens on the buyer's side: your own notification exposure is tied to your vendor's forensic timeline, and that timeline is outside your control once you have signed. If a revenue cycle vendor takes ten months to confirm scope and notify HHS, your notification to your own patients is delayed by exactly that long, through no fault of your own operationally, but at your practice's full reputational cost. Patients do not distinguish between "our system was breached" and "our vendor's system was breached." They remember whose name was on the appointment reminder.
It transfers work, not liability. A signed Business Associate Agreement is required before handing PHI to a vendor, but HHS guidance on covered entities and business associates is explicit that business associates carry direct HIPAA liability for their own security failures while the covered entity retains its own separate obligations. That is the part most practices misread: the BAA is not the transaction that closes out risk. It is the document that formalizes a shared, ongoing one.
The BAA typically gets handled at the end of procurement, after pricing and features are settled, signed as a formality because the vendor's sales team hands it over as boilerplate. Nobody in that room is thinking about a forensic timeline nine months out; they are thinking about go-live. That sequencing is the actual problem, not the paperwork itself.
Four things, none exotic. Ask for evidence of independent security testing, not a self-attestation — a recent penetration test summary or SOC 2 report tells you whether someone other than the vendor has looked under the hood. Ask whether PHI is encrypted at rest, not just in transit, since smaller billing and RCM vendors have historically underinvested here because it is invisible during a sales demo. Ask about data minimization and retention limits: how long is claims data kept after a patient relationship ends, and what categories of PHI does the vendor actually store. And ask how they inventory their own subcontractors, since your BAA obligations extend downstream to anyone your vendor discloses PHI to.
None of this is unreasonable to ask a vendor before a contract is signed. If a vendor cannot produce a straight answer to any of the four, that is diagnostic information about the price you were quoted, not just about their security program. It is the same due-diligence posture we recommend before adopting any third-party AI tool that will touch business data, laid out in our guide to AI security for small businesses — evidence first, contract second, trust last.
This is the single highest-leverage negotiating point in the relationship, and most practices never touch it. The HIPAA Breach Notification Rule sets 60 days from discovery as the outer limit for a covered entity's notification to individuals and HHS, and business associates must notify the covered entity of a breach so that clock can start. The statute is a floor, not a target, and a floor written for the worst case is not something to inherit by default in your own contract.
A clause requiring your vendor to notify you within a fixed, short window of confirming a breach — rather than relying on the statutory outer bound — is something you negotiate before signing, while you still have leverage, not after an incident, when you have none. It would have mattered most in the UTS case: a shorter internal window does not stop a breach, but it compresses the gap between discovery and your ability to act, and that gap is where your exposure accumulates.
| Contract lever | What the statute alone gives you | What you should negotiate instead |
|---|---|---|
| Notification timing | Up to 60 days from discovery (outer limit) | A fixed, shorter internal notice window to your practice, in writing |
| Evidence of controls | Vendor self-attestation in the BAA | Independent audit or penetration test summary on request, annually |
| Data handling | General "appropriate safeguards" language | Named encryption-at-rest commitment and defined retention limits |
| Subcontractor visibility | Implicit pass-through obligation | A right to see your vendor's own subcontractor BAA list |
Most practices cannot answer this cleanly. A billing vendor is obvious. A scheduling platform, a fax-to-email service, and an answering service that logs callback reasons are less obvious, and each may qualify as a business associate under HIPAA, where the obligation attaches to the function, not to how central the vendor feels to your operations.
Building that inventory is a procurement exercise before it is a compliance one: list every vendor with system access or a data feed, mark which ones touch PHI, and confirm a current, specific BAA exists for each — not a boilerplate one signed once and never revisited as the vendor's product changed. The NIST Cybersecurity Framework 2.0's supply chain risk management category, GV.SC, frames this the same way: suppliers should be known and prioritized by criticality, with due diligence performed before the relationship starts rather than after something goes wrong. It is a governance standard that reads like ordinary vendor management once you strip out the framework language — the same discipline we walk through in our overview of cybersecurity and compliance obligations for SMBs.
This inventory work is also what a cyber insurance underwriter now expects documented before binding a policy. Our review of what underwriters actually require for cyber insurance readiness in 2026 covers the same vendor-mapping exercise from the insurance side, and both efforts should share one document, not two.
No, and the distinction is worth being precise about. Our companion piece, on what happens to your network if your IT provider's console is breached, covers an attacker gaining direct network access through a provider's remote management tooling — a foothold into your own environment, using the provider's credentials as the door.
The UTS case is a different mechanism entirely. Nobody gained access to your network. Your billing vendor held your patients' data in its own environment, and that environment was compromised. You never lost a byte from your own systems, and you still carry HIPAA notification exposure, because the obligation follows the data and the patient relationship, not the location of the breach. One is a network failure that becomes your problem because the provider sits inside your infrastructure; the other is a data custody failure that becomes your problem because HIPAA was written to make it yours regardless of custody. Both start with a vendor relationship. Neither is solved by the same fix.
This is the uncomfortable part of the argument, and it is the one I actually get paid to make: price differences between competing vendors in the same category are rarely differences in margin alone. They are frequently differences in what has and has not been funded internally — the audit never commissioned, the encryption deferred, the retention policy never enforced because deleting old records takes engineering time nobody budgeted for. Choosing a cheaper vendor without asking why does not avoid that cost. It accepts it later, on a timeline you do not control, as a breach notification instead of a line item.
Treating the BAA as the finish line of vendor selection, rather than the starting point for ongoing oversight, is how a paperwork exercise gets mistaken for protection. The HIPAA Security Rule requires covered entities and business associates alike to maintain administrative, physical, and technical safeguards for electronic PHI — it does not require you to take a vendor's word that they have. A signed BAA with no evidence behind it tells you the vendor agreed to obligations. It tells you nothing about whether they can meet them.
When we sit down with a practice's technology budget, vendor risk is treated as a line item with its own review cadence, not a one-time signature collected during onboarding. That means building the PHI vendor inventory before a renewal decision, reviewing what evidence of controls each vendor has actually produced versus promised, and pushing notification-timing language into contracts at renewal rather than accepting the vendor's standard paper. None of that requires switching vendors; it requires managing the relationship continuously rather than closing it once and filing it away — the same governance discipline we describe in our practical guide to AI governance for small and mid-sized businesses, applied to every vendor holding regulated data, not just the AI ones.
If you are also weighing whether that oversight belongs in-house or with an outside partner, our comparisons of MSP, MSSP, and vCISO models and of what to look for in a HIPAA-focused MSP walk through the same vetting questions raised here about business associates generally.
A breach at a vendor you have never met can still land on your practice's notification list, and the only real defense is deciding, before you sign anything, what evidence you require and what timeline you contractually demand.
If your team is moving faster with AI than your guardrails are, start with structured training rather than another tool. Securafy AI University gives your people role-based AI training with security built into the material, not bolted on afterward.
If you would rather talk through your specific environment first, book a strategy call with Securafy and we will walk your current AI usage, exposure, and the fastest path to safe adoption.