Get a HIPAA compliance checklist built for your software.

Who this checklist is for

This checklist is for the people who build and operate software that touches protected health information: software engineers, DevOps and platform teams, product managers, QA, and the support staff who see customer data while they work. If your product creates, receives, maintains, or transmits electronic protected health information for a covered entity, or for another business associate, then you are a business associate under HIPAA, and the Security Rule applies to your systems. That status is not about the size of your company or whether you call yourself a health-tech startup. It is about whether protected health information flows through your code, your databases, your logs, and your vendors.

Since the HITECH Act, business associates are directly liable to the Office for Civil Rights for many HIPAA requirements. A breach at your company is your problem to report, your cost to absorb, and your name in the resolution agreement. The practical job, then, is to turn HIPAA from legal copy into product, infrastructure, vendor, and workforce decisions an engineer can actually check off. That is what this generator does: it converts the Security Rule into a list of concrete controls, marks the ones you already have, and tells you which gaps to close first.

How the Security Rule translates into engineering work

The Security Rule is organized into three groups of safeguards, and each one maps to work a software team recognizes. Administrative safeguards at 45 CFR 164.308 are the program: a documented risk analysis, a risk management process, a named security official, workforce training, incident response, and a contingency plan with tested backups. Technical safeguards at 45 CFR 164.312 are the controls in the system itself: unique user identities, access control, audit logging, integrity protections, authentication, and transmission security. Physical safeguards at 45 CFR 164.310 cover the devices and facilities, which for a cloud-hosted product mostly flow through your provider and your laptop and mobile device policies.

The risk analysis sits at the center of all of it. HHS guidance is explicit that the risk analysis is foundational and must cover all electronic protected health information your organization touches, in every form and every system. You cannot decide which safeguards are reasonable and appropriate until you know where the data lives, who can reach it, and what could go wrong. A team that skips the risk analysis and jumps straight to buying tools usually ends up with strong controls in the obvious places and gaping holes in the ones no one mapped. The checklist starts there for a reason, and it is the first item flagged as a priority when you have not done it.

The gaps that cause real breaches

Most HIPAA problems in software teams do not come from exotic attacks. They come from a handful of ordinary engineering shortcuts that quietly move protected health information somewhere it was never supposed to be. The most common is PHI in logs. A developer adds a debug line, an error handler dumps a full request body, an analytics event captures a field it should not, and now protected health information sits in a log aggregator, an error tracker, or a third-party analytics platform that was never scoped as PHI storage and may not even be covered by a business associate agreement. The data is replicated, retained, and exposed to everyone who can read the logs.

The second common gap is production data in non-production environments. Copying a slice of the real database into staging to reproduce a bug feels harmless, but those environments rarely carry the same access controls, encryption, and logging as production. A test environment full of real patient records is a breach waiting for a misconfiguration. The fix is to use synthetic or properly de-identified data, which the checklist treats as a priority. The third is the missing business associate agreement, especially with the small vendors. Teams remember to sign a BAA with the big cloud provider and forget the email service, the SMS gateway, the error tracker, the queue, and the AI API that all see protected health information in passing. Each of those is a subprocessor that needs an agreement, and the absence of one is exactly the kind of finding that turns a breach investigation into a penalty.

Business associate agreements down the whole chain

If your software runs on Amazon Web Services, Google Cloud, or Microsoft Azure, you sign that provider's business associate agreement before any protected health information lands there, and you stay inside the provider's published list of HIPAA-eligible services. All three offer a BAA and document which services it covers. Using a service outside that list, or skipping the agreement, leaves the data without the contractual protection HIPAA requires. The generator produces this item automatically based on the hosting provider you choose, because it is both common and easy to miss.

The agreement obligation does not stop at the cloud provider. Every subprocessor that creates, receives, maintains, or transmits protected health information on your behalf needs a signed BAA, and the rule requires you to flow the same restrictions down to anyone further along the chain. The way to stay ahead of this is a living inventory: every vendor that touches PHI, the data it sees, the date of its agreement, and the renewal status. When you operate as a business associate to your own customers, you are also on the other side of these agreements, owing the same assurances upstream that you demand downstream. If you need to produce one of these agreements, the BAA generator linked below builds a draft from the HHS sample provisions.

Building the safeguards into the system

Technical safeguards are where engineering does most of its visible HIPAA work. Access control means unique identities for every user and service, least privilege so people and systems can reach only the protected health information they need, and no shared logins to production. Authentication means multi-factor everywhere that can reach ePHI, including admin consoles and infrastructure. Audit controls mean you record who accessed protected health information, when, and what they did, and that someone actually reviews those logs rather than letting them pile up unread.

Encryption appears twice. At rest, the Security Rule treats encryption as addressable, which does not mean optional. It means you either implement it or document why an equivalent safeguard is reasonable and appropriate for your situation, and for ePHI in a modern cloud stack encryption at rest is almost always the reasonable answer. In transit, you encrypt protected health information everywhere it crosses a network, and that includes internal service-to-service calls, not only the public edge. Integrity controls protect the data from being altered or destroyed without detection, and automatic logoff closes sessions that display ePHI when a user walks away. None of these is exotic. The work is making sure they are on consistently, including in the corners of the system that grew up fast and never got reviewed.

