What Is a Business Associate Agreement? A HIPAA Guide

What Is a Business Associate Agreement? A HIPAA Guide

A Business Associate Agreement (BAA) is a written contract between a HIPAA covered entity and a vendor that creates, receives, maintains, or transmits protected health information (PHI) on the covered entity's behalf. Under the HIPAA Privacy Rule, covered entities must obtain satisfactory written assurances from any such vendor before PHI changes hands. If you work with a billing company, a cloud EHR host, or a transcription service, you need a signed BAA in place before that vendor touches patient data. The HHS sample BAA provisions provide the canonical checklist for required clauses and are the best starting point for drafting or auditing your own agreements.

The stakes are concrete. Vendors with their own subcontractors must flow down equivalent obligations, meaning the BAA chain extends beyond your direct vendor to anyone that subcontractor engages to handle PHI. A gap anywhere in that chain is a compliance exposure for your practice.

Table of Contents

• What is a business associate under HIPAA?
• When is a BAA required, and what are the edge cases?
• What provisions must a compliant BAA include?
• Who is responsible for what under a BAA?
• What happens when PHI is breached?
• Common BAA failures and OCR enforcement patterns
• How to evaluate vendors, negotiate BAAs, and implement safeguards
• Where to find HHS/OCR sample BAAs and authoritative resources
• Key Takeaways
• Why most BAA problems are really IT problems in disguise
• Greatplainsnetworking helps small practices meet BAA safeguard requirements
• Useful sources and further reading

What is a business associate under HIPAA?

The regulatory definition is precise: a business associate (BA) is a person or entity that, on behalf of a covered entity, performs functions or activities involving the use or disclosure of PHI. The key phrase is "on behalf of." A vendor that simply delivers mail or cleans your office does not qualify. A vendor that processes, analyzes, or stores patient records does.

Common business associate examples

• Medical billing companies that process claims containing patient diagnoses and insurance data
• Cloud EHR and practice management software vendors that host electronic PHI on their servers
• Transcription services that receive and process recorded patient encounters
• Health information exchange organizations and e-prescribing gateways with routine PHI access
• Analytics and data aggregation vendors that analyze patient populations for quality reporting
• Email encryption or secure messaging providers with routine access to PHI in transit
• IT managed service providers that remotely access systems storing ePHI (more on this below)
• Legal, accounting, or consulting firms whose services require reviewing patient records

Who is NOT a business associate

Classification depends entirely on function and relationship, not on whether PHI is physically nearby. A courier who delivers sealed lab specimens has incidental contact with PHI but does not use or disclose it on the covered entity's behalf. A janitorial service with no routine access to records does not qualify. Treating physicians who receive PHI for treatment purposes are also excluded from the BA definition under 45 CFR § 160.103.

Pro Tip: Run this three-question test for any vendor: (1) Does the vendor create, receive, maintain, or transmit PHI? (2) Does the vendor perform that function on behalf of your practice, not just incidentally? (3) Is the vendor outside your workforce? Three "yes" answers mean you need a BAA.

The subcontractor flow-down requirement

When a BA engages a subcontractor to perform any function involving PHI, that subcontractor becomes a sub-BA and must enter an equivalent agreement with the primary BA. This flow-down obligation is explicit in 45 CFR § 164.504(e)(2)(ii)(D). Missing sub-BA agreements are one of the most common compliance gaps practices discover during audits.

When is a BAA required, and what are the edge cases?

Use this sequential decision process when evaluating any new vendor relationship:

1. Does the vendor create, receive, maintain, or transmit PHI? If no PHI is involved at any stage, no BAA is needed. If yes, continue.
2. Is the vendor performing that function on behalf of your practice? Incidental exposure (a vendor who might see a sticky note) is different from a vendor whose service requires PHI access. If yes, continue.
3. Is the vendor a member of your workforce? Employees and volunteers under your direct control are covered by your HIPAA policies, not a BAA. If the vendor is external, continue.
4. Does an exception apply? Treating providers, plan sponsors under specific conditions, and certain government agencies are excluded by regulation. If no exception applies, a BAA is required.

