When American Addiction Centers (AAC) disclosed their second data breach in two years, this time through a Business Associate's Salesforce environment, the incident report contained a telling detail: "the incident didn't involve any direct access to [AAC's] system, network, or health records application." In other words, they were breached through someone else's security gap.
These myths persist because vendor management feels like someone else's problem until it becomes yours. You sign a Business Associate Agreement (BAA), check a compliance box, and move on. But AAC's $2.75 million settlement from their 2024 breach, which affected 410,747 individuals, proves that courts and regulators don't care whose server got compromised, they care whose patients got exposed.
Let's dismantle the vendor security myths that turn Business Associates into compliance liabilities.
Myth 1: The BAA Makes You Compliant
Reality: A signed BAA establishes legal obligations, not technical security.
The HIPAA Security Rule § 164.308(b)(1) requires you to obtain "satisfactory assurances" that your Business Associate will safeguard ePHI, typically through a BAA. But that contract is just the starting point. When AAC's vendor environment was breached on May 12, 2026, that BAA didn't prevent the exposure of names, Social Security numbers, contact information, and patient health descriptions.
Your BAA should require specific security controls like encryption standards, access logging, and incident notification timelines. You need to verify those controls exist. Request SOC 2 Type II reports, HITRUST CSF certifications, or penetration test summaries annually. If your vendor balks at sharing evidence of their security posture, you're working with the wrong vendor.
Myth 2: You're Only Responsible for Your Own Systems
Reality: Under HIPAA's Omnibus Rule, Covered Entities remain directly liable for their Business Associates' failures.
The OCR has repeatedly held Covered Entities accountable when their vendors cause breaches. You can't outsource compliance risk even when you outsource the technical work. AAC learned this twice: their 2024 breach led to 12 consolidated lawsuits despite the attack originating outside their direct control.
The Security Rule's § 164.314(a)(2)(i) and (ii) require you to document how you evaluated each Business Associate's security capabilities and maintain evidence of that due diligence. When OCR investigates, they'll ask what you knew about your vendor's security practices before the breach, not just what your contract said.
Myth 3: Annual Vendor Reviews Are Sufficient
Reality: Risk changes faster than your review cycle.
Consider AAC's timeline: their 2024 breach was allegedly perpetrated by Rhysida, a ransomware group that only emerged in 2023. If you assessed that vendor in early 2023, your risk profile was obsolete within months. By the time AAC faced their second incident in 2026, the threat landscape had evolved twice over.
Implement continuous monitoring instead of point-in-time assessments. Set up automated alerts for vendor security incidents; many now appear in public breach databases. Require quarterly attestations that no material security changes have occurred. For critical vendors handling large ePHI volumes, schedule semi-annual security reviews, not annual ones.
Myth 4: Cloud Platforms Are Inherently Secure
Reality: Shared responsibility models mean you own the configuration layer.
AAC's breach occurred in their Salesforce environment, a platform that can be HIPAA compliant when properly configured and integrated. The key phrase is "when properly configured." Cloud platforms provide secure infrastructure, but you're responsible for access controls, encryption settings, and integration security.
Salesforce won't automatically encrypt patient communications or restrict data exports to authorized users. You configure those controls. When you integrate a cloud platform with other systems (email, analytics, marketing automation), each integration point creates a new attack surface. Map every data flow involving ePHI, document the security controls at each handoff, and test those controls before going live.
Myth 5: Vendor Security Is an IT Problem
Reality: Vendor risk management requires coordination across compliance, legal, IT, and operations.
Your IT team can assess technical controls, but they can't evaluate contractual liability terms or operational dependencies. Your legal team can draft indemnification clauses, but they can't verify encryption implementations. Your compliance officer can identify regulatory requirements, but they can't configure firewall rules.
Create a vendor risk committee that meets quarterly to review high-risk Business Associates. Include your Privacy Official, IT security lead, legal counsel, and operational stakeholders who use the vendor's services. This group should review incident reports, assess whether your response protocols worked, and update vendor requirements based on lessons learned.
What to Do Instead
Start with a tiered vendor classification system. Not every Business Associate poses equal risk. A vendor that stores full medical records demands more scrutiny than one that processes appointment reminders with Limited Data Sets.
For high-risk vendors (those with access to large ePHI volumes or sensitive data like substance abuse records), require:
Before contract signature: Evidence of current HITRUST CSF certification or SOC 2 Type II report with security controls tested within the past 12 months. Request their incident response plan and breach notification procedures.
During onboarding: Technical security assessment of the specific environment that will process your ePHI. Don't accept generic security documentation, review the actual configuration.
Ongoing: Quarterly security questionnaires, annual penetration test summaries, and immediate notification of any security incidents affecting their infrastructure (not just confirmed breaches of your data).
After incidents: Conduct joint post-mortems. When AAC contained their incident and initiated an investigation, that process should have included their vendor's security team, not just internal staff.
Document everything. When OCR asks what "satisfactory assurances" you obtained, your answer needs to be more detailed than "we have a signed BAA." Show the security reports you reviewed, the questions you asked, the deficiencies you identified, and the remediation you required.
AAC's experience demonstrates that treatment centers and other healthcare providers face real financial consequences when vendor security fails. Their $2.75 million settlement didn't account for legal fees, security improvements, or the operational impact of reduced services following financial strain. But those costs were predictable and potentially preventable with rigorous vendor management.
Your data is only as secure as your least-secure Business Associate. Stop treating vendor risk as a contract problem and start treating it as an ongoing compliance obligation.
