If you're building software that touches protected health information -- and in 2026, that's a surprisingly large number of SaaS products, patient portals, telehealth platforms, and even marketing tools -- you need a Business Associate Agreement. Not "should have." Need. The penalties for getting this wrong start at $141 per violation and scale up to $2,134,831 per violation category per year. That's not a typo.

I've worked on healthcare-adjacent projects where the BAA conversation happened way too late in the development cycle. Teams build an entire platform, get to the compliance review, and realize their cloud provider doesn't have a BAA in place, their analytics tool is ingesting PHI without one, and their logging service is storing patient data in plaintext. It's a mess. This guide is what I wish someone had handed me the first time I had to deal with HIPAA compliance as a developer.

We'll cover what a BAA actually is (and isn't), who needs one, what must be in it, and provide a practical template you can adapt. Whether you're a covered entity evaluating vendors or a business associate trying to figure out your obligations, this is the guide.

Table of Contents

HIPAA Business Associate Agreement (BAA): Template & Full Guide

What Is a Business Associate Agreement?

A Business Associate Agreement (BAA) is a legally binding contract required under HIPAA between a covered entity (think: hospitals, health plans, healthcare clearinghouses) and any third party -- the business associate -- that creates, receives, maintains, or transmits protected health information (PHI) on the covered entity's behalf.

The legal basis comes from 45 CFR § 164.502(e) and § 164.504(e). The HIPAA Privacy Rule mandates these agreements. The Security Rule adds requirements specific to electronic PHI (ePHI). After the HITECH Act and the 2013 Omnibus Rule, business associates became directly liable for HIPAA compliance -- not just contractually liable through the BAA, but directly subject to enforcement by the Office for Civil Rights (OCR).

Here's what a BAA is not: it's not a checkbox exercise. It's not something you download, sign, and forget. A BAA establishes specific obligations, restricts how PHI can be used and disclosed, defines breach notification procedures, and creates audit rights. If you treat it as boilerplate, you're setting yourself up for pain.

Why BAAs Matter More in 2026

The enforcement landscape has shifted significantly. OCR has been ramping up audits and settlements. In 2024, they settled multiple cases specifically related to missing or inadequate BAAs -- including a $1.55 million settlement with a health system that failed to have BAAs with several vendors processing ePHI. The trend has continued into 2025 and 2026 with increasing scrutiny on cloud services, AI tools, and web tracking technologies.

The December 2022 OCR bulletin on tracking technologies (updated in 2023) made it clear that even website analytics and pixel tracking can trigger BAA requirements if they collect PHI -- including IP addresses combined with health condition information from appointment scheduling pages.

Who Needs a BAA?

This is where things get tricky, and where I see the most confusion.

Covered entities must have BAAs with every business associate. A covered entity is:

  • A healthcare provider that transmits health information electronically
  • A health plan (insurance companies, HMOs, Medicare, Medicaid)
  • A healthcare clearinghouse

Business associates are individuals or organizations that perform functions or activities on behalf of a covered entity that involve PHI. This includes:

  • IT service providers with access to ePHI
  • Cloud hosting providers storing PHI
  • Billing and claims processing companies
  • EHR/EMR vendors
  • Data analytics firms processing health data
  • Law firms and accountants accessing PHI
  • Shredding and document storage companies
  • Consultants who require access to PHI
  • Web developers building patient-facing applications (yes, this includes us at Social Animal when we build healthcare platforms)

Subcontractors of business associates also need BAAs. If you're a business associate and you hire a cloud provider to host the PHI you're processing, you need a BAA with that provider. This was a major change from the 2013 Omnibus Rule.

Who Doesn't Need a BAA?

Not every vendor relationship requires one:

  • Conduit exception: Entities that merely transport PHI (like the postal service or internet service providers) without accessing it don't need BAAs.
  • Employment relationships: Your own employees aren't business associates -- they're members of your workforce.
  • Patient-directed disclosures: If a patient asks you to send their records to a specific app, that app isn't your business associate (though this gets complicated with TEFCA and health information exchanges).
  • Treatment purposes between providers: When one provider shares PHI with another provider for treatment, that's not a BA relationship.