Edge cases worth knowing

Remote IT support: An IT provider that can access servers or workstations storing ePHI qualifies as a BA. Even if the provider never intentionally views patient records, the technical capability to access them triggers the requirement. This is why managed IT providers serving dental and medical practices routinely sign BAAs as part of their service agreements.

Cloud backup services: Any cloud storage or backup vendor that maintains ePHI on your behalf needs a BAA, even if the data is encrypted. HHS has confirmed this position for cloud service providers.

Marketing vendors: A vendor that receives a patient list to send appointment reminders is handling PHI and likely qualifies as a BA. A vendor that only receives de-identified data does not.

Business partners exchanging lists: If two covered entities share PHI for treatment, payment, or health care operations, a BAA is not required between them. But if a covered entity shares PHI with a non-covered entity for operational purposes, the analysis returns to the four-step test above.

When the arrangement involves cross-border data storage, complex subcontracting chains, or novel data-sharing structures, escalate to legal counsel before proceeding.

What provisions must a compliant BAA include?

The mandatory elements are codified at 45 CFR § 164.504(e). HHS also publishes a model BAA that translates these requirements into contract language. A compliant BAA must address all of the following:

1. Permitted and required uses and disclosures. The contract must specify exactly what the BA may do with PHI. Uses beyond those listed are prohibited unless required by law.
2. Prohibition on unauthorized use or further disclosure. The BA may not use or disclose PHI in any way that would violate HIPAA if the covered entity did the same thing.
3. Appropriate safeguards. The BA must use safeguards to prevent unauthorized use or disclosure. For electronic PHI, the BA must comply with the HIPAA Security Rule (Subpart C of 45 CFR Part 164).
4. Breach and unauthorized disclosure reporting. The BA must report any use or disclosure not permitted by the contract, including breaches of unsecured PHI under 45 CFR § 164.410.
5. Subcontractor flow-down. The BA must require any subcontractor that creates, receives, maintains, or transmits PHI to agree to the same restrictions.
6. Individual rights support. The BA must make PHI available for patient access, amendment, and accounting of disclosures as required by the Privacy Rule.
7. HHS access to books and records. The BA must make its internal practices, books, and records available to HHS for compliance determinations.
8. Termination provisions. The covered entity may terminate the contract if the BA materially breaches its obligations and cannot cure the breach.
9. Return or destruction of PHI at termination. At contract end, the BA must return or destroy all PHI. If return or destruction is not feasible, the BA must extend the contract's protections indefinitely.
10. Covered entity obligation pass-through. If the BA is carrying out a covered entity's HIPAA obligation, the BA must comply with the same requirements that apply to the covered entity for that obligation.

Mapping clauses to operational controls

Each clause implies a specific technical or administrative control. The safeguards clause (item 3) maps directly to encryption of ePHI at rest and in transit, access logging, and multi-factor authentication. The breach reporting clause (item 4) requires the BA to have an incident detection and response process. The return/destruction clause (item 9) requires documented data retention and secure deletion procedures. Reviewing backup and recovery practices against this clause is a practical starting point for small practices.

Legal practitioners recommend auditing BAAs against HHS model provisions rather than relying on generic templates, particularly as digital-health services and complex subcontracting chains expand the PHI risk surface.

Who is responsible for what under a BAA?

Covered entity responsibilities

• Select vendors carefully and verify that BAA language meets the requirements of 45 CFR § 164.504(e) before PHI is shared.
• Include all required provisions; a BAA that omits mandatory clauses puts the covered entity out of compliance regardless of what the BA does.
• Monitor for known material breaches. The covered entity is not required to audit the BA's day-to-day operations, but it must act when it becomes aware of a pattern of violations.
• Take reasonable steps to cure a material breach. If cure fails and termination is feasible, terminate the contract. If termination is not feasible, report the problem to HHS OCR.

Business associate responsibilities

• Implement the technical, physical, and administrative safeguards required by the Security Rule for ePHI.
• Report breaches and unauthorized disclosures to the covered entity without unreasonable delay.
• Enter sub-BA agreements with any subcontractor that touches PHI.
• Comply directly with certain HIPAA provisions under the HITECH Act and the 2013 OCR final rule.

