Business Associate Agreement: A Complete Guide for Healthcare Orgs

Introduction 

A business associate agreement (BAA) is a legally required written contract between a HIPAA covered entity and any third party that creates, receives, maintains, or transmits protected health information (PHI) on its behalf. 

Before the HITECH Act of 2009, business associates had no direct HIPAA liability. They were bound only by their contracts. 

HITECH changed that by making business associates directly subject to the HIPAA Security Rule, including administrative, physical, and technical safeguards, as well as imposing direct penalty liability for violations. 

The 2013 Omnibus Rule formalized those requirements. Today, both covered entities and business associates face direct OCR enforcement exposure. 

And yet, in 2023, 74% of cybersecurity incidents involving unauthorized access in healthcare were linked to third-party vendors. 

The trend continues still, with business associates involved in 37% of reported healthcare breaches in the first half of 2025. 

A signed business associate agreement does not make an organization HIPAA-compliant. It does not verify that a single firewall rule has been configured; a single access log has been reviewed, or a single risk assessment has been performed. 

The controls are supposed to exist. Whether they implement them is a separate question, and it is a question the BAA itself cannot answer. This distinction is the most misunderstood aspect of BAA under HIPAA compliance. 

Healthcare IT and security teams need to understand not just what a business associate agreement requires but also where those requirements break down in practice and what the non-compliance cost looks like when they do. 

What is BAA Must Include to Comply with HIPAA For Healthcare?

First, let’s understand which type of organizations are considered business associates. This will help you assess whether you really need a BAA or not.

Who is a Business Associate?

A business associate is defined as a person or entity that performs certain functions or activities involving the use or disclosure of PHI on behalf of, or provides services to, a covered entity. 

This includes entities that handle PHI services such as claims processing, data analysis, billing, and consulting. 

Examples of business associates include third-party claims processors, medical transcriptionists, and IT consultants who work with electronic medical records (EMR) systems. 

What should a BAA include?

HIPAA requires ‘appropriate safeguards’ but does not define what that means for any specific vendor relationship. 

A BAA that says ‘implement appropriate administrative, physical, and technical safeguards’ without specifying encryption standards, MFA requirements, penetration testing cadence, or incident response timelines is technically good. 

But it is operationally meaningless when a breach occurs, and OCR asks what you verified. 

HIPAA specifies the minimum elements a BAA must contain. Every compliant agreement must address: 

• Permitted and required uses and disclosures of PHI, i.e., what the business associate is and is not allowed to do with the data. 

• An obligation not to use or disclose PHI beyond what the contract permits or law requires. 

• A requirement to implement appropriate administrative, physical, and technical safeguards to prevent unauthorized use or disclosure. 

• Breach notification obligations: how and when the business associate must report incidents to the covered entity. 

• Subcontractor compliance; the business associate must ensure its own downstream vendors agree to the same restrictions. 

• PHI return or destruction at contract termination. 

• HHS access rights; the covered entity must be able to make the business associate’s records available to OCR. 

These are baseline requirements. On their own, they create a legally operative contract. What they do not create is a verified security program. 

HIPAA also notes that parties may wish to add specificity beyond the minimum, including stricter breach notification timelines, explicit security control requirements, and audit rights. 

Most BAAs do not include these additions. That gap between the minimum and what is actually protective is where the majority of BAA-related enforcement originates. 

Where Do Business Associate Agreements Fail?

The enforcement record from OCR reveals five recurring failure modes, each of which can produce a reportable breach, a financial penalty, and a corrective action plan even when a BAA is in place. 

Failure Mode 1: The Agreement Exists but the Controls Don’t 

This is the most common and most consequential failure pattern in BAA HIPAA compliance. 

The covered entity asks whether the vendor is HIPAA-compliant. The vendor says yes. A BAA is executed. What the vendor has not disclosed is that they are not actually meeting the controls the agreement obligates them to implement. 

A signed BAA with a hosting or services provider does not guarantee the provider is implementing the controls the BAA requires and does not protect the covered entity from enforcement if required controls are absent on either side. 

According to OCR’s Phase 2 Audit Report, only 11% of covered entities audited showed no compliance deficiencies. The majority had BAAs in place. 

Failure Mode 2: The Subcontractor Chain Is Not Covered 

A business associate that subcontracts PHI-related functions to another vendor must execute a downstream BAA with that subcontractor before granting access to PHI. 

The terms of the top-level BAA do not flow automatically to subcontractors. A separate agreement is required. In practice, business associates frequently fail to recognize this obligation. 

If PHI flows through the arrangement and no downstream BAA exists, the covered entity carries exposure even though the original BAA was properly executed. 

Failure Mode 3: The BAA Is Outdated or Template-Generated 

Organizations sign BAAs once and treat them as permanent. Regulatory requirements change. Vendor service scopes expand. New subcontractors are added. The BAA does not update automatically to reflect any of these changes. 

