What a BAA Is and Why It Matters

A Business Associate Agreement, almost always shortened to BAA, is the legal contract that turns the abstract HIPAA chain of responsibility into something enforceable. It is the single most important document in the compliance picture. Without it, no amount of technical security makes a vendor "HIPAA compliant" from our perspective. With it, we have a vendor we can legally route Protected Health Information through.

What the contract actually says

Every BAA, regardless of which vendor is offering it, contains roughly the same five promises. The wording varies. The structure does not.

1. Purpose limitation. The vendor agrees they will only use the Protected Health Information for the specific service we hired them for. They will not train their AI models on it, sell it, use it for marketing, or repurpose it in any way we did not authorize.
2. Safeguards. The vendor agrees to implement the HIPAA Security Rule safeguards inside their service. Encryption at rest and in transit, access controls, audit logging, all the technical protections covered on the Security Rule Safeguards page.
3. Breach notification. The vendor agrees to tell us promptly if Protected Health Information is exposed on their side, so that we can fulfill our own breach notification obligations on time. This is not optional and it is how the chain of responsibility actually functions during an incident.
4. Subcontractor pass-through. The vendor agrees that anyone they hire who will touch the same Protected Health Information must sign an equivalent BAA with them. This is how the chain keeps extending deeper without losing protection.
5. Return or destroy. When the relationship ends, the vendor agrees to either return the data to us or destroy it. They cannot keep our regulated data after we stop being their customer.

Why the paper itself matters

Some founders assume that if a vendor is technically secure, they are HIPAA compliant. They are not, until there is a signed BAA in place. The reason is procedural: when HHS investigates a breach, the first thing they ask for is the signed BAA. If there is no BAA, the violation is automatic, regardless of how the data was actually protected. The paper is what proves the chain existed.

This also means that a vendor who refuses to sign a BAA, or who only offers one at a higher enterprise pricing tier, cannot be used in the regulated path of our system. They might be a fine vendor in every other respect. They are simply outside the chain.

How vendors offer BAAs

The process varies by vendor. The most common patterns:

• Self-service through a portal. AWS is the gold standard here. You log into AWS Artifact, click through their templated BAA, and it is signed in five minutes. No sales calls.
• Sales-mediated contract. Some vendors require talking to their enterprise sales team. The conversation is short and the BAA is templated, but you have to ask.
• Tier-gated availability.Some vendors only offer BAAs on their higher pricing tiers. The vendor’s cheaper plans are not BAA-eligible at all.
• Inherited through a parent agreement. Some platforms route through underlying providers whose BAAs cover them. AWS Bedrock works this way: the BAA you signed with AWS automatically covers Claude inference running through Bedrock.

The BAA chain for this platform

Because we chose to build on AWS for the regulated data path, our BAA chain is short and easy to manage. We sign one BAA with AWS, and that single agreement covers our database, file storage, AI inference, email sending, logging, secrets management, and content delivery. The other vendors outside the regulated path (the public-facing site, the development tooling) do not need BAAs because they never touch Protected Health Information.

The current status of every BAA we need is tracked on the BAA Status page, which becomes the canonical "is our chain intact" reference during audits.