Key Takeaways:
- This checklist covers every HIPAA requirement relevant to software development — technical safeguards, administrative controls, physical security, mobile-specific requirements, cloud-specific requirements, and BAA management.
- Updated for the 2026 HIPAA Security Rule: encryption is now mandatory (not addressable), MFA is required for all users accessing ePHI, and continuous monitoring supplements annual risk assessments.
- Common HIPAA violations in software development include unencrypted PHI in databases, shared admin accounts, missing audit logs, PHI in test environments, and BAA gaps with SaaS vendors.
- Use this alongside our downloadable HIPAA compliance checklist PDF for a structured implementation and audit preparation process.
Why Developers Need a HIPAA Checklist
HIPAA compliance in software development is not a single action — it is a system of technical controls, organizational policies, and operational practices that must work together. Missing a single requirement creates a gap that auditors will find and attackers will exploit.
The challenge is scope. HIPAA requirements are spread across multiple rules — Privacy, Security, Breach Notification, Omnibus — each with dozens of implementation specifications. Without a structured checklist, development teams inevitably miss items. The most common gaps are not dramatic failures — they are quiet omissions: a database column that is not encrypted, a monitoring tool that captures PHI in logs without a BAA, test data that contains real patient information, or an admin account shared between three developers.
This checklist organizes every HIPAA requirement relevant to software development into categories your team can work through systematically. For the full regulatory context behind each item, see our HIPAA compliance guide. For a downloadable PDF version with status tracking columns, visit our HIPAA compliance checklist tool.
Technical Safeguards Checklist
Technical safeguards are the requirements that translate directly into code, configuration, and architecture decisions. These are what your development team owns.
Encryption
All ePHI encrypted at rest using AES-256 or equivalent — databases, file storage, backups, logs containing PHI. Under the 2026 rule, this is mandatory — no alternative measures accepted.
All ePHI encrypted in transit using TLS 1.2 or higher — API calls, web traffic, database connections, internal service communication. No exceptions for “internal” traffic.
Full disk encryption on all servers, devices, and workstations that store or process ePHI.
Encryption key management implemented — secure key storage, key rotation schedule, access-controlled key access, separate key management from data storage.
Backup data encrypted with the same standards as production data. An unencrypted backup is an unencrypted copy of your entire PHI database.
Access Controls
Unique user identification for every person accessing the system. No shared accounts. No generic admin logins. Every action must be attributable to a specific individual.
Multi-factor authentication for all users accessing systems containing ePHI. Under the 2026 rule, this is mandatory — not just for administrators. Acceptable factors include something you know (password), something you have (authenticator app, hardware token), and something you are (biometric).
Role-based access control (RBAC) implementing the principle of least privilege. Each role accesses only the minimum PHI necessary for its function. A billing clerk does not need access to clinical notes. A nurse does not need access to financial records.
Automatic session timeout after a configurable period of inactivity. Healthcare environments typically use 10–15 minutes for clinical workstations and 5 minutes for mobile devices.
Emergency access procedures documented and tested. When normal authentication fails during a clinical emergency, there must be a documented process for obtaining access — with full audit logging of the emergency access event.
Access provisioning tied to documented approval workflows. Access de-provisioning triggered immediately upon role change or termination — not “when IT gets around to it.”
Audit Controls
Every access to ePHI logged — who accessed what data, when, from what device/IP, what action was performed (read, write, modify, delete), and whether access was successful or denied.
Every system configuration change logged — who changed what setting, when, from where, and what the previous value was.
Audit logs stored in tamper-proof, write-once storage. If an attacker (or a rogue insider) can modify audit logs, the logs are worthless.
Audit log retention configured for minimum 6 years per HIPAA requirements.
Regular audit log review process established — not just logging, but someone actually looking at the logs on a defined schedule, with documented findings and escalation procedures.
Automated alerting for suspicious patterns — multiple failed login attempts, access to unusual volumes of records, access outside normal hours, access from unusual locations.
Integrity Controls
Input validation on all user-submitted data to prevent injection attacks that could modify ePHI.
Checksums or digital signatures on stored clinical data to detect unauthorized modification.
Database transaction logging with rollback capability.
Version control for clinical record modifications — every change tracked, previous versions recoverable.
Transmission Security
Certificate pinning for mobile applications to prevent man-in-the-middle attacks.
All API communication encrypted via TLS 1.2+ — including internal microservice communication, not just external-facing endpoints.
VPN or encrypted tunnel required for all administrative and development access to production systems.
Secure WebSocket connections (WSS) for any real-time data features — telemedicine video, RPM alerts, chat messaging.
Administrative Safeguards Checklist
Administrative safeguards are the policies, procedures, and organizational practices that support technical compliance. Development teams often overlook these, but OCR auditors do not.
Security Management
Formal risk assessment completed within the past 12 months — identifying all PHI touchpoints, threats, vulnerabilities, and risk levels. Use our HIPAA risk assessment template for a structured approach.
Risk management plan documented with specific remediation actions, owners, and target dates for each identified risk.
Sanction policy established — documented consequences for workforce members who violate HIPAA security policies.
Information system activity review — regular review of audit logs, access reports, and security incident records.
Workforce Security
Authorization procedures for granting workforce access to ePHI — documented approval process, not informal requests.
Clearance procedures for verifying workforce members before granting PHI access — background checks, role verification.
Termination procedures that revoke all access immediately — system accounts, VPN, cloud console, code repositories, communication channels. “Immediately” means the same day, not next week.
Contractor and temporary staff governed by the same access policies as permanent employees.
Training
HIPAA security awareness training completed at onboarding for all workforce members with access to ePHI.
Annual refresher training documented with attendance records and attestation.
Training content updated within 30 days of material policy changes.
Training includes how to identify and report security incidents, phishing awareness, and proper PHI handling procedures.
Contingency Planning
Data backup procedures documented — daily encrypted backups, offsite or multi-region storage, verified restoration process.
Disaster recovery plan documented and tested at least annually. “Tested” means actually running the recovery process, not just reviewing the document.
Emergency mode operation plan — how critical clinical systems continue operating during infrastructure failures.
Backup restoration tested and verified at least quarterly. A backup that has never been restored is not a backup — it is a hope.
Physical Safeguards Checklist
Physical safeguards protect the infrastructure that houses ePHI. For cloud-deployed applications, most physical safeguards are inherited from the cloud provider’s BAA — but device and workstation security remain your responsibility.
Data center access controlled and logged (handled by cloud provider under BAA for cloud deployments).
Workstation use and security policies documented — which devices can access ePHI, screen lock requirements, physical security requirements for remote work.
Device and media disposal procedures — certified data wiping or physical destruction before disposing of any device that has stored ePHI.
Remote work security — encrypted VPN, company-managed or company-approved devices, physical workspace security requirements.
Mobile App-Specific HIPAA Requirements
Mobile healthcare apps face unique compliance challenges beyond standard web applications.
On-device data storage encrypted using hardware-backed encryption (iOS Keychain, Android Keystore). Local databases encrypted via SQLCipher or equivalent.
Screenshot blocking implemented to prevent PHI from appearing in app switcher previews.
Push notifications contain no PHI — generic alerts only (“You have a new message”). Authentication required to view content.
Biometric authentication (Face ID, Touch ID) supported as one MFA factor.
Remote wipe capability for lost or stolen devices.
Offline mode encrypts any locally cached PHI and purges on session end.
App transport security enforced (iOS ATS, Android network security configuration) blocking cleartext HTTP connections.
Certificate pinning prevents man-in-the-middle attacks on API communication.
For a deep dive, see our blog on HIPAA compliance for mobile apps.
Cloud-Specific HIPAA Requirements
Cloud infrastructure introduces shared responsibility — the cloud provider secures the infrastructure, you secure everything you build on top of it.
BAA executed with cloud provider before deploying any ePHI. AWS, Azure, and GCP all offer BAAs — but not for every service. Only BAA-covered services may be used for PHI workloads.
Verify every cloud service used with ePHI is explicitly listed in the provider’s BAA documentation. Using a non-covered service — even accidentally — is a compliance violation.
Network isolation configured — VPC/VNet with security groups restricting access. No ePHI-containing resources on public subnets.
Cloud audit logging enabled — CloudTrail (AWS), Azure Monitor (Azure), Cloud Audit Logs (GCP). Logs retained for 6+ years.
IAM roles configured with least-privilege access. No root account usage for daily operations.
Encryption enabled on all storage services — S3 buckets, RDS databases, EBS volumes (AWS); Blob Storage, SQL Database (Azure).
Multi-region or multi-AZ deployment for high availability and disaster recovery.
For cloud architecture guidance, see our healthcare cloud migration services.
BAA Requirements Checklist
Business Associate Agreements are the most frequently missed compliance requirement — especially for SaaS tools that development teams adopt without thinking about PHI implications.
BAA executed with cloud provider (AWS, Azure, GCP) — verify it covers every service you use with ePHI.
BAA executed with your development partner (if they access production PHI or test data containing PHI).
BAA executed with monitoring and logging services that may capture PHI in log data (Datadog, New Relic, Sentry — check if your logs contain PHI).
BAA executed with email and SMS services used for patient communication (SendGrid, Twilio, Mailgun).
BAA executed with analytics platforms processing data derived from PHI.
BAA executed with payment processors handling healthcare billing data.
BAA executed with any CI/CD or deployment tool that accesses production environments containing PHI.
BAA inventory maintained and reviewed annually — every vendor relationship verified for scope accuracy.
BAAs reviewed when services change — adding a new feature that sends PHI through a previously non-PHI service requires a new or amended BAA.
Common HIPAA Violations in Software Development
Understanding the most common violations helps development teams avoid them proactively.
Unencrypted PHI in databases. Storing patient data in an unencrypted database — even behind a firewall — is a violation under the 2026 rule. Encryption at rest is now mandatory.
Shared admin accounts. Three developers sharing one admin account means no one knows who did what. Every individual must have unique credentials.
Missing audit logs. Building a feature that accesses PHI without adding corresponding audit log entries. Every PHI touchpoint must be logged.
PHI in test environments. Using production data containing real patient information for development, testing, or QA. Test environments must use de-identified or synthetic data — or maintain the same security controls as production.
BAA gaps with SaaS tools. Using Slack, Trello, Google Docs, or consumer email to discuss patient cases without a BAA. If PHI flows through the tool, it needs a BAA.
Unencrypted backups. A nightly database backup stored unencrypted on S3 is an unencrypted copy of every patient record in your system.
No log retention policy. Audit logs that auto-delete after 30 days violate the 6-year retention requirement.
PHI in error messages. Application error logs that capture patient data in stack traces, API request logs, or debug output — often transmitted to third-party error tracking services without BAAs.
2026 Security Rule Changes Developers Must Know
The 2026 update is the most significant change since HITECH. If your application was built before 2026, verify these specifically.
Encryption is now mandatory. Previously “addressable” — organizations could document alternative measures. Under the 2026 rule, AES-256 (or equivalent) encryption at rest and TLS 1.2+ in transit are required. No alternatives. No exceptions.
MFA is now mandatory for all users. Previously recommended but not universally required. Under the 2026 rule, every user accessing ePHI must authenticate with at least two factors. Not just admins. Not just developers. All users.
Continuous monitoring is required. Annual risk assessments remain the baseline, but organizations must also implement real-time intrusion detection, regular vulnerability scanning (not annual-only), and continuous monitoring of systems containing ePHI.
Patch management timelines must be documented. Organizations must document their patch management process with specific timelines for applying security patches — and demonstrate compliance with those timelines.
For complete 2026 rule details, see our HIPAA compliance guide.
HIPAA Compliance Testing Checklist
Before any healthcare application goes to production, verify these testing items.
Encryption validation — Verify data at rest is encrypted (inspect database storage, file storage, backup storage). Verify data in transit uses TLS 1.2+ (test with SSLLabs or similar).
Access control testing — Verify RBAC enforcement (attempt to access data outside assigned role). Verify MFA enforcement (attempt login without second factor). Verify session timeout (wait for inactivity period, confirm session terminates).
Audit log verification — Perform a PHI access action and verify it appears in the audit log with correct details (who, what, when, where, action). Verify audit logs cannot be modified or deleted by application users.
Penetration testing — Independent security assessment covering OWASP Top 10, HIPAA-specific attack vectors (PHI access, authentication bypass, audit log tampering), and infrastructure security.
BAA verification — Confirm all production services handling PHI are covered by executed BAAs. Check monitoring tools, error tracking, email services, and cloud services — not just the obvious ones.
Breach response test — Tabletop exercise simulating a PHI breach. Verify the team can identify, contain, investigate, and notify within required timelines.
Download the Full HIPAA Checklist (PDF) Get the complete 50+ item checklist as a downloadable PDF with implementation notes, responsible party assignments, and compliance status tracking. Download Full Checklist →
Related Resources:
- HIPAA Compliance Guide for Software Development
- HIPAA Compliance Checklist (Downloadable)
- HIPAA Compliance Cost for Software
- HIPAA Risk Assessment Template
- HIPAA-Compliant App Development
- HIPAA Compliance for Mobile Apps (Blog)
- SOC 2 vs HIPAA (Blog)
- Healthcare Cloud Migration
- Certifications & Compliance
- Healthcare Software Development Guide
- Free Consultation
Frequently Asked Questions
This checklist covers the software development-specific requirements. Full HIPAA compliance also requires organizational policies, workforce training, and ongoing risk management beyond the software itself. This checklist is comprehensive for what development teams control.
Quarterly for a quick status check. Annually for a formal comprehensive review. Immediately after significant system changes (new features handling PHI, new integrations, new cloud services).
HIPAA penalties range from $141 per violation (unknowing) to $2.13 million per violation category per year (willful neglect). A single missing control can trigger penalties across multiple categories. See our HIPAA compliance cost guide for financial details.
Yes. Go through each item and mark current status — compliant, in progress, or gap. Use the gaps to build a prioritized remediation plan. This is essentially what a HIPAA gap assessment does.
Download the full 50+ item PDF checklist with status tracking columns from our HIPAA compliance checklist tool page.




