HIPAA Compliance Checklist for Software and Healthcare Apps
This HIPAA compliance checklist for software gives development teams, product owners, and healthcare buyers a practical way to confirm that an application supports HIPAA requirements before PHI goes live. It covers administrative, physical, and technical safeguards, business associate agreements, breach readiness, and the development practices that keep software secure over time. Use it to evaluate a product you're building, buying, or inheriting. Custom Healthcare Solutions uses the same checklist on every project and can run it against your application in a short assessment.
Administrative Safeguards Checklist
Administrative safeguards are the policies and processes that govern how PHI is protected. They're often overlooked by software teams, but auditors and OCR investigators ask about them first. Risk analysis failures, in particular, have been a recurring focus of OCR enforcement. Each item below should be documented, owned by a named person, and reviewed at least annually. Our healthcare compliance and security page shows how we handle these for the software we build.
Risk Analysis Completed and Current
A documented risk analysis covers the application, its hosting, integrations, and data flows. It's updated after major releases, new integrations, or infrastructure changes, not completed once at launch and shelved.
Security Official Assigned
A named person is responsible for security policies and their enforcement. For software vendors, this is often a security lead who owns the risk register, incident response, and access reviews.
Workforce Training and Sanctions
Everyone with PHI access, including developers and support staff, completes HIPAA training. Written sanctions policies define consequences for violations, and training records are kept as evidence for audits and investigations.
Contingency Plan Tested
Data backup, disaster recovery, and emergency mode operation plans exist and are tested. Restore tests confirm backups actually work, and recovery time objectives are documented and realistic for each critical system.
Technical Safeguards Checklist
Technical safeguards are where software teams have the most direct control. These requirements come from the HIPAA Security Rule and apply to every system that creates, receives, stores, or transmits electronic PHI. Check each item against the application's actual behavior, not its design documents, because configuration drift and quick fixes often weaken controls that were originally built correctly. Test in an environment that mirrors production as closely as possible.
Access Control
Each user has a unique ID, roles limit access to minimum necessary PHI, and emergency access procedures exist. Automatic logoff ends idle sessions, and multi-factor authentication protects privileged and remote access.
Audit Controls
The application logs views, creation, changes, exports, and deletions of PHI with user and timestamp. Logs are protected from tampering, retained according to policy, and reviewed on a defined schedule. See our guide to audit logging requirements.
Integrity Controls
Mechanisms detect unauthorized alteration or destruction of PHI, such as checksums, database constraints, and change logging. Backups are protected from modification, including ransomware, through immutable or isolated copies where possible.
Transmission and Storage Encryption
All connections use TLS 1.2 or higher, and PHI is encrypted at rest in databases, file storage, and backups. Keys are stored separately from data and rotated according to policy. Our PHI encryption best practices go deeper.
Physical and Organizational Safeguards Checklist
Physical safeguards protect the facilities and devices where PHI lives, while organizational requirements cover the agreements that extend responsibility to vendors. For cloud-hosted software, much of the physical layer is handled by your hosting provider, but only under a signed agreement and only for covered services. Your team remains responsible for workstations, mobile devices, and every vendor that touches PHI. These items are easy to miss in software projects.
Hosting Provider BAA and Eligible Services
Your cloud provider has signed a BAA, and every service storing or processing PHI appears on the provider's HIPAA-eligible services list. Unlisted services should never touch PHI under any circumstances. Learn more about HIPAA compliant cloud hosting.
Workstation and Device Security
Laptops and mobile devices used by staff or developers with PHI access have disk encryption, screen locks, current patches, and remote wipe. Policies cover lost or stolen devices and reporting timelines.
Vendor BAAs for Every Integration
Every third party that handles PHI, including email, SMS, analytics, support, and monitoring tools, has a signed BAA. A vendor inventory tracks agreements, renewal dates, and review status for each one. Here's what to look for in a BAA.
Media Disposal and Data Retention
Retention periods are defined, and PHI is securely deleted when no longer needed. Decommissioned storage, backups, and test environments are wiped using documented methods, with disposal records kept as evidence.
Breach Readiness and Secure Development Checklist
HIPAA's Breach Notification Rule requires notifying affected individuals without unreasonable delay and no later than 60 days after discovering a breach, with additional notice to HHS and, for larger breaches, the media. Meeting those deadlines requires preparation before an incident happens. Secure development practices reduce the chance of a breach in the first place. Our HIPAA compliance assessment pricing page explains how we scope a checklist review of your software.
Incident Response Plan
A written plan defines how security incidents are detected, escalated, investigated, and documented. Roles, contact lists, and decision criteria for breach risk assessment are current and known to the team before an incident occurs.
Breach Risk Assessment Process
The team can apply HIPAA's four-factor risk assessment to determine whether an incident is a reportable breach. Encrypted data meeting HHS guidance may qualify for the breach notification safe harbor.
Secure SDLC Practices
Code reviews, dependency scanning, secrets management, and security testing are routine. Production PHI never appears in development or test environments, and synthetic data is used for all testing and demos.
Penetration Testing and Remediation
An independent penetration test is performed before launch and at least annually. Findings are tracked to remediation with deadlines based on severity, and retests confirm fixes actually work as intended.
Related Compliance Guides
More on building and proving compliance in healthcare software.
HIPAA Compliant Software Development
Risk analysis, secure architecture, BAAs, and audit-ready documentation from day one.
Custom Healthcare Compliance Solutions
Software that automates risk assessments, access reviews, policy tracking, and audit evidence.
SOC 2 for Healthcare Software
Type I vs Type II, Trust Services Criteria, and how SOC 2 relates to HIPAA.
Frequently Asked Questions About HIPAA Compliance for Software
What should a HIPAA compliance checklist for software include?
It should cover administrative safeguards like risk analysis and training, technical safeguards such as access control, audit logging, integrity, and encryption, physical safeguards for hosting and devices, business associate agreements, breach notification readiness, and secure development practices. Each item should be verified against the application's actual behavior, not just documentation.
Is encryption required by HIPAA?
Under the current Security Rule, encryption is an addressable specification, meaning you must implement it or document why an equivalent alternative is reasonable. In practice, encryption is expected. HHS proposed in January 2025 to make it required, and properly encrypted data can qualify for breach notification safe harbor.
How often should we review HIPAA compliance for our software?
Review at least annually, and whenever you make significant changes such as new integrations, hosting changes, major releases, or new types of PHI. Risk analysis, access reviews, and penetration tests should follow a documented schedule, with evidence retained so you can demonstrate ongoing compliance during audits.
Who is responsible for HIPAA compliance, the software vendor or the healthcare organization?
Both. Covered entities are responsible for their HIPAA compliance, including how they use software. Vendors handling PHI are business associates, directly liable for Security Rule compliance and their BAA obligations. The BAA divides responsibilities, but neither party can shift all compliance obligations to the other.
Can you audit our existing application against this checklist?
Yes. A checklist assessment reviews your application's safeguards, hosting, integrations, and development practices, then produces a prioritized list of gaps with remediation recommendations. It's useful before a security review, customer audit, or funding round, and it gives your team a clear starting point for fixes.
Find Your Gaps Before an Auditor Does
Request a HIPAA checklist assessment, explore our healthcare software development services, or visit the Custom Healthcare Solutions homepage.