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 business associate, review the function or service and the exceptions in 45 CFR 160.103. A person that meets the business-associate definition is subject to applicable HIPAA duties. The classification depends on the role and facts, not merely on a software category or the presence of health-related data.

Business associates have direct liability for specified HIPAA requirements. Under 45 CFR 164.410, a business associate must notify the affected covered entity of a breach without unreasonable delay and no later than 60 days after discovery. Covered entities separately evaluate notice duties under 164.404 and related provisions. The generator translates selected safeguards into concrete questions, marks reported controls, and identifies items for follow-up.

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 facility access, workstation use and security, and device or media controls. Cloud services may address part of the infrastructure, but each regulated organization must evaluate the physical safeguards applicable to its own devices, facilities, people, and arrangements.

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 tools can miss systems or workflows outside the initial scope. The checklist therefore treats a documented risk analysis and a separate risk-management process as distinct controls.

Software data-flow scenarios to review

A data-flow review should include logs, error trackers, analytics events, crash reports, and screenshots. A debug line or captured request body can move PHI into a system that was not included in the risk analysis or vendor inventory. If a service handles ePHI on the organization's behalf, determine whether the relationship meets the business-associate definition and whether written assurances are required.

Non-production environments also belong in scope when they contain ePHI. Prefer synthetic or properly de-identified data when production PHI is unnecessary. If PHI is used, evaluate that environment's access, logging, encryption, retention, and vendor relationships just as the risk analysis requires. Classify email, messaging, error-tracking, queue, and AI services by function instead of assuming every service is or is not a business associate.

Business associate agreements down the whole chain

For a cloud relationship, first determine whether the provider creates, receives, maintains, or transmits ePHI on the organization's behalf and whether an exception applies under 45 CFR 160.103. If the provider is a business associate, obtain the required agreement before placing ePHI in scope and confirm which services the agreement covers. The generator excludes a cloud-provider BAA item for self-managed or on-premise hosting.

If a business associate delegates a function or service involving PHI to a subcontractor, 45 CFR 164.504(e)(5) requires the same restrictions and conditions to apply to that subcontractor. Maintain an inventory of vendor functions, data handled, classification decisions, agreements, and review dates. A customer is not a subcontractor merely because it uses the software. If an agreement is required, the linked BAA generator can produce a draft based on HHS sample provisions.

Building the safeguards into the system

Technical safeguards translate several HIPAA standards into system controls. Access control includes unique user identification and access decisions that limit ePHI to authorized users and functions. Service identities and least-privilege design can support those controls. Authentication under 164.312(d) requires procedures to verify identity. Multi-factor authentication can be a reasonable risk-based control, but HIPAA does not name it as a universal requirement. Audit controls require mechanisms that record and examine activity in systems containing or using ePHI.

Encryption at rest under 164.312(a)(2)(iv), transmission encryption under 164.312(e)(2)(ii), and automatic logoff under 164.312(a)(2)(iii) are addressable specifications. Under 164.306(d), the organization evaluates whether each specification is reasonable and appropriate, documents the decision, and implements an equivalent measure when reasonable and appropriate if the specification is not implemented. Integrity controls address improper alteration or destruction. The checklist keeps access control, authentication, audit controls, encryption decisions, and logoff decisions as separate lines so one checkbox does not prove multiple controls.

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 non-production environments where production PHI is unnecessary, 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. Pre-release data-flow and vendor review can identify a debug path or third-party service before it begins handling ePHI.

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 can own encryption configuration, infrastructure access, audit logging, backups, and the incident response runbook. Legal, privacy, procurement, and technical owners can jointly classify vendor relationships and manage required agreements. 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.

The Security Rule requires a security awareness and training program for all workforce members, including management. Role-relevant examples can help engineers, DevOps staff, product teams, and support workers recognize when a new log, ticket, build, or analytics service changes how ePHI is handled. That handling can create risk outside the controls originally reviewed for the production system.

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 behalf of a business associate, determine whether it is a business-associate subcontractor under 45 CFR 160.103 and whether the required written assurances apply. A service can also fall within a regulatory exception, so classify the function and relationship rather than the product label alone.

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 can disclose PHI to that provider. Before routing ePHI to a model, classify the relationship, obtain any required agreement, verify the covered service and retention terms, and include the workflow in the risk analysis. Properly de-identifying the input under 45 CFR 164.514 may change HIPAA scope, but removing a name alone is not sufficient.

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.

Each review should leave dated records of scope, decisions, findings, owners, and follow-up. A current risk analysis, maintained vendor inventory, applicable training records, and tracked checklist items document different parts of the program. They do not by themselves establish compliance or predict an enforcement outcome.

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, required agreements with classified business associates and subcontractors, breach procedures, and an applicable workforce training program. The checklist turns selected provisions into a finite list of reported controls and follow-up items.

When you generate your checklist, investigate the priority items first, then turn each remaining TODO into a ticket. Training is one required administrative safeguard, and a signed agreement or access policy still depends on people who recognize protected health information and follow the relevant procedure. The Security Rule program applies to all workforce members. Add role-relevant examples for engineers, DevOps staff, product teams, and support teams, and retain the required records.