Vendor Security Assessments & BAAs: A Home Health Guide

Every home health agency has a list of vendors longer than it probably realizes once you actually count them: the EHR, the billing company, the scheduling software, the e-fax service, the payroll processor, the background-check vendor, maybe a staffing agency. Any vendor that creates, receives, maintains, or transmits PHI on the agency's behalf is a business associate under HIPAA, and every one of them needs a signed Business Associate Agreement — not as a formality, but because the agreement is what actually obligates the vendor to protect patient data and tells the agency what happens if that vendor has a breach.

Most agencies have BAAs on file for the obvious vendors. Fewer have actually read what those BAAs say, and fewer still have a repeatable process for assessing a vendor's security before signing anything in the first place.

What a BAA Must Actually Include

HIPAA's Business Associate Contract requirements (45 CFR § 164.504(e)) specify what has to be in the agreement, not just that an agreement has to exist. A compliant BAA needs to:

• Define permitted uses and disclosures. The agreement must describe what the vendor is allowed to do with the PHI it receives, and limit it to what's needed to perform the contracted service — not an open-ended license to use patient data however the vendor sees fit.
• Require appropriate safeguards. The vendor must agree to implement administrative, physical, and technical safeguards consistent with the Security Rule to protect any electronic PHI it handles.
• Flow down to subcontractors. If the vendor uses its own subcontractors who will also touch the PHI, the vendor must obtain the same BAA-equivalent commitments from those subcontractors — a BAA that doesn't address this leaves a hole for PHI to pass through an unaccountable fourth party.
• Require breach notification. The vendor must agree to report any breach of unsecured PHI to the agency, generally without unreasonable delay — this is the provision that actually matters when something goes wrong, since the agency's own 60-day HHS notification clock often depends on when the vendor tells it about an incident.
• Require return or destruction of PHI at termination. When the relationship ends, the vendor must return or destroy any PHI still in its possession, or explain why that's infeasible and continue protecting it under the same terms.
• Preserve the agency's HIPAA rights. The agreement must make clear that the vendor's obligations don't override an individual's rights to access, amend, or receive an accounting of disclosures regarding their own PHI.
• Allow termination for violation. The agency needs the contractual right to terminate the relationship if the vendor violates a material term of the agreement, not just a vague mutual-termination clause buried in boilerplate.

A signed document that's missing one or more of these elements isn't a fully compliant BAA, even if both parties call it one and both believe they're covered.

Red Flags in Vendor Contracts

A few patterns show up repeatedly in vendor agreements that look fine on the surface but create real exposure:

• No BAA offered at all. A vendor that handles anything resembling PHI but doesn't have a standard BAA process, or treats the request as unusual, is signaling that handling healthcare data isn't something they've built their compliance program around.
• A BAA that doesn't name the actual product being used. Some larger vendors offer a BAA that covers only specific services or tiers of their platform — if the agreement doesn't explicitly list the product your agency is actually using, you may not be covered for it regardless of the BAA's existence.
• Vague or missing subcontractor language. If the vendor relies on cloud infrastructure, support contractors, or other downstream providers and the BAA doesn't address how those parties are bound, PHI may be flowing to an entity with no contractual obligation to protect it at all.
• Breach notification timelines left undefined. "Will notify as required by law" sounds reasonable but provides no actual commitment on timing — a vendor that won't commit to a specific notification window (ideally well inside the agency's own 60-day HHS deadline) is pushing risk back onto the agency.
• No audit or inspection rights. A BAA that gives the agency no way to verify the vendor's security practices, even informally, means the agency is taking the vendor's compliance entirely on faith.
• Liability caps that undercut the relationship's real risk. A vendor contract that caps the vendor's liability for a breach at a token amount — far below what a PHI breach actually costs an agency in notification, remediation, and reputational damage — shifts nearly all of the financial risk back onto the agency despite the vendor being the one that lost the data.

A 10-Question Vendor Security Assessment Template

Before signing with a new vendor that will touch PHI — or when reviewing an existing one — these ten questions provide a baseline assessment that takes most vendors under an hour to answer and surfaces the issues above directly:

1. Will you sign a Business Associate Agreement covering the specific product or service we're using?
2. Do you encrypt PHI at rest and in transit, and what encryption standard do you use?
3. Do you require multi-factor authentication for accounts with access to our data?
4. What subcontractors or cloud infrastructure providers will have access to our PHI, and are they bound by equivalent agreements?
5. What is your committed timeline for notifying us of a security incident or breach involving our data?
6. Do you carry cyber liability insurance, and at what coverage level?
7. Have you had a third-party security audit or penetration test in the last 12 months, and can you share a summary?
8. What happens to our data if we terminate the relationship — is it returned, destroyed, or retained, and under what terms?
9. Who at your organization has access to our PHI, and how is that access limited and reviewed?
10. Have you experienced a data breach in the past three years, and if so, what changed as a result?

