HIPAA Compliance for Software: A Developer's Guide to the Rules, BAAs and Safeguards

A clinic wants to use your scheduling app. Their compliance officer asks 2 questions: “Will you sign a BAA?” and “How do you protect ePHI?” If you’re not sure how to answer, you’re not alone. Many founders building health software learn HIPAA on the fly, often mid-sale.

This guide explains HIPAA compliance for software in practical terms: when the law applies to you, what the 3 core rules require, how business associate agreements work, and how the technical safeguards translate into engineering work. We cite the US Department of Health and Human Services (HHS) throughout.

This is general information, not legal or medical advice. Talk to a qualified healthcare attorney about your specific situation.

Does HIPAA apply to your software?

HIPAA applies to 2 groups:

• Covered entities: health plans, healthcare clearinghouses, and healthcare providers that conduct certain transactions electronically.
• Business associates: people or companies that create, receive, maintain or transmit protected health information (PHI) on behalf of a covered entity, or on behalf of another business associate as a subcontractor.

If your software stores or processes PHI for a hospital, clinic, health plan or another business associate, you’re almost certainly a business associate. That includes cloud hosting, EHR add-ons, billing tools, telehealth platforms and analytics services.

If your app collects health data directly from consumers and isn’t working on behalf of a covered entity, HIPAA may not apply. That doesn’t mean no rules apply. The Federal Trade Commission’s amended Health Breach Notification Rule, effective July 29, 2024, makes clear that it covers most health apps and similar technologies not covered by HIPAA.

For context on where health software is heading, see our articles on AI in healthcare and telehealth and remote patient monitoring.

The 3 HIPAA rules software teams need to know

The 2013 Omnibus Rule, with a general compliance date of September 23, 2013, made business associates directly liable for complying with parts of the HIPAA Rules. That’s why your company, not just your customer, carries the legal risk.

The Privacy Rule in brief

The Privacy Rule sets when PHI can be used or disclosed, gives patients rights to access and amend their records, and requires reasonable efforts to limit uses and disclosures to the minimum necessary. For a software vendor, the practical impact is that you may only use PHI as your BAA allows, and you must help your customers meet patient access and amendment requests.

The Security Rule in brief

The Security Rule requires reasonable and appropriate administrative, physical and technical safeguards for ePHI. It’s deliberately flexible: HHS lets you weigh your size, costs and risks when choosing measures. The foundation is a documented risk analysis, which HHS describes as an ongoing process, not a one-time exercise.

The Breach Notification Rule in brief

After a breach of unsecured PHI, covered entities must notify affected individuals without unreasonable delay and no later than 60 days after discovery. Breaches affecting 500 or more people also require notice to HHS within 60 days and, when more than 500 residents of a state or jurisdiction are affected, to prominent media there. Smaller breaches can be logged and reported to HHS within 60 days after the end of the calendar year. Business associates must notify the covered entity of breaches they discover.

Business associate agreements (BAAs)

A BAA is the contract that lets a covered entity share PHI with you. HHS lists what it must include. In summary, a BAA must:

1. Set the permitted and required uses and disclosures of PHI.
2. Prohibit uses or disclosures beyond the contract or the law.
3. Require appropriate safeguards, including Security Rule compliance for ePHI.
4. Require reporting of improper uses, disclosures and security incidents, including breaches.
5. Require subcontractors that handle PHI to agree to the same restrictions.
6. Make PHI available for patient access, amendment and accounting of disclosures.
7. Make internal practices and records available to HHS for compliance reviews.
8. Require return or destruction of PHI at termination, where feasible.

Your BAA chain runs in both directions. You sign with your customers, and you need BAAs with any vendor that touches PHI for you: cloud hosts, email or SMS providers, logging tools, support desks and backup services.

Key takeaway: No BAA, no PHI. Before any vendor in your stack touches patient data, confirm a signed BAA is in place and that the specific services you use are covered by it.

Technical safeguards translated for engineers