A secure software development lifecycle

The safeguards above describe the running system. A secure software development lifecycle describes how you keep it that way as the code changes. Minimum necessary is an engineering principle as much as a privacy one: APIs, reports, and data exports should return only the fields a task requires, not the whole patient record because it was easier to select everything. Code review and security testing belong in front of any release that touches protected health information, and the records of those reviews are part of the evidence you keep. Secrets and keys live outside source control, get rotated, and stay off developer laptops, so a leaked repository or a stolen machine does not hand someone the keys to production.

The discipline that ties the lifecycle together is keeping protected health information out of the places it does not belong. That means log scrubbing and field-level redaction before data leaves a request, de-identified or synthetic data in every non-production environment, and a habit of asking, for each new tool a team adopts, whether it will see PHI and whether there is an agreement covering it. The cheapest time to catch these issues is in review, before the shortcut ships. The most expensive time is during a breach investigation, when an auditor finds the debug line that has been writing records to a third-party service for eight months.

What each part of the team owns

HIPAA compliance for software is not one team's job. Engineering owns the technical safeguards in the code, the minimum-necessary discipline in APIs, and keeping PHI out of logs and test environments. DevOps and platform teams own the cloud BAA, encryption configuration, access control to infrastructure, audit logging, backups, and the incident response runbook. Product and QA own the decisions about what data the product collects in the first place, the use of safe test data, and the minimum-necessary choices baked into features. Support owns the daily handling of customer data, the verification of who is on the other end of a request, and fast escalation when something looks like an exposure.

What every one of these roles shares is the need to recognize protected health information and know what to do when they are about to move it, store it, or send it somewhere new. That recognition is what training builds, and it is the control the checklist closes with. The technical safeguards stop working the moment a well-meaning engineer pastes a record into a support ticket, ships a debug build that logs request bodies, or spins up a new analytics tool without checking the agreement. The system can only be as careful as the people changing it.

Where third-party APIs and AI services fit

Modern products lean on outside services for things teams used to build themselves, and each one is a place protected health information can quietly travel. Email and SMS providers, payment processors, customer messaging widgets, observability platforms, search services, and the growing list of AI and large language model APIs all sit in the path of real data. The rule does not change because a vendor is fashionable or because the integration took ten minutes. If the service creates, receives, maintains, or transmits ePHI on your behalf, it is a subprocessor, it needs a business associate agreement, and using it without one is the same gap as any other missing BAA.

AI services deserve a specific look because the failure mode is easy to miss. Sending a patient note, a support transcript, or a record to a model endpoint to summarize or classify it is a disclosure of protected health information, and many general-purpose AI APIs will not sign a BAA or will only cover specific enterprise tiers. Before routing ePHI to any model, confirm the vendor offers a business associate agreement, that the data is not retained or used for training, and that the endpoint sits inside the covered service list. When in doubt, de-identify the input first or keep the call out of the PHI path entirely. The checklist surfaces the subprocessor inventory as a priority precisely because these integrations multiply faster than anyone tracks them.

Keeping the checklist current

A checklist captures a moment, and software changes faster than a moment. The point is not to generate it once and file it. Tie a refresh to the events that actually move your risk: a new vendor that will see ePHI, a new environment or region, a major feature that changes what data you collect, a move between cloud services, or an incident that taught you something. At minimum, revisit the risk analysis and the checklist on a regular cadence, and update both whenever the system changes in a way that touches protected health information. Each pass should leave a short record of what was checked, what changed, who owns the open items, and when the next review is due.

The discipline pays off most when something goes wrong. If you can show an investigator a current risk analysis, a maintained vendor inventory, dated training records, and a checklist that turned gaps into tickets with owners, you are demonstrating the documented, good-faith program the rules expect. A team that can produce that history is in a far stronger position than one scrambling to reconstruct it after a breach.

From checklist to a real program

A checklist is a starting point, not a finish line, and no checklist makes you compliant on its own. Be skeptical of any vendor selling a badge that claims your software is HIPAA certified, because there is no government HIPAA certification for software. Compliance is an ongoing program: a documented risk analysis you keep current, the safeguards this checklist covers, signed agreements with every vendor in the chain, breach procedures you have actually rehearsed, and a workforce that knows the rules. The value of the checklist is that it turns a sprawling regulation into a finite list of gaps with owners and due dates.

When you generate your checklist, work the priority gaps first, then turn each remaining TODO into a ticket. Of all the items, the fastest to close and the one regulators ask about first is training. A signed agreement and a strong access policy still depend on people who recognize protected health information and handle it correctly under pressure. Certifying the engineers, DevOps staff, and support team who touch ePHI produces the documented, good-faith record that backs everything else on the list. Build the checklist here, close the gaps, and certify the people who keep the system honest.