HIPAA Compliance Checklist for Software: Requirements and Best Practices
"HIPAA compliant" is a phrase that gets used loosely and understood precisely far less often. There's no single certificate you earn and move on from; compliance is an ongoing set of administrative, physical, and technical safeguards. Here's what actually needs to be in place.
Every safeguard exists to protect one signal: ePHI in motion and at rest.
What HIPAA compliance means for software
HIPAA, the Health Insurance Portability and Accountability Act, protects Protected Health Information (PHI) and its electronic form, ePHI. The Privacy Rule governs how PHI can be used and disclosed. The Security Rule specifically addresses how electronic PHI must be protected, and it's the Security Rule that matters most for software teams.
A HIPAA compliance checklist for software is a framework for that analysis, not a fixed list of products to install.
Who needs HIPAA-compliant software
Covered entities
Healthcare providers, health plans, and clearinghouses that handle PHI directly.
Business associates
Any vendor, including a software company, that handles PHI for a covered entity. If your software stores, processes, or transmits PHI for a healthcare client, you're very likely one, and the requirements apply to you, not just your client.
The HIPAA compliance checklist for software
Administrative safeguards
01 to 05Conduct a formal risk analysis.
The foundation everything else is built on: you can't safeguard PHI without first identifying where it lives, how it flows, and where it's vulnerable.
Establish a risk management program.
A risk analysis without a follow-up plan to address findings doesn't satisfy the requirement; it just documents the gaps.
Assign a security officer.
Someone needs to own HIPAA compliance documentation and decisions, not treat it as everyone's part-time responsibility.
Write and maintain security policies.
Actual documented policies, not informal team knowledge, covering access, incident response, and data handling.
Train your workforce.
Anyone with access to PHI needs training on what that access requires of them, not just at onboarding but on an ongoing basis.
Physical safeguards
06 to 07Control physical access to systems.
Even cloud-first, this extends to how your infrastructure providers secure their data centers and how your own team's devices are secured.
Manage device and media disposal.
Old drives, backups, and decommissioned hardware need documented, secure disposal processes.
Technical safeguards
08 to 12Implement access control.
Every user gets the minimum access necessary for their role, nothing broader, the principle behind role-based access control.
Enable audit controls and audit logging.
A recorded, tamper-evident trail of who accessed what PHI, and when, useful both for detecting an incident and for demonstrating compliance.
Enforce strong authentication.
Multi-factor authentication for anyone touching ePHI is now close to a baseline expectation, not an advanced feature.
Encrypt data at rest and in transit.
Not a fixed algorithm mandate, but the standard practical answer to the Security Rule's transmission and integrity requirements.
Protect data integrity.
Build in mechanisms to detect whether ePHI has been improperly altered or destroyed, not just whether it's been accessed.
Vendor and contract requirements
13Sign a Business Associate Agreement (BAA) with every relevant vendor.
If a cloud provider, analytics tool, or any third-party service touches PHI, a signed BAA needs to exist before that integration goes live, not after.
Operational readiness
14 to 15Build backup, disaster recovery, and incident response plans.
Contingency planning is an explicit requirement: an incident response plan needs to exist before an incident happens, not get drafted during one.
Review and update continuously.
Not a one-time launch checklist. Risk analysis, policies, and safeguards need periodic review as your software, infrastructure, and threat landscape change.
Building software that touches patient data?
Get these safeguards designed into your architecture from day one, not retrofitted before launch.
Talk to Our Healthcare Software TeamHIPAA compliance across different software types
The checklist above applies broadly, but how it's implemented shifts depending on what you're building.
What a HIPAA risk analysis actually involves
Since risk analysis is the requirement everything else depends on, it's worth being concrete about what it covers rather than treating it as an abstract first step.
Identify every system
Not just the obvious database: logging, backups, analytics pipelines, third-party integrations.
Evaluate threats
Likelihood and impact for each system, from a stolen laptop to a misconfigured bucket to an unpatched dependency.
Prioritize gaps
The output isn't a pass or fail grade; it's a prioritized list of what needs fixing first.
Feed risk management
Gaps flow directly into the risk management step, the follow-up plan that makes the analysis count.
Teams that skip this step, or do it once at launch and never again, are the ones most likely to discover a compliance gap during an actual incident rather than before one.
Common HIPAA compliance mistakes
Treating HIPAA as a one-time certification
There's no HIPAA certificate issued by HHS. Any vendor claiming to "certify" your software is describing their own assessment, not a government credential.
Skipping the BAA with a subprocessor
It's common to sign a BAA with a primary vendor and forget a downstream service they rely on also touches PHI and needs its own agreement.
Confusing encryption with full compliance
Encryption is necessary, not sufficient. Access controls, audit logging, training, and incident response all matter just as much.
Under-scoping the risk analysis
Covering only the production database and missing logging, backups, or third-party integrations creates a false sense of completeness.
No real incident response plan
Many teams have a policy document that's never been tested. A plan nobody has walked through under pressure isn't a plan yet.
Assuming compliant infrastructure means a compliant app
AWS, Azure, and GCP will sign a BAA, but the application built on top still needs its own access controls, encryption, and audit logging.
Seaflux's approach to HIPAA-compliant software
Seaflux builds HIPAA-compliant software development into projects from the architecture stage, not as a retrofit before launch. Our healthcare software development company work covers HIPAA-compliant app development for telehealth platforms, patient portals, and clinical data systems, with access controls, audit logging, and encryption designed in from the start.
HIPAA-compliant AWS cloud migration for cancer diagnostics
Zero-trust security architecture combined with regulatory compliance for a clinical workflow where neither could be compromised.
RAG-powered chatbot for medical diagnosis support
How AI-powered healthcare tools can be built with the same compliance discipline as any other clinical system.
Weighing HIPAA compliance alongside a larger software build?
Our team designs access control, audit logging, and encryption in from the start, so compliance isn't a scramble before launch.
Talk to Our Healthcare Software TeamFrequently Asked Questions (FAQ): Get the Answers You Need
What are the main HIPAA compliance requirements for software?
Software handling PHI needs administrative safeguards like risk analysis and workforce training, physical safeguards for device and facility security, and technical safeguards including access control, audit logging, encryption, and authentication. A signed Business Associate Agreement is also required with any vendor that touches PHI.
Is there an official HIPAA certification for software?
No. HHS does not issue a HIPAA certification. Any vendor offering to "certify" software as HIPAA compliant is describing their own internal assessment process, not a government credential. Compliance is demonstrated through documented policies, safeguards, and risk management, not a single certificate.
Does encryption alone make software HIPAA compliant?
No. Encryption is one required safeguard among many. Access controls, audit logging, workforce training, risk analysis, and a signed Business Associate Agreement with relevant vendors are all part of the same requirement, not optional extras.
Do I need a Business Associate Agreement for every vendor?
Yes, for any vendor or subprocessor that creates, receives, maintains, or transmits PHI on your behalf, including cloud providers, analytics tools, and any downstream service a primary vendor relies on.
How often should a HIPAA risk analysis be updated?
Regularly, and any time your software, infrastructure, or data flows change meaningfully. A risk analysis done once at launch and never revisited does not reflect an evolving system or threat landscape.
Krunal Bhimani
Business Development Executive