What a BAA Actually Covers (and What It Doesn’t): A Plain-English Guide for App Teams

A business associate agreement (BAA) is the written contract HIPAA requires before a vendor can handle protected health information (PHI) on your behalf. It covers permitted uses of PHI, safeguards, breach reporting, subcontractor obligations, and termination terms. It does not certify compliance, configure your application, or transfer your own HIPAA obligations to the vendor.

That last sentence is the part app teams most often get wrong, so here it is as the spine of this whole guide: a BAA is necessary but not sufficient. Without one, PHI cannot lawfully flow to your vendor at all. With one, you have a liability chain and a set of contractual obligations, and everything else, the configuration, the training, the risk analysis, the day-to-day discipline, is still yours to do.

This guide walks through who signs a BAA, what the regulation forces into the contract, what the contract can never do for you, and how the chain of responsibility actually runs.

Who Signs a BAA, and Why It Exists

HIPAA’s rules bind two kinds of organizations. Covered entities are health plans, healthcare clearinghouses, and healthcare providers who transmit health information electronically. Business associates are the vendors and partners that create, receive, maintain, or transmit PHI on a covered entity’s behalf: the app platform hosting your patient intake forms, the billing service, the cloud storage vendor, the records-disposal company.

The Privacy Rule requires a covered entity to obtain “satisfactory assurances” that a business associate will appropriately safeguard PHI, and the Security Rule requires those assurances to be documented “through a written contract or other arrangement” (45 CFR 164.308(b)). That written contract is the BAA. HHS’s own description of its purpose is modest and precise: the agreement “serves to clarify and limit, as appropriate, the permissible uses and disclosures of protected health information by the business associate” (HHS, Business Associates guidance).

Note what that description does not say. It does not say the BAA makes anyone compliant. It clarifies and limits. The compliance work sits elsewhere.

What a BAA Must Contain

The contents of a BAA are not up for creative negotiation. 45 CFR 164.504(e) dictates the required elements, and 45 CFR 164.314(a) adds the Security Rule side. In plain English, the regulation requires the contract to:

1. Define what the vendor may do with PHI. The contract must “establish the permitted and required uses and disclosures of protected health information by the business associate,” and it may not authorize anything HIPAA itself would forbid. This is the scope clause, and as we will see below, it is the clause buyers most need to read.
2. Prohibit everything else. The vendor agrees to “not use or further disclose the information other than as permitted or required by the contract or as required by law.”
3. Require safeguards. The vendor must “use appropriate safeguards” and comply with the Security Rule for electronic PHI, including its administrative, physical, and technical safeguard requirements.
4. Require reporting. The vendor must report any use or disclosure not permitted by the contract, and under the Security Rule side, “report to the covered entity any security incident of which it becomes aware,” including breaches of unsecured PHI.
5. Flow obligations down to subcontractors. The vendor must “ensure that any subcontractors that create, receive, maintain, or transmit protected health information on behalf of the business associate agree to the same restrictions and conditions.” Your vendor’s vendors are inside the chain too.
6. Support individual rights. The vendor must make PHI available so individuals can access their records, request amendments, and receive an accounting of disclosures.
7. Open the books to regulators. The vendor must make its “internal practices, books, and records” relating to PHI available to the Secretary of Health and Human Services.
8. Handle the ending. At termination, the vendor must, if feasible, return or destroy all PHI, or extend the contract’s protections to whatever it retains. And the covered entity must be able to terminate the contract if the vendor “has violated a material term.”

One more provision deserves its own paragraph, because it points back at you. Under 164.504(e)(1)(ii), a covered entity is not in compliance if it “knew of a pattern of activity or practice” of its business associate that constituted a material breach of the contract, “unless the covered entity took reasonable steps to cure the breach or end the violation.” Signing the BAA does not let you look away afterward. Knowing about a vendor problem and doing nothing is itself a violation, on your side of the ledger.

What a BAA Does Not Do

This is the load-bearing section. Every item below is grounded in what the regulation conspicuously does not say.