A vendor that answers these directly and specifically is behaving like an organization that takes the question seriously. A vendor that deflects, provides only marketing language, or can't produce a BAA at all is a vendor worth reconsidering regardless of how good the product itself is.

Handling Specific Vendor Categories

EHR vendors are usually the most mature here — Homecare Homebase, WellSky, MatrixCare, Axxess, and Brightree all have established BAA processes, since PHI is the core of their product. The risk with EHR vendors is less about whether a BAA exists and more about whether the agency has actually read what it covers, particularly around mobile app behavior, offline data caching, and any third-party integrations the EHR connects to that might not be covered under the same agreement.

Billing companies handle PHI alongside financial data, which raises the stakes on their BAA specifically addressing subcontractors — billing is an area where outsourcing to a sub-processor is common, and that chain needs to be covered end to end, not just at the first link.

Scheduling software is the category most likely to get treated as low-risk when it shouldn't be — a scheduling tool handling patient names, addresses, and visit types is handling PHI, even if nobody thinks of a calendar app as a clinical system. The same BAA requirement applies regardless of how the tool is categorized internally.

Why This Matters Beyond the Contract Itself

A thorough vendor assessment isn't just a compliance exercise — it's also where an agency finds out, before a contract is signed, whether a vendor's security posture matches what the sales conversation implied. A vendor that can't answer the ten questions above specifically is often a vendor that hasn't thought carefully about security at all, which tends to show up later as the vendor that gets breached, that can't tell you how it happened, and that notifies you weeks after the fact rather than within the committed window the BAA was supposed to guarantee. The cost of an hour spent on this assessment before signing is small compared to the cost of discovering the gap after a vendor's breach becomes the agency's breach notification obligation.

Keeping Track of What You've Already Signed

None of this works as a one-time exercise. A vendor assessed and approved two years ago may have changed ownership, changed products, or quietly dropped a security practice the agency assumed was still in place. A simple vendor inventory — every vendor touching PHI, whether a BAA is on file, when it was last reviewed, and what the assessment found — turns this from a one-time gate into an actual ongoing program, which is also exactly the kind of documentation an OCR investigation or a cyber insurance renewal will ask to see.

ShieldForce maintains this vendor and BAA inventory as part of the complete home health cybersecurity platform we manage for agencies, flagging vendors that are overdue for review and surfacing gaps before they become findings in an audit. For the complete HIPAA Security Rule mapping beyond vendor management specifically, see our home health cybersecurity guide.

Frequently Asked Questions

What must a HIPAA Business Associate Agreement include?

A compliant BAA must define permitted uses and disclosures of PHI, require the vendor to implement appropriate safeguards, flow those same obligations down to any subcontractors, require breach notification to the agency, require return or destruction of PHI at the end of the relationship, preserve individuals' HIPAA rights, and give the agency the right to terminate for a material violation. A signed agreement missing any of these elements isn't a fully compliant BAA.

Does a scheduling or billing tool really need a BAA, or just the EHR?

Any vendor that creates, receives, maintains, or transmits PHI on the agency's behalf needs a BAA, regardless of how central or peripheral the tool seems. Scheduling software handling patient names and visit details, and billing platforms handling claims data, are both handling PHI and both need their own signed agreement.

What's the biggest red flag when reviewing a vendor contract?

A vendor that can't produce a clear, specific BAA covering the exact product your agency uses — or that treats the request as unusual — is signaling that handling PHI responsibly isn't built into how they operate. Vague subcontractor language and undefined breach notification timelines are close behind, since both push risk back onto the agency without the agency realizing it until something goes wrong.

How often should vendor security assessments be redone?

At least annually, and whenever a vendor changes ownership, changes the product your agency actually uses, or reports any security incident, even a minor one. A vendor assessed once at signing and never revisited is effectively being assessed on information that may be years out of date.

Who should be responsible for maintaining the vendor and BAA inventory?

A single named role, typically whoever holds compliance responsibility at the agency, should own the inventory and be accountable for knowing which vendors are covered, when each BAA was last reviewed, and what gaps exist. Without a single owner, this tends to fall through the cracks between whoever originally onboarded each vendor.