You've built a great SaaS product. A hospital wants to use it. Before any data flows, their compliance team sends you a Business Associate Agreement (BAA) and asks you to sign it.
If you don't know what you're signing — or what obligations it creates — you're taking on legal liability that could cost your company millions.
What Makes You a Business Associate
Under HIPAA, a Business Associate is any person or organization that creates, receives, maintains, or transmits protected health information (PHI) on behalf of a covered entity (healthcare providers, health plans, clearinghouses).
For software teams, this means you're a business associate if:
- Your application stores patient data for a clinic or hospital
- Your API processes, routes, or transforms PHI
- Your cloud infrastructure hosts ePHI workloads
- Your analytics platform ingests data that includes patient identifiers
- Your customer support team can access PHI during troubleshooting
- Your backup systems contain copies of ePHI
The key phrase is "on behalf of." If a healthcare provider uses your product and PHI passes through it, you're almost certainly a business associate — even if you never look at the data yourself.
What a BAA Actually Requires
A BAA isn't just a formality. It's a legally binding contract that requires you to:
1. Implement HIPAA Security Safeguards
You must apply the same administrative, physical, and technical safeguards that covered entities are required to implement. That means encryption, access controls, audit logging, workforce training, and a documented security program.
2. Report Breaches
If you discover a breach of unsecured PHI, you must notify the covered entity within 60 days (many BAAs negotiate this down to 10-30 days). "Discovery" includes when any employee or agent of your organization knows about it — not just when leadership finds out.
3. Ensure Subcontractor Compliance
If you use subcontractors who will access PHI (cloud providers, monitoring services, email platforms), you need BAAs with them too. The chain of BAAs must extend to every entity that touches PHI.
4. Make PHI Available for Patient Rights Requests
If a patient requests access to their records and your system holds those records, you need processes to support the covered entity in fulfilling that request within 30 days.
5. Return or Destroy PHI at Contract End
When the relationship ends, you must return all PHI to the covered entity or destroy it — and certify the destruction. This includes backups, logs, cached data, and any derived datasets.
The Subcontractor Chain Problem
This is where most development teams get tripped up. Consider a typical SaaS stack:
Your Healthcare SaaS App
├── AWS (infrastructure) → Need BAA ✓ (AWS offers one)
├── Datadog (monitoring) → Need BAA if logs contain PHI
├── SendGrid (email) → Need BAA if emails contain PHI
├── Stripe (payments) → Usually no PHI, but verify
├── Slack (internal comms) → Need BAA if team discusses PHI
├── Jira (issue tracking) → Need BAA if tickets contain PHI
└── GitHub (code repos) → Need BAA if repos contain PHI
Every tool in your stack that could come into contact with PHI needs a BAA. The major cloud providers (AWS, GCP, Azure) all offer BAAs. Many SaaS tools do not — which means you either need to find alternatives that do, or ensure PHI never touches those systems.
Common BAA Mistakes
Assuming your cloud provider's BAA covers everything
AWS's BAA covers their infrastructure services, but it doesn't make your application compliant. You're still responsible for how you configure and use those services. An S3 bucket without encryption, a publicly accessible RDS instance, or an unencrypted EBS volume are all your problem, not AWS's.
Not having a BAA before data flows
The BAA must be executed before any PHI is created, received, maintained, or transmitted. Retroactive BAAs don't fix the compliance gap during the period without one.
Using personal or non-BAA-covered tools for PHI
A developer SSHs into a production server and copies patient data to their laptop for debugging. That laptop isn't covered by your BAA with the healthcare client. Now you have an uncontrolled PHI exposure.
Ignoring the minimum necessary standard
Your BAA doesn't give you carte blanche to access all PHI. You should only access, use, or disclose the minimum necessary PHI to perform the service specified in the BAA.
Practical Steps for Dev Teams
- Inventory your PHI touchpoints — Map every system, service, and workflow where PHI could exist
- Audit your vendor stack — Identify which vendors have BAAs available and which don't
- Implement technical controls — Encryption, access controls, and audit logging across all PHI-touching systems
- Document your security program — You need policies, procedures, and evidence that you're actually following them
- Conduct a Security Risk Analysis — Assess the risks to ePHI in your environment and document your remediation plans
Making It Manageable
For SaaS companies entering the healthcare space, the BAA and compliance requirements can feel overwhelming. The key is treating compliance as an engineering problem, not a legal one — build it into your architecture, automate the tracking, and maintain documentation as a living system rather than a point-in-time exercise.
For a comprehensive look at how to manage BAAs and other compliance requirements as part of your broader HIPAA program: HIPAA Compliance Solutions
And if you're starting from the foundation — the Security Risk Analysis that drives your entire compliance program: What Is a HIPAA Security Risk Analysis?
Joe Gellatly is CEO of Medcurity, a HIPAA compliance platform that helps healthcare organizations and their business associates manage risk assessments, BAA tracking, and compliance programs.
Top comments (0)