• A BAA does not certify HIPAA compliance. Nothing in 164.504(e) evaluates, audits, or approves anyone. It is a contract, not an inspection. HHS is explicit that no certification of HIPAA compliance exists at all: “HHS does not endorse or otherwise recognize private organizations’ ‘certifications’ regarding the HIPAA Privacy Rule or Security Rule, and such certifications do not absolve covered entities of their legal obligations under the Privacy and Security Rules”.
• A BAA does not configure your application. The contract obligates the vendor to use appropriate safeguards on its side. It does not set your access roles, enable your audit logs, define your record-level permissions, or decide which fields hold PHI. A platform can be operated in a fully compliant way and your app on it can still leak, because you built an open form onto a public page.
• A BAA does not cover services outside its scope clause. The regulation requires the contract to establish permitted uses per service, which is exactly why a vendor’s BAA can cover some products and exclude others. New features, beta programs, AI capabilities, acquired add-ons, and specific endpoints are commonly carved out. The signature on the last page covers the list of services in the definitions section, not everything the vendor’s logo appears on.
• A BAA does not do your risk analysis, training, or process. The Security Rule requires the covered entity itself to “conduct an accurate and thorough assessment of the potential risks and vulnerabilities” to its ePHI (45 CFR 164.308(a)(1)(ii)(A)), to train its workforce, to manage access, and to re-evaluate periodically. No vendor contract performs any of that for you.
• A BAA does not transfer your covered-entity obligations. Your duties to patients, regulators, and your own workforce remain yours. The BAA adds obligations to the vendor; it subtracts none from you, and as 164.504(e)(1)(ii) shows, it adds one more: the duty to act when you know the vendor is failing.

Here is the same boundary as a single reference table.

The Chain: Covered Entity, Business Associate, Subcontractor

Responsibility under HIPAA runs as a chain. The covered entity signs a BAA with its business associate. The business associate must, in turn, put the same restrictions on any subcontractor that touches PHI, by contract. A cloud platform’s hosting provider, its backup vendor, its support tooling: if PHI reaches them, the flow-down clause reaches them too.

Since 2013, business associates are not merely bound by contract; they are directly liable to regulators for a defined set of failures. OCR’s May 2019 fact sheet lists ten provisions for which OCR can penalize a business associate directly, including “failure to comply with the requirements of the Security Rule,” “impermissible uses and disclosures of PHI,” “failure to provide breach notification to a covered entity or another business associate,” and, notably, two items about the next link down: failure to enter into BAAs with subcontractors, and failure to act on a subcontractor’s material breach. Signing a BAA is a real legal event for a vendor. It is also a map of what is not on the list: everything absent from those ten items remains the covered entity’s own problem.

The practical consequence for buyers is unglamorous: read the covered-services list. A vendor’s BAA is a contract over defined services, and the definitions decide everything. Two generic examples of how this plays out:

• A platform’s BAA covers its core database and hosting but excludes its AI features, so PHI can live in the tables but must never be fed to the AI assistant sitting one click away in the same interface.
• A vendor’s BAA covers production environments but not free trials or sandboxes, so the prototype your team built with real patient records during the evaluation was outside coverage the entire time.

Neither situation is hidden. Both are printed in the agreement. The failure mode is not vendor deception; it is that nobody on the buying side read the scope clause against the list of features the team actually uses.

What Enforcement Looks Like When the BAA Is Missing

OCR has settled enforcement actions where the absence of a BAA was the central finding, and the two best-known cases bracket the range neatly.

Raleigh Orthopaedic Clinic, P.A. (North Carolina), $750,000, announced April 20, 2016. The practice turned over X-ray films containing the PHI of approximately 17,300 patients to a vendor that would digitize the films and harvest the silver, without first executing a BAA. The settlement, $750,000 plus a corrective action plan, resolved potential violations with no admission of liability. Then-OCR Director Jocelyn Samuels put the principle on record: “HIPAA’s obligation on covered entities to obtain business associate agreements is more than a mere check-the-box paperwork exercise. It is critical for entities to know to whom they are handing PHI and to obtain assurances that the information will be protected.”

Center for Children’s Digestive Health (Illinois), $31,000, April 2017. A seven-clinic pediatric practice had sent records of more than 10,000 individuals to a records storage and disposal company over roughly 12 years. When OCR asked for the BAA, neither party could produce a signed agreement dated before October 2015. The practice settled potential violations for $31,000 plus a corrective action plan.

