Most Arizona practices treat "HIPAA compliance" as a single annual task: run the security risk assessment, file the report, move on. But the HIPAA Security Rule creates two related and frequently confused obligations. The first is the broad annual security risk assessment (SRA) required under 45 CFR § 164.308(a)(1)(ii)(A), which scans every system touching electronic protected health information (ePHI) inside the practice. The second is narrower and easier to skip entirely: assessing the vendors — the EHR platform, the billing company, the IT provider, the cloud host — that create, receive, maintain, or transmit that same data on the practice’s behalf. A signed contract with a vendor is not evidence that either obligation has been met.
For a practice with one to twenty employees, this distinction usually surfaces at the worst possible time: during an Office for Civil Rights (OCR) inquiry, a payer credentialing audit, or a breach notification deadline, when someone asks for the vendor risk documentation and the practice has only ever produced its internal SRA.
What the Annual SRA Actually Covers — and What It Doesn’t
The annual SRA under 45 CFR § 164.308(a)(1)(ii)(A) is deliberately broad. It identifies risks and vulnerabilities to all ePHI the practice creates, receives, maintains, or transmits, across internal systems, workstations, physical access, and administrative procedures. It should be refreshed at least annually and again after any significant change — a new EHR, a new location, a new vendor relationship, or a security incident.
What the annual SRA does not automatically do is verify that a specific vendor’s own safeguards are adequate. A practice can complete a thorough internal SRA and still have zero documented evidence that its billing company encrypts data at rest, that its IT contractor limits administrative access, or that its cloud host has ever been independently audited. That gap is the vendor risk assessment.
Vendor Risk Assessment: A Narrower, Contract-Adjacent Obligation
A vendor (or business associate) risk assessment is not a separate line item in the regulation the way the annual SRA is — it’s the part of the practice’s overall risk analysis that specifically accounts for third parties. In practice, regulators expect a covered entity to be able to answer three questions for every vendor that touches PHI: where does the data leave the practice’s environment, which vendor holds it, and what happens if that vendor is breached.
Answering those questions takes more than a signed agreement. It means collecting actual evidence of the vendor’s security posture — audit reports such as SOC 2 or HITRUST certification where available, completed security questionnaires, documented encryption practices, access control policies, and a record of how the vendor has handled past incidents. This review is meant to happen before a Business Associate Agreement (BAA) is signed, and again periodically afterward, since a vendor’s certifications and environment change over time even when the contract language doesn’t.
What a Business Associate Agreement Has to Cover
The BAA itself sits on a wider regulatory foundation than most practices assume — 45 CFR §§ 164.308, 164.314, 164.502, and 164.504 span the Security Rule, Privacy Rule, and Breach Notification Rule together, not just one section. A BAA that only restates "the vendor will keep data safe" is not doing the job the regulation assigns it. At minimum, it needs to specify:
- The permitted and required uses and disclosures of PHI by the vendor
- Administrative, physical, and technical safeguards consistent with the Security Rule
- A defined breach and security-incident reporting timeline back to the practice
- An obligation to mitigate harm from any violation of the agreement
- Flow-down terms binding any subcontractor the vendor uses to the same restrictions (45 CFR § 164.504(e)(1)(ii)(A)–(B))
- Return or destruction of PHI when the relationship ends
A vendor that resists putting any of these terms in writing is telling a practice something about how it will handle a breach long before one ever happens.
Which Vendors Actually Need This Treatment
The regulatory expectation applies to any vendor that creates, receives, maintains, or transmits PHI on the practice’s behalf — which is a wider list than most administrators initially assume:
| Vendor Category | Why It’s In Scope |
|---|---|
| EHR platform | Typically holds the largest volume of PHI of any vendor; the most consequential BAA a practice signs |
| Medical billing / RCM company | Handles claims data combining clinical and financial PHI |
| IT support or managed service provider | Has system access even when engagements are limited to maintenance or troubleshooting |
| Cloud hosting or storage provider | Stores ePHI outside the practice’s own infrastructure |
| Transcription, fax-to-email, and document scanning services | Frequently overlooked because the interaction feels administrative, not clinical |
Missing a BAA with any vendor on this list — including the EHR vendor itself — is treated as a HIPAA violation on its own, independent of whether a breach ever occurs.
Why This Gap Shows Up in Enforcement
OCR’s ongoing Risk Analysis Initiative has produced a consistent pattern in settlements: the most commonly cited deficiency is the failure to conduct or maintain a written risk analysis under 45 CFR 164.308(a)(1)(ii)(A) — and small practices are not exempt. Settlements have regularly involved practices with fewer than twenty employees. Separately, state-level enforcement has also moved on third-party breach exposure; in one recent case a New York orthopedic practice settled for $500,000 following violations tied to third-party handling of patient data, a reminder that the practice, not the vendor, carries ultimate accountability for patient and OCR notification even when a breach originates entirely on the vendor’s side.
For a growing share of breaches, the entry point is a vendor, not the practice’s own network. A documented vendor risk assessment doesn’t eliminate that exposure, but it is the piece of evidence that demonstrates the practice met its obligation to evaluate the vendor before handing over access — and it’s the piece most practices discover is missing only after someone asks for it.
Building the Habit Into Vendor Selection
The practical fix is sequencing. A vendor risk review belongs before a contract is signed, not after: request the vendor’s most recent audit report or security questionnaire, confirm the BAA covers all six elements above, and set a recurring reminder to re-check certifications annually alongside the practice’s broader SRA refresh. For practices evaluating EHR, billing, IT, or hosting vendors for the first time, treating that evaluation as a distinct, documented step — separate from price and feature comparisons — is what closes the gap between having a vendor contract and having a compliant one.