HITECH direct liability

Since the HITECH Act (2009) and the 2013 OCR final rule, business associates carry direct liability for certain HIPAA requirements. OCR can investigate and fine a BA directly for failures such as not providing patients with electronic copies of their ePHI, failing to enter sub-BA agreements, or violating the minimum-necessary standard. This is a meaningful shift: a BA can no longer treat HIPAA obligations as purely contractual duties owed to the covered entity. They are enforceable regulatory obligations.

Responsibility summary

What happens when PHI is breached?

Core contractual obligations

The BAA must require the BA to report any unauthorized use or disclosure to the covered entity without unreasonable delay. The covered entity then determines whether the incident meets the definition of a reportable breach and handles OCR notification when required.

What the BA must include in its report to the covered entity

• The date the breach was discovered and, if known, the date it occurred
• A description of the PHI involved (types of identifiers, number of individuals affected)
• The identity of the unauthorized person who used or received the PHI, if known
• Whether the PHI was actually acquired or viewed
• Steps the BA has taken or plans to take to mitigate harm and prevent recurrence

Pro Tip: When a potential breach is discovered, the BA should immediately isolate affected systems, preserve logs and forensic evidence, and document every action taken. Delaying containment to assess scope first is a common mistake that widens the impact and complicates the OCR investigation.

Common BAA failures and OCR enforcement patterns

Most BAA compliance failures fall into a predictable set of categories. Knowing them in advance is the fastest way to reduce your exposure.

• Relying on a signed BAA as a compliance endpoint. A signed agreement does not equal operational compliance. The BA must actually implement the Security Rule's controls. OCR investigations routinely find that a BAA existed but the promised safeguards were never deployed.
• Missing subcontractor BAAs. Primary BAs frequently overlook the obligation to execute agreements with their own subcontractors. Sub-BA chain failures are a frequent blind spot, and OCR has cited this gap in enforcement actions.
• Incomplete or outdated BAA clauses. Generic BAA templates often predate the 2013 final rule and omit HITECH-required provisions. Practices that have not updated their agreements since 2013 are likely out of compliance on specific clauses.
• Failure to document risk assessments. OCR expects covered entities and BAs to maintain documented Security Rule risk assessments. Absence of documentation is itself a finding, independent of whether a breach occurred.
• No termination or cure process. Covered entities that discover a BA violation and take no documented action are in violation of 45 CFR § 164.504(e)(1)(ii).

OCR enforcement actions have targeted both covered entities and business associates directly. Settlements have resulted from failures including lack of BAAs with IT vendors, inadequate ePHI access controls, and missing breach notification procedures. The AAP's guidance on vendor classification reinforces that classification errors, treating a BA as a non-BA, are a root cause of many enforcement exposures.

Pro Tip: Keep a BAA inventory spreadsheet that lists every vendor, the BAA execution date, the next review date, and the specific PHI functions covered. OCR auditors ask for this document early in any investigation. Having it ready demonstrates a culture of documented compliance.

How to evaluate vendors, negotiate BAAs, and implement safeguards

Vendor evaluation checklist

Before signing a BAA, verify the following with each vendor:

• Does the vendor have a documented Security Rule risk analysis?
• What encryption standards does the vendor apply to ePHI at rest and in transit?
• Does the vendor maintain access logs and audit trails for PHI access?
• What is the vendor's incident response plan, and what is the average detection-to-notification time?
• Does the vendor use subcontractors for any PHI-related function, and does it have sub-BA agreements in place?
• Has the vendor experienced a reportable breach in the past three years? If so, what corrective actions were taken?
• Does the vendor hold any third-party security certifications or attestations (SOC 2 Type II, HITRUST)?

Negotiation questions for specific clauses