Two details make these cases instructive rather than merely scary. First, neither involved a headline hack; the absent contract was the finding. Second, the exposure scales down as well as up: a small practice with no breach story still paid, because the obligation attaches the moment PHI moves, not the moment something goes wrong.

Common Myths About BAAs

Does signing a BAA make my app HIPAA compliant?

No. This is the single most common misreading. The BAA is a precondition: without it, PHI cannot lawfully flow to the vendor. But compliance is the sum of the BAA plus safeguards, configuration, risk analysis, training, and ongoing process, most of which the regulation assigns to you, not the vendor. Necessary, not sufficient.

Can any vendor just sign a BAA?

Any vendor can physically sign one, but the signature carries direct regulatory liability under OCR’s 2019 fact sheet, which is why vendors without real safeguards decline to sign, offer one only through bespoke enterprise negotiation with unpublished terms, or contractually prohibit health data instead. A vendor’s public answer to the BAA question is one of the fastest reads on its actual posture.

Is a BAA needed for de-identified data?

No. HIPAA governs protected health information, and data that has been properly de-identified under the Privacy Rule’s standard (45 CFR 164.514) is no longer PHI. The catch is the word “properly”: de-identification means either removing all 18 safe-harbor identifiers with no actual knowledge that what remains could identify the individual, or obtaining a formal expert determination, not just deleting the name column. If any re-identifiable data remains, you still need the BAA.

Do I need a BAA with every software vendor we use?

Only with vendors that create, receive, maintain, or transmit PHI on your behalf. A vendor whose service never touches PHI is not your business associate. The honest difficulty is inventory: teams routinely underestimate which tools PHI actually reaches, which is one more output of the risk analysis the BAA does not do for you.

If my vendor signed a BAA and then has a breach, am I off the hook?

No. The vendor has direct obligations, including notifying you of the breach. But your own notification duties to individuals and regulators remain yours, and if you knew of a pattern of violations by the vendor and took no reasonable steps to cure it or end the arrangement, that inaction is a compliance failure on your side under 164.504(e)(1)(ii).

What to Look For in an App Platform If You Handle PHI

If the BAA is necessary but not sufficient, vendor selection has to check both halves: the contract, and the machinery around it. For an application platform, the checklist is short:

• A signed BAA as a standard offering, at published pricing. If the BAA exists only as an enterprise negotiation with unpublished terms, you cannot price compliance before you commit.
• Independent annual audits. No government body certifies HIPAA compliance, and no third-party badge absolves anyone; the strongest available evidence is an independent third-party audit against HIPAA requirements and SOC 2 Type II, renewed annually by a named firm.
• Record-level security. Access controls that reach individual records and fields, not just an app-level password, so the platform can enforce minimum-necessary access.
• Audit trails. Logging of who accessed and changed what, because both your risk analysis and any future investigation depend on it.

Caspio meets these criteria: it operates a HIPAA-compliant environment with a signed BAA, and its SOC 2 Type II compliance is backed by annual independent audits; the BAA is standard at published pricing, available as a $500 per month add-on on top of a Team plan or higher, with a one-year term, so HIPAA-enabled deployments start from $800 per month total. Caspio’s HIPAA-eligible AI features operate under signed Business Associate Agreements. The covered-services list names the AI paths, so the scope-clause reading this guide recommends running on any vendor can be run on Caspio’s in a minute. For a vendor-by-vendor comparison against the same checklist, see our breakdown of the best HIPAA-compliant app builders.

One closing point for teams tempted to sort out the contract later: getting it wrong is expensive. According to IBM’s 2025 Cost of a Data Breach Report, healthcare data breaches average $7.42 million per incident, the highest of any industry for the 14th consecutive year.

Retrofitting a health app that was built without a BAA in place is often far more costly and time-consuming than starting with a platform that signs a BAA and includes key safeguards from the outset. Adding encryption, access controls, audit logging, workforce training, and ongoing risk analysis after deployment is significantly harder than building with those requirements in mind from day one. The BAA conversation is also cheapest before the first record of PHI is collected or processed. Have it early, review the agreement’s scope carefully, and remember that a signed BAA is the beginning of compliance work, not the end.