The HIPAA Software Checklist: Get It Right

The moment your software touches a patient's name next to their diagnosis, you're handling ePHI, and HIPAA becomes your problem. The risk isn't abstract: a data breach is expensive to fix, slow to recover from, and a HIPAA violation can carry significant civil penalties. Worse, a hospital or payer won't sign with you unless you can prove you built it right. Most teams treat compliance as a "later" problem. That's a mistake. This HIPAA software checklist covers what you need to get right before you launch, so you ship audit-ready instead of scrambling after the fact.

Who this is for (and what it isn't)

This is for founders and CTOs building healthcare software, not for compliance officers drafting policy. We focus on the technical and architectural decisions, the ones that determine whether your product actually holds up, and the ones that are painful and expensive to fix later. If you're evaluating a development partner, this doubles as the list of questions to ask them. If they can't answer every item below, keep looking.

A note on language. "HIPAA-compliant software" is a real standard, but "HIPAA compliant" isn't a certificate you can buy. There is no official HIPAA seal. Compliance is a state you maintain across people, process, and technology. This article is the technology-and-architecture part, the part you have to build yourself.

The law today vs. where it's heading

You need to hold two things in your head at once.

What current law requires. The HIPAA Security Rule currently splits implementation requirements into "required" and "addressable." "Addressable" does not mean optional, it means you must assess whether a safeguard is reasonable and appropriate for your environment, implement it if it is, and document your reasoning if it isn't. Encrypting ePHI is currently addressable under existing law, not strictly mandatory. But in practice, for virtually every modern healthcare app, encryption is entirely reasonable and appropriate, so "addressable" should never be your excuse to skip it.

Where the law is heading. In December 2024, the HHS Office for Civil Rights issued a Notice of Proposed Rulemaking (published January 6, 2025) that tightens the Security Rule considerably. If adopted, it would mandate encryption of ePHI both at rest and in transit (with limited exceptions), remove the required/addressable distinction (every requirement becomes mandatory), and add explicit obligations like multi-factor authentication, continuous monitoring, vulnerability scanning, penetration testing, network segmentation, and annual security-control testing.

Important caveat: as of mid-2026, this is still a proposal. It isn't final, so it isn't law yet. But the direction is unmistakable. Our advice is simple: build to the stricter proposed standard now. That's where the regulation is heading, it's what sophisticated buyers already expect, and honestly it's just good engineering. Retrofitting encryption and MFA onto a live system that already handles ePHI hurts far more than designing for them from day one.

The 12-point pre-launch checklist

Use this checklist before you ship. Each item is something a careful buyer or an auditor will eventually ask about. Get them right early and "compliant by design" stops being a slogan and becomes the actual shape of your system.

1. Sign a BAA with every vendor that touches ePHI. A Business Associate Agreement (BAA) is legally required between a covered entity and any business associate, including your software vendor, that handles ePHI. The obligation flows downstream: your cloud host, logging service, email service, and every subprocessor in the data path needs a BAA. Map everywhere ePHI flows and confirm a signed BAA for each one. A vendor who won't sign isn't part of your stack.
2. Encrypt ePHI at rest and in transit. Use strong, current encryption (TLS 1.2+ in transit, AES-256 at rest is the standard baseline). Yes, this is technically "addressable" under current law, but the proposed rule makes it mandatory, and reasonable practice already treats it as table stakes. Encrypt your database, backups, file storage, and message queues, not just the front door.
3. Apply least-privilege access control. Every user, service, and process should have the minimum access needed to do its job, and no more. Implement role-based access control, review permissions on a schedule, and revoke access the moment someone leaves or changes roles. Broad, stale admin rights are one of the most common findings in a real audit.
4. Enforce multi-factor authentication. MFA is one of the highest-leverage controls you can ship, and the proposed rule makes it a baseline expectation. Require it for all administrative access and any account that can touch ePHI. Treat it as non-negotiable, not a setting users can switch off.
5. Build a complete, tamper-resistant audit trail. You must be able to answer "who accessed which record, when, and what did they do." Log access, creation, reads, edits, and deletes on ePHI. Make the logs immutable or at least tamper-evident, store them securely, and retain them long enough to support investigation and reporting. An audit log you can quietly edit isn't an audit log.
6. Practice data minimization. Collect and retain only the ePHI you genuinely need. Every redundant field and unnecessary copy expands your breach surface and your liability. Define retention periods and actually enforce deletion. Data you never store can't be stolen.
7. Secure and test your backups. Backups must be encrypted, access-controlled, and, most importantly, restorable. Run a real restore drill. A backup you've never tested is a hope, not a recovery plan. Check that backups don't leak ePHI into a less-protected environment.
8. Segment your network and isolate ePHI. Separate systems that handle ePHI from those that don't. Network segmentation, named explicitly in the proposed rule, limits how far an attacker can move if one component is compromised. Don't run your marketing site and your patient data store on the same flat network.
9. Scan, patch, and pentest on a schedule. The proposed rule names vulnerability scanning and penetration testing for a reason. Automate dependency and vulnerability scanning in CI, patch on a defined cadence, and run an independent pentest before launch and periodically after. The vulnerability you don't find is the one that finds you.
10. Monitor continuously and alert on the right things. Detection matters as much as prevention. Set up continuous monitoring, with alerts for anomalous access, spikes in failed logins, privilege escalation, and unusual data exports. The faster you detect, the smaller the breach and the shorter the disclosure clock.
11. Be ready for breach notification before you need it. Have a written incident-response plan: who does what, how you assess scope, and how you meet HIPAA's breach-notification obligations. Know your timelines and contacts in advance. The middle of an incident is the worst time to start looking for a process.
12. Document everything, because compliance you can't prove doesn't count. Risk assessments, data-flow diagrams, access reviews, BAAs, encryption decisions, incident-response plans. If it isn't written down, an auditor will treat it as if it never happened. That unglamorous pile of documentation is exactly what turns "we think we're compliant" into "here's the evidence."

A note on AI in healthcare software

If your product uses AI, the bar goes up, not down. A model can hallucinate, leak data into a prompt, or take an action no one reviewed. That's why our Kite framework treats the model as untrusted by default: deterministic rules run first, the model operates inside guardrails, and there's always a human in the loop for anything consequential. In a HIPAA context, that's not a nice-to-have, it's how you keep an unpredictable component from becoming your weakest link. If a vendor wires an LLM straight into patient data without these constraints, that's a red flag.

How BeevR approaches HIPAA software development

We build HIPAA-compliant healthcare software to be audit-ready from day one, not patched toward compliance after launch. That means the checklist above is the starting point of a project, not an afterthought. Our model removes the familiar friction: fixed price and fixed timeline locked in the SOW so there are no surprise invoices, and you own 100% of the code, infrastructure, and IP from day one. A senior-only, founder-led team works directly with you, no PM wall between you and the people making technical decisions. Our philosophy is reliable over impressive, and in healthcare, that's the only philosophy that survives contact with an auditor. See what we do for the full picture of how we work.

HIPAA software development is mostly the discipline of building the unglamorous 99%, access control, audit logs, tested backups, so the clever 1% of your product can actually live in production.

Conclusion

Compliance isn't a phase you bolt on at the end. The decisions that determine whether your software holds up, encryption, access control, auditability, network design, are all architectural, and they're expensive to reverse. Use this checklist while the choices are still cheap. Build to the stricter proposed standard now, document as you go, and you'll walk into buyer security reviews and audits with evidence instead of excuses.

If you're building healthcare software and want it audit-ready from day one, that's exactly what we do. Book a consultation and we'll walk through your specific architecture and where the real risk sits.