A hospital system wants to use your platform to manage patient scheduling. A digital health startup wants to embed your API in their care-coordination tool. A benefits provider wants your SaaS to process employee health data. In every case, the first thing their legal team asks is: "Can you sign a BAA?"
If your answer is uncertain — or worse, if you don't know what a BAA is — you will not close that deal. Healthcare buyers have seen the consequences of HIPAA violations firsthand. They will not move forward without documented proof of compliance. This guide gives you what you need to get there without a six-figure consultant engagement.
Who this applies to: If your SaaS stores, processes, or transmits Protected Health Information (PHI) on behalf of a healthcare organization — even as a subprocessor — you are a Business Associate under HIPAA and this applies to you. "We're just the infrastructure" is not a defense.
Covered Entity vs. Business Associate: Know Which One You Are
HIPAA distinguishes between two types of regulated entities. Covered Entities are the healthcare providers, health plans, and clearinghouses that directly handle PHI as part of their core business — hospitals, insurers, doctor's offices. Business Associates (BAs) are the vendors, SaaS tools, and service providers that handle PHI on a covered entity's behalf.
As a B2B SaaS company selling into healthcare, you are almost certainly a Business Associate. This means HIPAA's Security Rule, Breach Notification Rule, and portions of the Privacy Rule apply directly to you — not just to your customers.
It also means your vendors who touch PHI are your Business Associate subcontractors, and you are required to have BAAs with them too. If you use AWS to host PHI, you need AWS's BAA (they offer one). If you use a third-party logging service that ingests application logs containing PHI, you need a BAA with them — or you need to scrub PHI from logs before they're shipped.
The Business Associate Agreement (BAA): What It Must Cover
A BAA is a contractual agreement between a Covered Entity and a Business Associate (or between a BA and their subcontractors) that establishes the permissible uses and disclosures of PHI. Under 45 CFR §164.308(b), having a BAA in place is not optional — it is a required safeguard.
At minimum, a compliant BAA must:
- Describe the permitted uses and disclosures of PHI by the BA
- Require the BA to not use or disclose PHI beyond what's permitted by the agreement
- Require appropriate safeguards to protect PHI
- Require the BA to report breaches and security incidents to the Covered Entity
- Require the BA to ensure any subcontractors also sign BAAs
- Require the BA to make PHI available for patient access requests
- Require that PHI is returned or destroyed when the agreement terminates
Common mistake: Many SaaS companies sign the customer's BAA template without reading it carefully. Some healthcare customers add clauses requiring 24-hour breach notification (HIPAA gives you 60 days), unlimited liability for breaches, or audit rights you're not operationally prepared for. Read every BAA before signing.
The Three Safeguards: What HIPAA Actually Requires
HIPAA's Security Rule requires Business Associates to implement three categories of safeguards. These aren't vague principles — there are specific required and addressable implementation specifications under each.
1. Administrative Safeguards (§164.308)
These are the policies and procedures that govern how your organization manages PHI. The required specifications include:
- Security Management Process: A risk analysis (at least annually) and a risk management program that addresses identified risks
- Assigned Security Responsibility: A designated HIPAA Security Officer — this can be a part-time role at a startup
- Workforce Training: Annual HIPAA training for all employees who touch PHI or the systems that store it
- Contingency Plan: Data backup procedures, disaster recovery plan, and emergency mode operation plan
- Evaluation: Periodic technical and non-technical evaluation of your security controls
2. Physical Safeguards (§164.310)
If you're fully cloud-hosted, this mostly means ensuring your cloud provider has appropriate physical security (AWS, Azure, and GCP all have this covered under their BAAs). You also need:
- Workstation use policies — who can access PHI-containing systems and from where
- Device and media controls — procedures for the movement and disposal of hardware containing PHI
- A clear policy for employee laptops that might cache PHI (full-disk encryption is the standard answer here)
3. Technical Safeguards (§164.312)
This is where most engineering effort goes. Required specifications:
- Access Controls: Unique user IDs, automatic logoff, and encryption/decryption mechanisms. No shared credentials for systems containing PHI.
- Audit Controls: Hardware, software, and/or procedural mechanisms that record and examine activity in systems that contain or use PHI. Audit logs must be retained and reviewed.
- Integrity Controls: Mechanisms to authenticate that PHI has not been altered or destroyed in an unauthorized manner. Checksums, digital signatures, or equivalent.
- Transmission Security: Technical security measures to guard against unauthorized access to PHI during transmission. TLS 1.2+ in transit, AES-256 at rest.
Cloud Infrastructure: Getting BAAs from Your Vendors
One of the most practical steps you can take today is executing BAAs with your cloud infrastructure providers. The major providers all offer them:
| Provider | BAA Available | How to Get It | PHI-Eligible Services |
|---|---|---|---|
| AWS | Yes | Accept in AWS console under Account Settings → AWS Artifact | EC2, RDS, S3, Lambda (most services) |
| Google Cloud | Yes | Contact sales or via GCP Console for Google Workspace BAA | GCE, GCS, BigQuery, Cloud SQL |
| Azure | Yes | Automatically included in Online Services Terms for most tiers | Most Azure services |
| Vercel | Enterprise only | Must be on Enterprise plan | Deployment infrastructure |
| Supabase | Enterprise only | Contact sales for HIPAA compliance package | Database, auth, storage |
Check every SaaS tool in your stack that touches application data: logging (Datadog, LogDNA, etc.), error tracking (Sentry), analytics, and customer support tools. If any of them could receive PHI — even in error messages or support tickets — you need BAAs or data scrubbing in place.
The Minimum Necessary Rule
HIPAA's "minimum necessary" standard (§164.502(b)) requires that disclosures of PHI be limited to the minimum necessary to accomplish the intended purpose. For SaaS companies, this translates into concrete engineering decisions:
- Don't log more PHI than you need for debugging. Mask or tokenize patient IDs in logs.
- Don't expose full PHI in API responses when a subset is sufficient for the use case
- Don't store PHI longer than the BAA or your data retention policy requires
- Role-based access controls should enforce minimum necessary at the application layer, not just the infrastructure layer
Breach Notification: The 60-Day Clock
If you discover a breach of unsecured PHI, HIPAA's Breach Notification Rule (45 CFR §§ 164.400-414) gives you up to 60 days from discovery to notify the affected Covered Entity. But your BAA may impose a shorter window — some contracts require notification within 24 to 72 hours. Know your contractual obligations before a breach happens.
A breach is any acquisition, access, use, or disclosure of PHI in a way not permitted by the Privacy Rule — unless you can demonstrate through a risk assessment that there is a low probability the PHI was compromised. This four-factor risk assessment (nature of PHI, who accessed it, whether it was actually acquired, and extent to which risk has been mitigated) is your defense against triggering full breach notification.
Practical advice: Document your incident response process before you need it. When you discover a potential breach at 2am, you don't want to be figuring out the 60-day clock, who to call, or what counts as PHI. Write the runbook now.
Your HIPAA Compliance Checklist
- Designate a HIPAA Security Officer (even part-time)
- Complete a formal risk analysis and document findings
- Execute BAAs with all Covered Entity customers
- Execute BAAs with your cloud and SaaS vendors that touch PHI
- Encrypt PHI at rest (AES-256) and in transit (TLS 1.2+)
- Implement unique user IDs and automatic session timeouts
- Enable and retain audit logs for all PHI access
- Enforce full-disk encryption on employee devices
- Write and distribute workforce HIPAA training (annually)
- Create a written breach notification procedure
- Document data retention and destruction policies for PHI
- Establish a contingency/disaster recovery plan for PHI systems
Do You Need a HIPAA Audit?
Unlike SOC 2, there is no official HIPAA certification or third-party attestation that a regulatory body recognizes. What exists are third-party HIPAA compliance assessments — auditors who review your policies, controls, and technical configuration against the Security Rule and issue a report. These typically cost $8,000–$25,000 and are increasingly requested by large health system buyers as part of vendor due diligence.
If you're closing deals under $50k ARR with mid-market healthcare buyers, a thorough self-assessment, a signed BAA, and documented controls are usually sufficient. Once you're going upmarket — academic medical centers, large payers, national health systems — a third-party assessment report becomes a competitive advantage that accelerates procurement.
The good news: if you've already done SOC 2, the overlap is substantial. SOC 2 CC6 (access controls), CC7 (system operations), and CC9 (risk management) map directly to HIPAA's technical and administrative safeguards. You're not starting from zero.