Your Business Associate Agreement is a legal document, not a security program
NIST CSF 2.0 → GOVERN → GV.SC: Cybersecurity Supply Chain Risk Management + GV.OV: Oversight
This post is part of a series on building a real cybersecurity program for telehealth practices. It builds on the foundational concepts in The Compliance Trap and Why HIPAA Compliance Isn’t Enough: A NIST CSF 2.0 Guide for Telehealth.
The BAA was signed. The SOC 2 report was “clean.” The vendor had a breach six weeks later — and the practice found out from a patient, not the vendor.
A mid-size telehealth practice had done everything by the book. They selected a vendor with a signed Business Associate Agreement. The vendor provided a SOC 2 report that looked comprehensive. The compliance officer filed both documents and moved on to the next item on the list.
What the practice didn’t know: the SOC 2 audit scope covered the vendor’s corporate email infrastructure and internal HR systems — not the telehealth platform the practice was actually using. And the BAA’s breach notification clause? It required notification within a “commercially reasonable” timeframe. When the vendor’s database was compromised through an unpatched API endpoint, “commercially reasonable” turned out to mean 47 days.
By the time the practice learned about the breach, it wasn’t from the vendor. It was from a patient who found their records listed on a dark web marketplace.
Day 0
Vendor’s API endpoint compromised through a known vulnerability that went unpatched for 90+ days.
Day 3
Attacker accesses production database. Begins exfiltrating patient records including names, diagnoses, and session notes.
Day 14
Vendor’s internal monitoring detects anomaly. Incident response team begins investigation. No external notification issued.
Day 28
Vendor confirms scope of breach. Legal team begins drafting notification language. Still no notice to affected practices.
Day 41
Patient data appears on dark web. A patient discovers their records and contacts the practice directly.
Day 47
Vendor sends formal breach notification to the practice — six days after patients already knew.
Day 48+
Practice scrambles to notify 12,000 patients, engage legal counsel, file with HHS, and manage media inquiries — all while trying to maintain patient care.
Most practice administrators treat a signed BAA as proof that a vendor will protect their data. It isn’t. A BAA is a legal contract that establishes regulatory obligations under HIPAA. It defines who is liable after a breach occurs. It does nothing — absolutely nothing — to prevent one.
The gap between these two columns is where practices get hurt. A BAA is a necessary legal instrument, but it is not a security assessment, not a penetration test, and not evidence that the vendor has any meaningful security controls in place. It is a promise to follow the rules — and promises don’t stop attackers.
If a BAA tells you who is liable, the following artifacts tell you whether a breach is likely to happen in the first place. These are the documents you should request — and scrutinize — before entrusting any vendor with your patients’ data.
What it is: An independent audit of a vendor’s security controls, conducted over a period of time (typically 6–12 months). Unlike a SOC 2 Type I, which only confirms controls exist at a point in time, a Type II report verifies that those controls were consistently operating throughout the audit period.
What to check: The scope. A SOC 2 report is only meaningful if it covers the specific services you use. A vendor’s SOC 2 might cover their internal corporate systems while the telehealth platform you rely on sits outside the audit boundary entirely.
Red flags:
Why you should request it: A penetration test reveals whether a vendor’s defenses actually work against simulated attacks. The executive summary provides findings without disclosing sensitive technical details the vendor rightfully protects.
What to look for: Scope of the engagement (did it include the platform you use?), severity of findings, and whether critical vulnerabilities were remediated. Look for the difference between an automated vulnerability scan and a genuine penetration test — automated scans check for known issues; real pen tests simulate attacker behavior including chained exploits, privilege escalation, and lateral movement.
Red flags: Vendor refuses to share even an executive summary. Vendor conflates automated scanning with penetration testing. Last test was conducted more than 12 months ago.
What it demonstrates: A mature vendor maintains a formal vulnerability management program with defined SLAs for patching based on severity. This includes regular scanning, prioritization of findings, and documented remediation timelines.
What to ask: What is your patch cadence for critical vulnerabilities? How do you track known vulnerabilities (e.g., CISA KEV catalog)? What is your SLA for applying critical patches?
Why it matters: The vendor breach in our opening scenario exploited a vulnerability that had been publicly known for over 90 days. A vendor with a 72-hour critical patching SLA would have closed that gap months before the attacker arrived.
What you need: A specific, contractually binding notification timeline measured in hours — not “commercially reasonable,” not “without unreasonable delay,” not “as soon as practicable.” These phrases are legally meaningless in practice and give vendors cover to delay notification for weeks.
What to demand: Initial notification within 24–48 hours of confirmed incident, with a preliminary impact assessment within 72 hours. Your patients, your regulators, and your reputation cannot wait 47 days.
The standard: Vendors who take security seriously will commit to specific timelines. Vendors who resist are telling you something about how they’ll behave when things go wrong.
Here is a fact that most practice administrators have never considered: your telehealth vendor almost certainly does not operate in isolation. Behind the platform you see is a chain of sub-processors — third-party services that handle critical functions on the vendor’s behalf.
A typical telehealth platform relies on:
Your BAA is with the primary vendor. It is not with AWS. It is not with the AI transcription service processing your clinical conversations. It is not with the analytics platform tracking session metadata. Each of these sub-processors introduces risk that your primary vendor agreement may not adequately address.
What to ask: Request a complete sub-processor list. Ask what PHI each sub-processor accesses. Ask whether each sub-processor has signed a BAA with the primary vendor. Ask what security assurances the vendor has obtained from each sub-processor. If the vendor cannot answer these questions, they have not done their own due diligence — and you are inheriting their risk.
The following questions are designed to be asked during vendor evaluation, contract renewal, or periodic reassessment. They separate vendors who invest in security from those who merely present the appearance of it.
| # | Question | Why It Matters |
|---|---|---|
| 1 | Can you provide a SOC 2 Type II report scoped to the services we use? | Ensures the audit covers your actual risk, not just the vendor’s marketing claims. A SOC 2 that doesn’t cover your platform is meaningless. |
| 2 | What is your breach notification SLA in hours, not “commercially reasonable”? | Vague SLAs mean delayed notification — every hour matters for patient trust and regulatory compliance. Demand a specific number. |
| 3 | Who are your sub-processors, and what PHI do they access? | Your vendor’s vendors are part of your risk surface. You cannot manage risk you cannot see. |
| 4 | Can you provide a penetration test executive summary from the last 12 months? | Shows they test defenses, not just document them. A vendor who has never been pen tested is a vendor who does not know their own vulnerabilities. |
| 5 | What is your critical vulnerability patching SLA? | Unpatched systems are the #1 entry point for attackers. A defined patching SLA (e.g., critical within 72 hours) is a baseline expectation. |
| 6 | How is PHI encrypted in transit and at rest? What key management do you use? | Encryption details matter — “we use encryption” is not an answer. You need to know the algorithm, key length, and who controls the keys. |
| 7 | What access controls and audit logging exist for our data? | You need to know who at the vendor can see your patients’ data and whether those access events are logged and reviewable. |
| 8 | What is your incident response plan, and when was it last tested? | A plan that has never been tested is a plan that will fail. Ask for the date of the last tabletop exercise or IR drill. |
| 9 | How do you handle data retention and deletion upon contract termination? | PHI must be returned or destroyed — not retained indefinitely in backup systems the vendor “forgot” to purge. |
| 10 | Do you support MFA and SSO integration for our users? | Your identity controls should extend to vendor platforms. If the vendor doesn’t support MFA or SSO, your credentials are only as strong as a password. |
| 11 | What is your uptime SLA and disaster recovery capability? | If the vendor goes down during clinic hours, can you still see patients? Understand the RTO, RPO, and failover architecture. |
| 12 | Will you allow us (or our auditor) to assess your security controls? | Vendors who refuse independent assessment may have something to hide. The right to audit is a standard clause in mature vendor agreements. |
How to use this table: A vendor who can answer all 12 questions with specifics — not vague assurances — is a vendor who has invested in security. A vendor who deflects, delays, or refuses to answer is a vendor whose risk you will be carrying on your practice’s balance sheet.
Do you have a formal vendor risk assessment process that goes beyond collecting a BAA and a SOC 2 cover page?
Can you identify every sub-processor that has access to your patients’ PHI through your telehealth vendor?
Does your telehealth vendor’s breach notification SLA specify a timeline in hours, not vague language like “commercially reasonable”?
Have you reviewed your telehealth vendor’s SOC 2 Type II report to confirm the audit scope covers the services your practice actually uses?
Do you reassess your telehealth vendor’s security posture on at least an annual basis, rather than treating initial due diligence as a one-time exercise?
If your primary telehealth vendor experienced a catastrophic failure today, do you have a documented contingency plan for maintaining patient care?
If you hesitated on any of these, the gap between your vendor risk management program and the threat landscape is wider than your BAA can cover.
A signed BAA is the starting line, not the finish line. Know what your vendors are actually doing with your patients’ data.
A comprehensive review of your telehealth vendor ecosystem: BAA gap analysis, sub-processor mapping, breach notification SLA evaluation, and a prioritized action plan for closing the gaps that put your practice at risk.
Hudson Valley CISO
A Division of Security Medic Consulting
Fractional CISO Services | Healthcare Security | Telehealth Compliance