The Security Rule’s technical safeguards sit in 45 CFR 164.312. Some implementation specifications are “required” and others are “addressable.” Addressable doesn’t mean optional: you must assess whether it’s reasonable and appropriate, implement it or an equivalent, and document your decision.

A few practical engineering habits help a lot:

• Keep PHI out of logs, analytics events, error messages and crash reports.
• Separate production data from development and test environments; use synthetic data for testing.
• Encrypt data at rest and in transit. HHS treats PHI encrypted to its guidance standards as “secured,” which matters for breach notification.
• Apply least privilege for staff and services; review access regularly.
• Build an audit trail from day 1. Retrofitting one is painful.

Our guide to zero trust security covers the access model many health software teams now use.

Administrative and physical safeguards still apply

Technical controls aren’t enough on their own. The Security Rule also requires administrative safeguards, starting with the security management process: risk analysis, risk management, a sanction policy and information system activity review. You’ll also need a designated security official, workforce training, incident procedures, contingency planning and periodic evaluation.

Physical safeguards cover facility access, workstation use and device and media controls. If you run in a major cloud, the provider handles data center security, but your team still owns laptops, phones and how devices are wiped or disposed of.

Cloud hosting and HIPAA

HHS guidance says a cloud service provider that stores ePHI is a business associate even if it stores only encrypted data and doesn’t hold the key. HHS calls these “no-view” services. So you need a BAA with your cloud provider, and you need to configure services correctly. Major clouds offer BAAs but typically cover only specific eligible services, so check the list before you build.

HHS also warns that encryption alone isn’t enough to meet the Security Rule. You still need access controls, logging, backups and the rest.

Ransomware is a top risk for health data. HHS’s ransomware fact sheet says that when ransomware encrypts ePHI, a breach is presumed unless you can show a low probability that the PHI was compromised. Our guide to ransomware protection covers prevention and recovery.

What about the proposed Security Rule update?

HHS published a proposed rule to strengthen the Security Rule in the Federal Register on January 6, 2025. It would make most implementation specifications mandatory and add explicit requirements such as encryption of ePHI at rest and in transit, MFA, vulnerability scanning and network segmentation. As of this writing it hasn’t been finalized, and the current Security Rule remains in force. Many of the proposed controls are already good practice, so building them in now reduces future rework. Check HHS.gov for the latest status.

Where to start: a step-by-step plan

1. Map your data. Document where PHI enters, where it’s stored, who can access it and where it leaves.
2. Confirm your role. Decide whether you’re a business associate, subcontractor or outside HIPAA, and get legal advice.
3. Sign BAAs. With customers, and with every vendor in your stack that touches PHI.
4. Run a risk analysis. Use HHS guidance and document risks, likelihood, impact and planned fixes.
5. Build technical safeguards. Access control, audit logs, integrity, authentication and encryption.
6. Write policies and train staff. Include incident response and breach notification procedures.
7. Test and repeat. Run restore tests, access reviews and periodic risk analysis updates.

Many health software companies also pursue a SOC 2 report to answer customer security questions. Note that HHS doesn’t certify products as “HIPAA compliant” and doesn’t recognize private HIPAA certifications as meeting your legal obligations.

Conclusion

HIPAA compliance for software is a continuing program, not a badge. Know whether you’re a business associate, sign the right BAAs, base your controls on a real risk analysis, and build access control, audit logging and encryption into the product from the start. Do that, and the compliance questions in your next sales call become easy wins.

This is not legal advice. This is general information, not medical advice.

Sources

• HHS: Summary of the HIPAA Security Rule — safeguard categories, flexibility, risk analysis and compliance dates
• HHS: Summary of the HIPAA Privacy Rule — uses and disclosures, minimum necessary and compliance dates
• HHS: Breach Notification Rule — notification timelines for individuals, HHS and media
• HHS: Business Associate Contracts (sample provisions) — required BAA terms
• HHS: Guidance on HIPAA and Cloud Computing — cloud providers as business associates, including no-view services
• Federal Register: HIPAA Security Rule To Strengthen the Cybersecurity of ePHI (proposed rule, January 6, 2025) — proposed Security Rule changes