HIPAA Software Development Checklist 2025
Building HIPAA compliant software requires systematically addressing dozens of security and compliance requirements across encryption, access controls, audit logging, backup, vendor management, and security testing. This checklist provides a practical, technical roadmap for development teams building healthcare applications in 2025.
This checklist is organized by domain. Each item references the underlying HIPAA requirement and provides implementation guidance. It covers both web and mobile application development contexts. Use it during architecture review, sprint planning, and pre-launch security assessments.
Encryption Requirements
Encrypt all ePHI at rest using AES-256 (minimum AES-128)
Databases, file storage, backups, and log archives containing PHI must all be encrypted at rest. Cloud storage buckets (S3, Azure Blob, GCS) must have server-side encryption enabled. Database encryption should use Transparent Data Encryption (TDE) or equivalent.
Enforce TLS 1.2 minimum (TLS 1.3 preferred) for all ePHI in transit
Disable TLS 1.0 and TLS 1.1 entirely. Configure strong cipher suites (forward secrecy required). Implement HSTS (HTTP Strict Transport Security) with a long max-age. Regularly audit TLS configuration with tools like SSL Labs.
Implement customer-managed encryption keys (CMEK) for high-sensitivity workloads
Cloud provider default encryption uses keys the provider manages — the provider can technically access your data. For maximum PHI protection, use customer-managed keys via AWS KMS, Azure Key Vault, or Google Cloud KMS with automated rotation policies.
Encrypt local storage on mobile devices using device-derived keys
Mobile apps that store any ePHI locally must encrypt that data using keys derived from the device's secure hardware (Secure Enclave on iOS, StrongBox / Keystore on Android). Never store encryption keys alongside encrypted data.
Use certificate pinning on mobile apps to prevent MITM attacks
Certificate pinning binds your app to a specific TLS certificate or public key, preventing attackers from intercepting traffic using fraudulent certificates. Implement with a backup pin and a pin update mechanism to handle certificate rotation.
Encrypt ePHI in application logs — or exclude PHI from logs entirely
Logging PHI to plaintext log files is one of the most common HIPAA violations in software. Either exclude PHI from logs (preferred) or encrypt logs at the storage layer and redact PHI fields before writing to centralized logging systems.
Access Controls
Assign unique user IDs — no shared accounts with PHI access
HIPAA requires unique user identification for every person or system accessing ePHI. Shared accounts make audit trails impossible. Service accounts must also have unique, non-shared credentials with least-privilege permissions.
Implement role-based access control (RBAC) with least-privilege enforcement
Users should access only the PHI required for their role. A billing clerk should not have access to clinical notes. A developer should not have access to production PHI. Define roles carefully, audit memberships regularly, and automate deprovisioning.
Enforce multi-factor authentication (MFA) for all PHI system access
Password-only authentication is insufficient for systems containing PHI. Implement MFA (TOTP, FIDO2/WebAuthn, or SMS as fallback) for all user-facing systems, administrative portals, cloud consoles, and developer tools with PHI access.
Implement automatic session timeouts and inactivity lockouts
HIPAA requires automatic logoff after a period of inactivity (addressed specification). Industry standard is 15 minutes for clinical workstations, shorter for high-risk contexts. Mobile apps should also lock after inactivity and require re-authentication.
Build emergency access (break-glass) procedures with mandatory post-access review
HIPAA requires a procedure for obtaining ePHI in emergencies even when normal access controls are unavailable. Implement a break-glass mechanism that grants elevated access but triggers mandatory post-access review and notifications to the Privacy Officer.
Implement and test user deprovisioning workflows
Terminate access immediately upon employee separation or role change. Automate deprovisioning through identity management systems. Test that deprovisioning actually removes access — former-employee access to PHI is a frequent compliance failure and breach cause.
Audit Logging
Log every PHI access, modification, and deletion event
Audit logs must capture: who accessed the record (user ID), what they did (read/write/delete), when (timestamp with timezone), what record was accessed (record ID, not PHI content), and from where (IP address, device). This is a required HIPAA Security Rule specification.
Store audit logs in write-once, tamper-evident storage
Audit logs must be protected from modification or deletion. Use WORM (Write Once Read Many) storage — S3 Object Lock, Azure Immutable Blob Storage, or equivalent. Implement cryptographic log signing (hash chains) for additional tamper detection.
Retain audit logs for a minimum of 6 years
HIPAA requires documentation retention for 6 years from creation or last effective date. Implement automated lifecycle policies that move logs to low-cost archive storage (Glacier, Archive tier) after a defined period while maintaining required retention.
Restrict audit log access to authorized security personnel only
Audit logs containing access records should themselves be access-controlled. Regular users, developers, and application service accounts should not have the ability to read, modify, or delete audit logs. Implement separate IAM roles for audit log management.
Implement real-time alerting for anomalous PHI access patterns
Beyond storing logs, implement active monitoring with alerts for unusual patterns: bulk PHI downloads, access at unusual hours, repeated failed authentication attempts, access to records outside a user's normal scope. SIEM tools like Splunk or OpenSearch Dashboards support this.
Test audit log completeness — verify all events are captured
Many developers assume their logging captures everything — and are wrong. Conduct regular tests by performing PHI access actions (read, write, delete) and confirming the expected log events appear. Include audit log coverage in security testing.
Backup & Availability
Implement automated encrypted backups for all PHI data stores
Backups must be encrypted (same or higher standard as production). Automate daily backups with configurable retention (e.g., 30 daily, 12 monthly, 7 yearly). Verify backup encryption keys are stored separately from backup data.
Test backup restoration — verify backups are actually usable
Untested backups are not backups. Schedule regular restoration tests (quarterly minimum) to verify that backups can be restored to a functional state. Document the test results. Ransomware attacks regularly expose the fact that backups were never tested.
Implement point-in-time recovery for databases
Beyond nightly backups, enable database point-in-time recovery (PITR) to restore to any moment within the retention window. This is critical for recovering from accidental data deletion or corruption without losing significant data.
Document and test your disaster recovery (DR) plan
HIPAA requires a contingency plan including data backup, disaster recovery, and emergency mode operation. Define your RTO (Recovery Time Objective) and RPO (Recovery Point Objective). Run a tabletop exercise at minimum annually; full DR test at least every 2 years.
Protect backups from ransomware with immutable storage
Ransomware increasingly targets backup systems before encrypting primary data. Implement offline or immutable backups that the ransomware payload cannot reach or encrypt — ensuring you can recover without paying ransom.
BAA & Vendor Management
Execute a BAA before any vendor receives access to PHI
Every vendor with PHI access must have a signed BAA before they receive any PHI — not after. Retroactive BAAs do not eliminate the period of unauthorized disclosure. Maintain a vendor inventory with BAA status and renewal dates.
Audit all third-party SDKs and libraries for PHI exposure risk
Every analytics SDK, crash reporter, logging library, and third-party service in your stack must be audited for PHI exposure. If an SDK could transmit PHI to a third party (e.g., automatic crash reports containing PHI), you need a BAA or must sanitize all PHI before the SDK sees it.
Obtain BAAs from all cloud providers for HIPAA-eligible services only
Cloud provider BAAs only cover specific listed services. Storing PHI in a non-HIPAA-eligible service (even on a HIPAA BAA cloud) violates the BAA. Maintain a list of which cloud services are PHI-eligible and enforce this in your architecture.
Include HIPAA requirements in vendor security assessments
Before onboarding vendors with PHI access, assess their security posture — request SOC 2 Type II reports, security questionnaire responses, penetration test summaries, and evidence of encryption and access control practices.
Security Testing
Conduct a HIPAA Security Rule risk analysis before launch
A risk analysis is a required HIPAA Security Rule specification. It must identify threats and vulnerabilities to ePHI, assess the likelihood and impact of each, and document the controls implemented to reduce risk to an appropriate level.
Perform penetration testing before production launch and annually
Commission a penetration test from a qualified third party before initial launch and at least annually thereafter. Scope should include API endpoints, authentication mechanisms, access controls, and encryption implementation. Address critical and high findings before launch.
Run automated vulnerability scanning in CI/CD pipeline
Integrate SAST (Static Application Security Testing), DAST (Dynamic Application Security Testing), and dependency vulnerability scanning into your CI/CD pipeline. Block deployments with critical vulnerabilities in PHI-handling code.
Test authentication and authorization controls specifically
Explicitly test that access controls work as designed — that a user in Role A cannot access resources restricted to Role B, that unauthenticated requests are rejected, and that horizontal privilege escalation (accessing another user's PHI) is not possible.
Include HIPAA compliance testing in your QA process
Add HIPAA-specific test cases to your test suite: verify audit log generation for each PHI operation, confirm MFA enforcement, test session timeout behavior, verify encrypted storage, and confirm that error messages don't leak PHI.
Using This Checklist
No checklist replaces a proper HIPAA Security Risk Analysis. This checklist provides a technical baseline, but your risk analysis must assess the specific threats and vulnerabilities in your particular system, environment, and operational context.
Start using this checklist early in development — not as a final audit before launch. HIPAA compliance is most efficiently built in from the architecture and design phase. Retrofitting encryption, access controls, or audit logging into an existing system is significantly more expensive and error-prone than implementing them from the start.
For a step-by-step guide to the development process itself, see our HIPAA Compliant App Development Guide. To understand the specific technical safeguard requirements from the regulation, see our HIPAA Technical Safeguards service page.
Need Help Implementing HIPAA Requirements?
Our team of HIPAA software engineers can review your architecture, implement missing controls, and help you achieve full HIPAA compliance. Free consultation — no obligation.