Key Takeaways
- HIPAA-compliant software development requires coordinated work across four layers: technical safeguards, infrastructure configuration, application logic, and administrative policies. Missing any one layer puts the entire system at risk.
- Encryption, access controls, and audit logging form the technical foundation. AES-256 at rest, TLS 1.2+ in transit, role-based access, and tamper-evident logs with 6-year retention are non-negotiable.
- Business Associate Agreements (BAAs) must be in place with every vendor that touches PHI, including your cloud provider, logging platform, email service, and error tracking tools.
- Infrastructure-as-code tools like Momentum's open source HealthStack can automate compliant cloud setup in days rather than months, covering VPC segmentation, encryption, monitoring, and access controls out of the box.
- The most common compliance failures are not architectural. They come from operational gaps: PHI leaking into logs, shared database credentials, and backup procedures that have never been tested.
Is Your HealthTech Product Built for Success in Digital Health?
.avif)
Introduction
You are building a healthcare product that handles protected health information (PHI).
You have confirmed that HIPAA applies to your product.
Now you need a concrete answer to the question every technical founder asks next: what does my software actually need to do to be compliant?
This article is that answer. It is a checklist, organized by the four areas that matter for HIPAA-compliant software development: technical safeguards, infrastructure, application design, and administrative policies. Each item is specific enough to assign to an engineer or add to a sprint backlog.
This is engineering guidance, not legal advice. Consult a healthcare compliance attorney for your specific situation. For the regulatory framework, see Momentum's HIPAA Compliance Guide for CTOsand the HIPAA Decision Tree. This checklist covers what to build.
Checklist:
HealthStack: HIPAA-Compliant Infrastructure in Days
Momentum's open source HealthStack Terraform modules reduce HIPAA-compliant infrastructure setup from weeks to days.
HealthStack is a set of pre-built, production-tested Terraform modules that deploy HIPAA and GDPR-compliant infrastructure on AWS. It handles the infrastructure checklist items covered in this article:
- VPC with network segmentation that isolates PHI workloads in private subnets
- Encryption configured by default using AWS KMS for data at rest and TLS for data in transit
- Audit logging through CloudWatch and CloudTrail with tamper-evident log storage
- Access controls via IAM roles with least-privilege permissions
- Monitoring and alerting pre-configured for security events and infrastructure health
- Automated backups with cross-region replication for disaster recovery
What HealthStack Covers vs. What You Handle
HealthStack automates the infrastructure layer: cloud configuration, network segmentation, encryption, logging, and monitoring. These are the items in the Infrastructure Checklist section above.
Your team remains responsible for the application layer: PHI data handling, authentication logic, session management, input validation, and API security. These are the items in the Application Checklist and Technical Safeguards Checklist sections.
Your team also remains responsible for the administrative layer: BAAs, incident response plans, workforce training, and risk assessments.
Infrastructure is the part of compliance that benefits most from automation and standardization. Application logic and organizational policies are specific to your product and cannot be generalized into a Terraform module.
For a detailed walkthrough, see How Momentum Accelerates HIPAA-Compliant Infrastructure Setup with Open Source Terraform HealthStack
Common Mistakes That Break HIPAA Compliance
After supporting 100+ healthcare deployments, Momentum's engineering team sees the same compliance failures repeatedly. These are operational gaps that exist in production systems that otherwise appear well-architected.
1. Storing PHI in services without a BAA
A team configures their database and cloud storage correctly, then sends PHI to an analytics platform or error tracking tool without a BAA. Every service that receives PHI needs a BAA. If the vendor does not offer one, the service cannot be used for PHI.
Common offenders: logging platforms, analytics tools, support chat widgets, marketing automation platforms, and third-party form builders.
2. Logging PHI in application logs or error tracking
A stack trace that includes a patient name. A debug log that prints the full API request body. An error message that contains a diagnosis code. These are breaches. Implement structured logging with PHI field masking at the framework level, not as something individual developers remember to do.
3. Sharing database credentials instead of using IAM roles
Shared credentials make it impossible to attribute access to specific individuals, which violates the unique user identification requirement. Use IAM-based database authentication (supported by AWS RDS, Aurora, and equivalents on other cloud providers) so every access is tied to a specific identity.
4. Skipping encryption for internal services
"It's only internal traffic" is not a valid justification. Service-to-service communication within your VPC should use TLS, and internal databases should enforce encrypted connections.
5. Using consumer-grade tools for PHI communication
Personal Gmail accounts, free Slack workspaces, consumer Dropbox, and SMS messages are not HIPAA-compliant channels for PHI. If your team discusses patient cases or shares PHI for debugging, those communications need to happen on platforms with BAAs and appropriate access controls.
6. Not testing backup restoration
Having automated backups is necessary but not sufficient. If you have not tested restoring from those backups within the last 90 days, you do not know whether your disaster recovery plan works. Schedule quarterly restoration tests and document the results.
Start Your HIPAA Compliance Implementation
This checklist provides the technical foundation for HIPAA-compliant software development. The work is in implementing each item, validating it through testing, and maintaining it as your product evolves.
If you are building a healthcare product and need engineering support for HIPAA-compliant development, Momentum's team has implemented these requirements across 100+ healthcare deployments. Explore our HIPAA compliance servicesto see how we can help you build on a compliant foundation from day one.
Frequently Asked Questions
The minimum requirements include: AES-256 encryption for PHI at rest, TLS 1.2+ for PHI in transit, unique user identification with role-based access controls, multi-factor authentication, audit logging with 6-year retention, and automatic session management. You also need a BAA with every vendor that processes PHI, a documented risk assessment, and an incident response plan. All applicable safeguards must be in place before your software handles PHI in production.
If your MVP handles, stores, or transmits PHI, yes. HIPAA does not have a startup exemption or an MVP exception. However, you can be strategic about scope. If your MVP can function with de-identified data or avoid handling PHI directly, you may not need HIPAA compliance at launch. Use the HIPAA Decision Tree to determine whether HIPAA applies to your specific product.
AWS, Google Cloud Platform (GCP), and Microsoft Azure all support HIPAA compliance and offer BAAs. AWS has the largest number of HIPAA-eligible services (over 150 as of 2025). GCP and Azure have comparable offerings for most use cases. The BAA is not automatic with any provider; you must explicitly sign or accept it through your account settings or enterprise agreement. Once in place, restrict PHI processing to HIPAA-eligible services only. Using a non-eligible service within your BAA-covered account does not make it compliant.
HIPAA requires risk assessments to be conducted "regularly," without specifying an exact frequency. Industry practice and HHS enforcement guidance point to annual assessments as the baseline. You should also conduct one whenever you make significant changes: new integrations, infrastructure migrations, changes to PHI data flows, or adoption of new third-party services. Document each assessment, the threats identified, the controls in place, and any remediation steps with timelines.
The HIPAA Breach Notification Rule requires a defined response sequence. You must notify all affected individuals within 60 days of discovering the breach. If the breach affects 500 or more individuals, you must also notify HHS and prominent media outlets in the affected area. For breaches affecting fewer than 500 individuals, you can report to HHS annually. Financial penalties range from $100 to $50,000 per violation, with annual maximums up to $1.5 million per violation category. HHS also publishes all breaches affecting 500+ individuals on a public database. Beyond financial penalties, a breach triggers mandatory investigation and potential corrective action plans. Having a tested incident response plan and documented security controls can reduce both the severity of penalties and the scope of required corrective action.
Yes. HIPAA does not restrict the use of open source software. Many HIPAA-compliant applications use open source databases (PostgreSQL, MySQL), web frameworks (Django, Express, Rails), and infrastructure tools (Terraform, Kubernetes). The requirement is that whatever software you use must be configured and operated in a way that meets HIPAA safeguard requirements. Open source tools like Momentum's HealthStack are specifically designed to automate HIPAA-compliant infrastructure deployment.