1. Permitted uses: What exact functions will the vendor perform with PHI? Are any secondary uses (analytics, product improvement) included, and are they acceptable?
2. Breach notice SLA: What is the vendor's committed timeline for notifying you after discovering an incident? "Without unreasonable delay" is the regulatory floor; many practices negotiate a specific number of days.
3. Indemnity scope: Does the vendor accept indemnification for breaches caused by its own failures? What is the liability cap?
4. Data return and destruction: What format will PHI be returned in at contract termination? What is the destruction method and timeline?
5. Audit rights: Does the BAA give you the right to audit the vendor's controls or request third-party attestation reports?

Operationalization steps

Once the BAA is signed, map each clause to a specific control and assign an owner:

• Encryption clause → verify the vendor's encryption configuration and document it in your risk assessment
• Breach reporting clause → add the vendor's notification contact to your incident response plan
• Access/amendment clause → confirm the vendor's process for responding to patient requests within your required timeframe
• Subcontractor clause → request a list of the vendor's sub-BAs and confirm agreements are in place
• Return/destruction clause → schedule a contract-end data return or destruction procedure and document it

Red flags that should trigger escalation or termination

• Vendor refuses to sign a BAA or insists on language that removes key required provisions
• No documented sub-BA agreements for subcontractors that handle PHI
• Evidence of a past breach with no documented corrective action plan
• Vendor cannot produce a current Security Rule risk analysis
• Unwillingness to accept audit rights or provide SOC 2 / HITRUST attestation

Timeline and cost factors for small practices

For a small dental or medical practice, negotiating and implementing a BAA with a single vendor typically takes two to four weeks when both parties are prepared. Complex arrangements involving data-sharing, subcontractors, or novel service types can extend that timeline to six to eight weeks and may warrant legal review. Legal counsel fees for BAA review vary by firm and complexity; practices should budget for at least one attorney review cycle when updating a full vendor portfolio. Periodic re-audits, recommended annually, add modest ongoing time but prevent the larger cost of an OCR investigation.

Where to find HHS/OCR sample BAAs and authoritative resources

The most reliable starting point for any BAA is the official HHS model language, not a vendor-supplied template. Below are the key resources and what each one is best used for.

• HHS sample BAA provisions: The primary reference for required contract elements under 45 CFR § 164.504(e). Use this to draft or audit every clause in your agreements.
• HHS model BAA (PDF): A complete model agreement with fill-in-the-blank structure. Useful as a drafting template, though legal review is still advisable before execution.
• HHS Business Associates FAQ: Answers common classification questions, including cloud service providers and data use agreement combinations.
• McGuireWoods BAA audit advisory: A legal practitioner's checklist for auditing existing BAAs against HHS model provisions. Best used during annual BAA reviews.
• American Academy of Pediatrics — Business Associates: Practical vendor classification guidance for healthcare providers. Useful for the initial "is this vendor a BA?" determination.
• HIPAA Journal and TotalHIPAA: Both publish practical enforcement summaries and plain-language explainers that complement the primary HHS sources. Neither replaces HHS guidance, but both are useful for staying current on OCR activity.

Annotated clause excerpts

Permitted uses clause (from HHS model language): "Business Associate may use or disclose PHI only as necessary to perform the services described in the Agreement." Operational implication: the vendor's system should be configured to restrict PHI access to only the personnel and functions named in the agreement. Any secondary use, such as training an AI model on patient data, requires explicit written authorization.

Breach reporting clause: "Business Associate shall report to Covered Entity any use or disclosure of PHI not provided for by this Agreement of which it becomes aware, including breaches of unsecured PHI." Operational implication: the vendor must have an active incident detection capability, not just a policy. Logging, alerting, and a defined escalation path are the minimum technical controls that make this clause meaningful.

Return/destruction clause: "Upon termination, Business Associate shall return or destroy all PHI and retain no copies." Operational implication: the vendor must have a documented data deletion procedure and be able to provide a certificate of destruction. Practices should request this documentation at contract end, not assume it happened.

When the arrangement involves novel data-sharing structures or significant indemnity exposure, involve legal counsel before execution.

Key Takeaways

A Business Associate Agreement is a legally required, operationally enforceable contract that covered entities must execute with every vendor that creates, receives, maintains, or transmits PHI on their behalf, and compliance requires verified controls, not just a signature.