Template-generated BAAs present a related risk. Large technology vendors often supply their own BAA forms with optional clauses that limit their obligations in ways a covered entity may not notice. 

These are technically compliant agreements that nonetheless create gaps in coverage specific to that vendor relationship. A BAA that was compliant when executed in 2018 may not reflect current HIPAA Security Rule requirements or the actual scope of services the vendor now performs. 

Running on an outdated agreement is itself an enforcement risk and is exactly the kind of gap OCR surfaces during post-breach investigations. 

Failure Mode 4: Breach Notification Timelines Are Not Followed 

HIPAA requires business associates to notify covered entities of a breach within 60 days of discovery. 

The covered entity then holds ultimate accountability for notifying affected individuals, OCR, and in some cases the media, even when the breach originated entirely at the business associate. 

BAAs that include stricter notification timelines, for example 24/48 hours for suspected incidents, with escalation procedures named give covered entities the operational window to respond. BAAs that default to the regulatory minimum do not. 

Key distinction: The covered entity bears the public and regulatory consequence of a breach it did not cause and may not have been told about promptly. This accountability asymmetry is one of the most significant operational risks in any third-party BAA relationship. 

Failure Mode 5: Audit Rights Exist but Are Never Exercised 

BAAs can and should include the covered entity’s right to audit the business associate’s security posture, i.e., to review evidence that the controls the BAA requires are actually implemented. Most BAAs that include this right never see it exercised. 

OCR expects covered entities to investigate vendor capabilities before engagement and monitor compliance throughout the relationship. 

A signed BAA plus a current, independent security attestation like a SOC 2 Type 2 report, a HITRUST certification, or documented annual penetration testing, is materially stronger than a signed BAA alone. 

Without evidence of ongoing compliance, the covered entity has no way to know whether the vendor relationship it is relying on is actually secure. 

How Weak BAAs Exacerbate HIPAA Non-Compliance Cost 

A BAA is not a security program, and there are four specific things it cannot do regardless of how carefully it is drafted. 

1. It cannot verify that controls are implemented.  

2. It does not transfer liability. 

3. It cannot cover subcontractors that were never identified. 

4. It cannot substitute for ongoing monitoring. 

OCR’s enforcement actions since 2024 produced a consistent finding of either inadequate or absent risk analysis. In every single action under that initiative, OCR concluded that the regulated entity had failed to conduct an accurate and thorough assessment of the potential risks and vulnerabilities to its ePHI. 

The pattern is not that organizations lacked BAAs; it’s that neither party could demonstrate that risks had been assessed, and controls had been validated. 

The non-compliance cost across OCR’s 2024–2025 enforcement activity totaled almost $10 million in penalties and settlements. 

That figure does not include the operational cost of the breaches themselves. The average cost of a healthcare data breach is $7.42 million, the highest of any industry for the 14th consecutive year. 

What BAA HIPAA Compliance Looks Like with a Concierge 

When did you last verify that the controls specified in the signed BAA really exist? 

That is the question KLEAP helps healthcare organizations answer. 

Our compliance and security services cover business associate risk assessment, BAA review and gap analysis, and the technical validation that turns a signed agreement into a defensible security posture. 

We scope every engagement around your specific vendor landscape and regulatory obligations. Treat the BAA as the start of the vendor relationship compliance program, which requires four operational disciplines. 

• Specify controls in the agreement itself.  

Name the controls you require: encryption standards, MFA, penetration testing cadence, patch management timelines, and incident response escalation procedures. Requirements that are not written into the agreement are requirements that cannot be enforced. 

• Require evidence of compliance, not self-attestation. 

Claiming HIPAA compliance is not evidence; a current SOC 2 Type 2 report, HITRUST certification, or a documented periodic penetration testing result is. For smaller or higher-risk vendors, consider specifying annual penetration testing directly in the BAA. 

• Map the subcontractor chain before signing. 

Require the business associate to notify you when new subcontractors with PHI access are added. Downstream BAAs must be in place before you grant access to EHR. 

• Exercise audit rights and review BAAs annually. 

BAAs should be reviewed at least annually and updated whenever the scope of services changes, new regulations take effect, or the vendor’s role in handling PHI expands. 

• Tighten breach notification timelines contractually. 

The regulatory default of 60 days is the standard. BAAs that specify 24- or 48-hour notification for suspected incidents allow you the time needed to respond in event of a breach. The covered entity bears accountability for notifying all affected parties before the regulatory window closes. 

A compliant business associate agreement is a necessary foundation for HIPAA for healthcare organizations that work with third-party vendors. It is not sufficient on its own. 

We help IT and security teams manage every BAA as an ongoing compliance program by mapping vendors, verifying controls, tightening timelines, and covering subcontractors end-to-end.