Covered Entities vs. Business Associates vs. Subcontractors

Understanding the chain of responsibility is critical. Here's how the relationships break down:

Role Examples BAA Required With Direct HIPAA Liability?
Covered Entity Hospital, health plan, clearinghouse All business associates Yes -- full liability
Business Associate EHR vendor, cloud host, billing company Covered entity (upstream) + subcontractors (downstream) Yes -- since 2013 Omnibus Rule
Subcontractor Cloud infrastructure under a BA, sub-hired developer Business associate (upstream) Yes -- since 2013 Omnibus Rule
Conduit ISP, postal service, courier None No (conduit exception)
Member of Workforce Employee, volunteer, trainee None (not a BA) No (covered by entity's policies)

The chain can go several levels deep. A hospital uses an EHR vendor (BA). The EHR vendor uses AWS (subcontractor/BA). AWS uses specific infrastructure partners. Each link in the chain needs a BAA.

HIPAA Business Associate Agreement (BAA): Template & Full Guide - architecture

Required Components of a HIPAA BAA

The HHS provides guidance on what must be included, and they published an updated model BAA that's worth reviewing. Here are the mandatory and recommended components:

Mandatory Elements (per 45 CFR § 164.504(e))

  1. Permitted uses and disclosures: Spell out exactly what the BA can do with PHI. This must be limited to what's in the contract, required by law, or otherwise permitted under the Privacy Rule.

  2. Prohibition on unauthorized use/disclosure: The BA cannot use or disclose PHI in ways not permitted by the agreement.

  3. Safeguards requirement: The BA must use appropriate safeguards -- and specifically implement the Security Rule requirements for ePHI -- to prevent unauthorized use or disclosure.

  4. Reporting obligations: The BA must report any use or disclosure not provided for in the agreement, including security incidents and breaches.

  5. Subcontractor obligations: The BA must ensure any subcontractors that handle PHI agree to the same restrictions and conditions.

  6. Access to PHI: The BA must make PHI available to the covered entity (or directly to individuals) to satisfy the individual's right of access under 45 CFR § 164.524.

  7. Amendment of PHI: The BA must make PHI available for amendment and incorporate amendments when directed by the covered entity.

  8. Accounting of disclosures: The BA must make information available for an accounting of disclosures as required by 45 CFR § 164.528.

  9. HHS access: The BA must make its practices, books, and records available to HHS for compliance determination.

  10. Return or destruction of PHI: Upon termination, the BA must return or destroy all PHI. If that's not feasible, protections must extend beyond termination.

  11. Termination provisions: The covered entity must be able to terminate the agreement if the BA violates a material term.

  • Breach notification timelines: HIPAA requires BAs to report breaches to CEs "without unreasonable delay" and no later than 60 days. But 60 days is an eternity. Smart agreements specify shorter windows -- 5 to 10 business days is common.
  • Cyber insurance requirements: Increasingly standard. Specify minimum coverage amounts.
  • Audit rights: Beyond what HHS requires, give yourself the right to audit or request SOC 2 + HIPAA reports.
  • Indemnification clauses: Who pays when things go wrong?
  • Data residency requirements: Where will PHI be stored? This matters for state laws too.
  • Training requirements: Require the BA to train their workforce on HIPAA.
  • Encryption standards: Specify minimum encryption (AES-256 at rest, TLS 1.2+ in transit).

BAA Template with Annotations

Here's a practical BAA template structure. This isn't legal advice -- you need an attorney to finalize any BAA for your specific situation. But this gives you a solid starting framework based on the HHS model agreement and real-world implementations I've seen work well.

BUSINESS ASSOCIATE AGREEMENT

This Business Associate Agreement ("BAA") is entered into as of [DATE]
by and between:

[COVERED ENTITY NAME], a [STATE] [ENTITY TYPE] ("Covered Entity")
and
[BUSINESS ASSOCIATE NAME], a [STATE] [ENTITY TYPE] ("Business Associate")

(collectively, the "Parties")

RECITALS

WHEREAS, Covered Entity is a HIPAA covered entity as defined in
45 CFR § 160.103;

WHEREAS, Business Associate performs certain services for Covered
Entity that involve the creation, receipt, maintenance, or transmission
of Protected Health Information (PHI);

WHEREAS, the Parties intend to comply with the Health Insurance
Portability and Accountability Act of 1996 (HIPAA), the Health
Information Technology for Economic and Clinical Health Act (HITECH),
and their implementing regulations;

NOW THEREFORE, the Parties agree as follows:

---

SECTION 1: DEFINITIONS

Terms used but not defined in this BAA shall have the meanings
assigned in 45 CFR Parts 160 and 164.

"Breach" shall have the meaning given in 45 CFR § 164.402.
"Designated Record Set" shall have the meaning in 45 CFR § 164.501.
"PHI" means Protected Health Information as defined in 45 CFR § 160.103.
"ePHI" means Electronic Protected Health Information.
"Security Incident" shall have the meaning in 45 CFR § 164.304.
"Subcontractor" shall have the meaning in 45 CFR § 160.103.

---

SECTION 2: OBLIGATIONS OF BUSINESS ASSOCIATE

2.1 Permitted Uses and Disclosures. Business Associate shall use
or disclose PHI only as permitted or required by this BAA, the
underlying service agreement, or as Required by Law.

2.2 Safeguards. Business Associate shall implement administrative,
physical, and technical safeguards that reasonably and appropriately
protect the confidentiality, integrity, and availability of ePHI,
in accordance with 45 CFR Part 164, Subpart C.

[ANNOTATION: Be specific here. Consider adding minimum requirements
like AES-256 encryption at rest, TLS 1.2+ in transit, MFA for
administrative access, etc.]

2.3 Reporting. Business Associate shall report to Covered Entity:
  (a) Any use or disclosure of PHI not provided for by this BAA
      within [5/10] business days of discovery;
  (b) Any Security Incident within [5/10] business days of discovery;
  (c) Any Breach of Unsecured PHI within [10] business days of
      discovery, including the information required by
      45 CFR § 164.410(c).

[ANNOTATION: The HIPAA default is 60 days. You want this shorter.
10 business days is aggressive but achievable. Some organizations
go as low as 48 hours for confirmed breaches.]

2.4 Subcontractors. Business Associate shall enter into a written
agreement with any Subcontractor that creates, receives, maintains,
or transmits PHI on behalf of Business Associate, containing
substantially the same restrictions and conditions as this BAA.

2.5 Access. Business Associate shall make PHI in a Designated Record
Set available to Covered Entity within [15] business days of a
request, to enable Covered Entity to fulfill its obligations under
45 CFR § 164.524.

2.6 Amendment. Business Associate shall make PHI available for
amendment and incorporate amendments to PHI in a Designated Record
Set as directed by Covered Entity within [30] days.

2.7 Accounting of Disclosures. Business Associate shall document
and make available information required for an accounting of
disclosures under 45 CFR § 164.528.

2.8 Availability of Records. Business Associate shall make its
internal practices, books, and records relating to the use and
disclosure of PHI available to the Secretary of HHS for purposes
of determining compliance.

2.9 Minimum Necessary. Business Associate shall limit its use,
disclosure, or request of PHI to the minimum necessary to accomplish
the intended purpose, in accordance with 45 CFR § 164.502(b).

2.10 Training. Business Associate shall ensure that all members of
its workforce who handle PHI receive appropriate HIPAA training
upon hire and annually thereafter.

2.11 Audit Reports. Upon request, Business Associate shall provide
Covered Entity with a copy of its most recent SOC 2 + HIPAA report,
HITRUST certification, or other mutually agreed-upon independent
third-party audit report.

---

SECTION 3: PERMITTED USES AND DISCLOSURES

3.1 Business Associate may use or disclose PHI solely for the
purpose of performing services described in the underlying
service agreement.

3.2 Business Associate may use or disclose PHI as Required by Law.

3.3 Business Associate may use PHI for its proper management and
administration or to carry out its legal responsibilities, provided
that disclosures are Required by Law or Business Associate obtains
reasonable assurances from the recipient.

3.4 Business Associate may use PHI to provide Data Aggregation
services as permitted by 45 CFR § 164.504(e)(2)(i)(B).

3.5 Business Associate may de-identify PHI in accordance with
45 CFR § 164.514(a)-(c).

---

SECTION 4: OBLIGATIONS OF COVERED ENTITY

4.1 Covered Entity shall notify Business Associate of any
limitations in its Notice of Privacy Practices that may affect
Business Associate's use or disclosure of PHI.

4.2 Covered Entity shall notify Business Associate of any changes
in, or revocation of, authorization by an Individual.

4.3 Covered Entity shall notify Business Associate of any
restrictions on the use or disclosure of PHI agreed to by
Covered Entity under 45 CFR § 164.522.

---

SECTION 5: TERM AND TERMINATION

5.1 This BAA shall be effective as of the date first written above
and shall continue until the underlying service agreement terminates
or until terminated as provided herein.

5.2 Covered Entity may terminate this BAA and the underlying
service agreement if Covered Entity determines that Business
Associate has violated a material term of this BAA.

5.3 Upon termination, Business Associate shall return or destroy
all PHI received from Covered Entity or created/received on behalf
of Covered Entity. If return or destruction is not feasible,
Business Associate shall extend the protections of this BAA to
such PHI and limit further use and disclosure to those purposes
that make return or destruction infeasible.

---

SECTION 6: MISCELLANEOUS

6.1 Indemnification. [Customize based on negotiation]
6.2 Insurance. Business Associate shall maintain cyber liability
insurance with minimum coverage of $[AMOUNT].
6.3 Governing Law. [STATE]
6.4 Amendment. This BAA may be amended only in writing.
6.5 Survival. Sections related to return/destruction of PHI and
indemnification shall survive termination.

This is a starting point. Your healthcare attorney will want to customize it based on your specific use case, state laws (some states like California, Texas, and New York have additional health privacy requirements), and the nature of the services being provided.

Common Mistakes That Invalidate a BAA

I've reviewed dozens of BAAs over the years, and these mistakes come up constantly:

1. Using a Generic Template Without Customization

Grabbing a template off the internet and signing it without tailoring the permitted uses and disclosures to your actual relationship. A BAA for a cloud hosting provider looks very different from one for a billing service.

2. Failing to Include Subcontractor Requirements

Post-2013, this is mandatory. If your BAA doesn't address subcontractors, it's deficient. I've seen BAAs from major SaaS companies that completely omit this.

3. No Breach Notification Timeline

Relying on the default 60-day window is a bad idea. By the time you hear about a breach at day 59, you've lost critical incident response time. Specify shorter timelines.

4. Not Executing BAAs Before Sharing PHI

This seems obvious, but it happens all the time. A developer spins up a new analytics tool, starts collecting data from the patient portal, and nobody thinks about the BAA until months later. The PHI is already flowing. You're already in violation.

5. Forgetting to Update BAAs

Regulations change. Services change. Your 2019 BAA might not reflect current requirements. Review annually at minimum.

6. Confusing a BAA with a Data Processing Agreement (DPA)

GDPR's DPA and HIPAA's BAA are different instruments with different requirements. Having one doesn't satisfy the other. If you handle data from EU individuals who are also patients in the US system, you may need both.

Technical Implementation Considerations

As developers building healthcare applications, the BAA has direct implications on your architecture. Here's what the agreement means in practice:

Infrastructure Requirements

# Example: HIPAA-eligible AWS services configuration
# Not all AWS services are covered under their BAA

# ✅ Covered under AWS BAA
services:
  compute: [EC2, ECS, EKS, Lambda, Fargate]
  storage: [S3, EBS, EFS, Glacier]
  database: [RDS, DynamoDB, Aurora, Redshift]
  networking: [VPC, CloudFront, Route 53, API Gateway]
  security: [KMS, CloudTrail, CloudWatch, GuardDuty]

# ❌ NOT covered under AWS BAA (as of 2026)
# Always check the current list at:
# https://aws.amazon.com/compliance/hipaa-eligible-services-reference/

Major cloud providers -- AWS, Google Cloud, and Microsoft Azure -- all offer BAAs, but you have to explicitly activate them. On AWS, you enable it through AWS Artifact. On Google Cloud, you accept the BAA through your organization settings. On Azure, it's part of the Online Services Terms for eligible services.

Encryption Requirements

Your BAA likely specifies encryption. Here's what that looks like in practice:

# Encryption at rest - minimum AES-256
# Encryption in transit - minimum TLS 1.2

# Example: Encrypting PHI before database storage
from cryptography.fernet import Fernet
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.kdf.pbkdf2 import PBKDF2HMAC
import base64, os

def derive_key(password: bytes, salt: bytes) -> bytes:
    kdf = PBKDF2HMAC(
        algorithm=hashes.SHA256(),
        length=32,  # AES-256
        salt=salt,
        iterations=600_000,  # OWASP 2023 recommendation
    )
    return base64.urlsafe_b64encode(kdf.derive(password))

def encrypt_phi(data: str, key: bytes) -> bytes:
    f = Fernet(key)
    return f.encrypt(data.encode())

Access Controls and Audit Logging

Your BAA commits you to implementing access controls and maintaining audit logs. Every access to PHI should be logged with who accessed it, when, and why. This isn't optional -- it's how you demonstrate compliance during an OCR audit.

If you're building on Next.js or another modern framework, implement role-based access control at the API layer and audit logging as middleware. Don't rely on client-side controls.

Monitoring and Enforcing Your BAAs

Having a signed BAA is step one. Monitoring compliance is the ongoing work.

Annual Review Process

  1. Inventory all BAAs: Maintain a centralized register of every active BAA, including the business associate name, services provided, PHI types accessed, effective date, and last review date.
  2. Request audit reports: Ask for SOC 2 Type II + HIPAA reports, HITRUST certifications, or equivalent third-party assessments annually.
  3. Verify subcontractor chains: Confirm your BAs have BAAs with their subcontractors.
  4. Update for regulatory changes: HIPAA regulations evolve. The HHS proposed modifications to the HIPAA Privacy Rule are still being finalized in 2026 and may require BAA updates.
  5. Document everything: If OCR comes knocking, your documentation is your defense.

Risk Assessment

Perform a risk assessment of each business associate based on the volume and sensitivity of PHI they access. Not all BA relationships carry equal risk. Your EHR vendor with access to millions of records needs more scrutiny than the document shredding company.

Risk Factor Low Risk Medium Risk High Risk
PHI Volume < 500 records 500-50,000 records > 50,000 records
PHI Type De-identified data Limited dataset Full PHI with SSN
Access Type Encrypted storage only Read access Read/write access
Location On-premises, US only US cloud Multi-region/offshore
Audit Report SOC 2 Type II current SOC 2 Type I No independent audit

BAA Requirements by Vendor Type

Here's a practical breakdown of common vendor relationships and their BAA requirements:

Vendor Type BAA Required? Common Gotchas
Cloud hosting (AWS, GCP, Azure) Yes Must explicitly activate; not all services are eligible
EHR/EMR vendor Yes Verify subcontractor chain
Email service (if sending PHI) Yes Most standard email providers don't sign BAAs; use HIPAA-compliant email services
Website analytics Maybe If tracking tech collects PHI (IP + health condition), yes
Payment processor Yes (if they see PHI) Stripe, for example, has a BAA for healthcare
Web development agency Yes (if accessing PHI during development) Use synthetic test data to avoid this requirement during dev
Document storage/shredding Yes Often overlooked
Legal counsel Yes (if accessing PHI) Attorneys are not automatically exempt
Answering/phone service Yes They're hearing PHI on calls
AI/ML tools Yes A rapidly evolving area -- be very careful with LLM-based tools

For web development specifically, if we're building a headless CMS-powered healthcare portal at Social Animal, we structure projects to minimize PHI exposure during development. Synthetic test data, environment isolation, and PHI-free staging environments mean we can often avoid needing BAAs for the development phase while still delivering HIPAA-ready production systems.

FAQ

What is a HIPAA Business Associate Agreement?

A BAA is a legally required contract under HIPAA (45 CFR § 164.504(e)) between a covered entity and any third party that creates, receives, maintains, or transmits protected health information on the covered entity's behalf. It establishes what the business associate can and cannot do with PHI, requires appropriate safeguards, and defines breach notification procedures. Without one, both parties are in violation of HIPAA regardless of whether a breach actually occurs.

Who is responsible for initiating the BAA -- the covered entity or the business associate?

The legal obligation falls on the covered entity to ensure BAAs are in place with all business associates. However, in practice, many business associates (especially SaaS vendors) have standard BAAs ready to go. Either party can initiate the conversation, but the covered entity bears the regulatory risk if a BAA doesn't exist. Business associates also have an obligation to ensure BAAs are in place with their own subcontractors.

Can I use the HHS model BAA template as-is?

The HHS published an updated model BAA that's a solid starting point, but it's explicitly described as a model -- not a one-size-fits-all document. You should customize it for your specific relationship, services, PHI types, and risk profile. Key areas to customize include breach notification timelines (the HHS model uses the 60-day maximum, which most organizations shorten), specific security requirements, and indemnification terms. Always have a healthcare attorney review your final version.

What happens if a business associate violates the BAA?

The covered entity must take reasonable steps to cure the violation. If the violation can't be cured, the covered entity must terminate the BAA and the underlying contract, or if termination isn't feasible, report the problem to OCR. Beyond contractual remedies, the business associate faces direct HIPAA liability since the 2013 Omnibus Rule -- meaning OCR can investigate and penalize the BA directly. Penalties range from $141 to $2,134,831 per violation category per year (2026 adjusted amounts), plus potential criminal penalties for knowing violations.

Does a web developer or agency need a BAA?

It depends on whether the developer accesses, stores, or transmits PHI. If you're building a patient portal and your development environment uses real patient data, yes -- you need a BAA. If you're building the application but using synthetic test data and never touching actual PHI, you likely don't need one for the development phase. However, the production hosting and any services that handle PHI in production absolutely require BAAs. This is why environment isolation and synthetic data strategies matter during healthcare application development.

How often should BAAs be reviewed and updated?

At minimum, annually. You should also review BAAs whenever there's a material change in the services being provided, a change in applicable regulations, a security incident involving the business associate, or a change in the BA's subcontractor chain. The HHS has proposed updates to the HIPAA Privacy Rule that, when finalized, will likely require updates to existing BAAs. Keep a calendar reminder and build BAA review into your annual compliance workflow.

Do I need a BAA with my cloud provider even if I encrypt everything?

Yes. Encryption doesn't eliminate the BAA requirement. Even if PHI is encrypted and the cloud provider can't read it, the provider is still maintaining ePHI. AWS, Google Cloud, and Azure all provide BAAs -- you just need to explicitly activate them. The one narrow exception is the "conduit" exception for entities that merely transport data (like an ISP), but cloud providers that store data don't qualify for the conduit exception.

What's the difference between a BAA and a Data Processing Agreement (DPA)?

A BAA is a US HIPAA requirement governing protected health information. A DPA is typically a GDPR requirement governing personal data of EU/EEA individuals. They serve related but different legal purposes under different regulatory frameworks. Having a DPA doesn't satisfy the BAA requirement, and vice versa. If your organization handles health data that falls under both HIPAA and GDPR -- for example, a US health system with EU patients -- you may need both agreements with the same vendor. Some vendors offer combined agreements, but make sure each regulatory requirement is independently satisfied.