Why most BAA problems are really IT problems in disguise

The conventional wisdom treats BAAs as a legal department issue: get the contract signed, file it, move on. That framing is wrong, and it explains why so many practices end up in OCR investigations with a signed BAA and no actual compliance.

Every clause in a BAA describes something that has to happen in the real world. The safeguards clause requires encryption, access controls, and audit logging. The breach reporting clause requires detection capability and a tested incident response process. The return/destruction clause requires documented data deletion. None of those outcomes are produced by a signature. They are produced by configured systems, verified settings, and documented procedures.

Small practices are particularly exposed here. A dental office or medical group typically signs a BAA with their EHR vendor, their billing company, and maybe their IT provider, then assumes the obligation is satisfied. What they often miss is the IT provider's own subcontractors, the cloud backup vendor, the email platform, and the secure messaging tool. Each of those relationships needs its own BAA, and each of those vendors needs to demonstrate that the controls they promised are actually running.

The other underappreciated risk is the gap between what a BAA says and what a vendor actually does. Periodic audits, not just at contract signing but annually, are the only way to verify that the controls promised in 2022 are still in place in 2026. Legal practitioners at McGuireWoods have made exactly this point: audit against the HHS model provisions, not against the vendor's assurances.

Managed IT providers that understand HIPAA can close this gap by mapping their business IT support monitoring, backup, and incident response services directly to BAA clause requirements. That is the practical value of working with a provider that knows the regulatory context, not just the technology.

Greatplainsnetworking helps small practices meet BAA safeguard requirements

For small practices in Norman, Moore, and Oklahoma City, the gap between a signed BAA and verified operational compliance is exactly where Greatplainsnetworking works. Rather than leaving your practice to self-certify that vendor controls are running, Greatplainsnetworking provides 24/7 monitoring, documented incident response, and managed IT support that maps directly to the safeguard and breach-reporting clauses in your BAAs.

The services align to specific BAA obligations: cybersecurity monitoring and ransomware protection satisfy the Security Rule safeguards clause; backup and recovery services address the return/destruction and ePHI availability requirements; Microsoft 365 security configuration supports the access-control and audit-logging provisions. Greatplainsnetworking also offers a free HIPAA and cyber insurance audit for Oklahoma dental practices, which includes a BAA checklist review as part of the assessment.

This article is general information, not legal advice. For contract language and specific compliance determinations, consult a qualified HIPAA attorney. To find out whether your current vendor agreements and technical controls hold up against HHS model provisions, contact Greatplainsnetworking for a no-obligation assessment.

Useful sources and further reading

The following primary and secondary sources support the guidance in this article:

• HHS Business Associates guidance: The authoritative overview of BA definition, BAA requirements, and covered entity obligations. Start here for any compliance question.
• HHS sample BAA provisions: The clause-by-clause reference for drafting and auditing BAAs. Use this alongside the model BAA PDF when reviewing existing agreements.
• HHS model BAA (PDF): A complete fill-in-the-blank template. Best used as a drafting baseline, with legal review before execution.
• 45 CFR § 164.504 — e-CFR: The full regulatory text for BAA requirements. Essential when verifying that a specific clause meets the legal standard.
• HHS Direct Liability of Business Associates factsheet: Explains which HIPAA obligations apply directly to BAs under HITECH and the 2013 final rule.
• McGuireWoods BAA audit advisory: A legal practitioner's checklist for auditing existing BAAs. Best used during annual reviews or when onboarding new digital-health vendors.
• American Academy of Pediatrics — Business Associates: Practical vendor classification guidance for healthcare providers. Useful for the initial BA determination and counterexample analysis.
• HIPAA Journal and TotalHIPAA: Both publish ongoing enforcement summaries and plain-language explainers. Neither replaces HHS primary sources, but both are practical resources for staying current on OCR activity and recent settlement patterns.

Recommended

• ABA Cybersecurity Guidance: What Attorneys Must Know
• What Is Business Email Compromise? A Small Business Guide