HIPAA-compliant software development: How engineering teams build in compliance

Last updated date: 08/06/2026

I've never seen a healthcare engineering team get into trouble because they didn't know they needed encryption or access control.

I've seen several teams get into trouble because they underestimated how quickly protected health information (PHI) flows through a growing system.

Patient data finds its way into analytics platforms, staging environments, and third-party services through decisions that all seemed reasonable at the time. By the time someone asks whether the platform is HIPAA (Health Insurance Portability and Accountability Act) compliant, the limitations of architecture have already made that question difficult to answer.

That's why, instead of treating HIPAA as a checkpoint, experienced healthcare engineering teams treat it as an architectural constraint that shapes the system from the first design discussion. Every decision about how PHI moves through the platform either shrinks or expands your compliance surface area. If these decisions are deliberate, compliance becomes a natural outcome of the way your software is designed.

In this guide, we connect the HIPAA Security Rule to the architecture patterns and delivery practices that make compliance practical, while highlighting the mistakes that repeatedly surface in security reviews.

What is HIPAA-compliant software development?

HIPAA-compliant software development is the process of designing, building, and maintaining software that protects protected health information (PHI) in accordance with the HIPAA Security Rule. Compliance is not something you achieve once or enable with a single feature. There is no "HIPAA-certified" software. Instead, HIPAA compliance comes from applying the right safeguards throughout the entire software development lifecycle, from design and development to deployment and maintenance.

When does HIPAA apply to a software system?

HIPAA applies to a software system only when both of the following conditions are true:

• The software is used by a covered entity (such as a healthcare provider or health plan) or a business associate that works on its behalf.
• The software creates, receives, stores, or transmits protected health information (PHI).

If either condition is absent, the system falls outside HIPAA's scope. When both are present, the software is in scope, and your development team inherits a defined set of technical obligations.

Does HIPAA apply differently when PHI is stored versus just passing through?

The obligations themselves don't change from one system to the next. What changes is where your engineering effort needs to focus, and that starts with an important question: Does PHI simply pass through the system, or is it stored?

• Transient access: When data passes through without being stored, most of the effort goes to transmission security, encryption in transit, and keeping PHI out of edge caches and temporary files. Access controls and logging still apply.
• Persistent access: When PHI is stored or processed continuously, everything above still applies. The difference is that durable storage introduces additional responsibilities, including encryption at rest, audit logging, data retention, backup and recovery, and business associate agreements where required.

So, although the nature of access shifts the engineering surface, the compliance burden does not shrink.

Which HIPAA Security Rule requirements apply to software development?

The HIPAA Security Rule sorts its requirements into three types of safeguards: administrative, physical, and technical. Technical safeguards map most directly onto code and architecture, but the administrative and physical ones still shape how the software gets developed.

Historically, each safeguard was labeled either "required" or "addressable," and teams routinely misread "addressable" as "optional." It never meant that. It meant you had to implement the specification as written, put a documented equivalent in place, or record a formal justification for why it did not apply.

That distinction is now going away. In a rule proposed in December 2024, HHS moved to remove the required/addressable split and make all implementation specifications mandatory, subject to limited exceptions. The same proposal would make encryption of PHI at rest and in transit an explicit requirement, again with limited exceptions. The rule is not yet final, and its target finalization date has slipped to July 2027, but the direction is unambiguous: treat every safeguard below as mandatory and build to that standard now.

Most of what HIPAA asks of software is established security engineering practice. What HIPAA adds is consequence: when PHI is involved, these practices become legally binding.

How do you architect a HIPAA-compliant application?

Compliance is far cheaper to build in than to retrofit. Teams that treat HIPAA as a checklist applied at the end of development consistently discover that core architectural decisions, made early and without compliance in mind, are the most expensive to unwind. The following patterns address the requirements that most often force architectural rework when overlooked.

1. Isolate PHI from the rest of the system

One of the quickest ways to make HIPAA compliance harder is to let PHI spread across every service that might find it useful. Instead, contain it within a clearly defined boundary and expose only the data each service genuinely needs. Fewer systems handling PHI means fewer trust boundaries to secure, fewer places to audit, and far greater confidence in where sensitive data lives. It also reinforces the HIPAA Privacy Rule's minimum necessary standard by ensuring services receive only the information required for their specific purpose.

2. Enforce access control at the data layer, not just the interface

Hiding a button in the UI doesn't make a system secure. If a user can reach an endpoint directly, the interface becomes irrelevant. That’s why you must enforce authorization on the server, as close to the data as possible. Every request that can access PHI should pass through an explicit permission check before it's processed.

Role-based access control (RBAC) is typically the starting point, but mature healthcare systems rarely stop there. Access often depends on the user's role, their relationship to the patient, the action they're performing, and sometimes even the specific record they're trying to access. Whatever authorization model you adopt, the enforcement belongs in the application and data layers, where it can't be bypassed by alternate clients or internal services.

3. Encrypt PHI at rest and in transit, & manage keys deliberately

It’s important to encrypt databases, backups, storage volumes, and message queues that hold PHI at rest. All network traffic carrying PHI should use TLS 1.3 (with TLS 1.2 as a strict legacy minimum). Encryption is only as strong as its key management. Therefore, keys must be stored separately from the data they protect, rotated on a defined schedule, and never committed to source code or configuration files. A dedicated key management service is the standard approach.

4. Design audit logging as a first-class system

Every access to PHI, every read, write, modification, and deletion, must be recorded in a log that cannot be altered after the fact. These logs need to capture who accessed what, when, and from where, and they must be retained according to policy. Because audit logs themselves may reference PHI, they require the same protection as the data they describe.

5. Plan for data lifecycle, not just data creation

PHI remains your responsibility for as long as it exists. Design your architecture to support secure retention, disposal, backup, and recovery, and ensure the same protections follow the data at every stage. Backups that are encrypted in production but restored into an unprotected environment are one of the most frequent gaps I have observed.

Modus Create helped a life sciences company modernize its smoking cessation app and expand into digital biomarkers, improving quit success rate by 34%. Read the full case study ->

What does HIPAA compliance require in your CI/CD & infrastructure?

Most organizations tend to focus their HIPAA efforts on the application itself. In practice, some of the most common compliance gaps appear in the delivery pipeline and the infrastructure around it. PHI has a way of creeping into build logs, staging environments, backups, monitoring tools, and cloud infrastructure that were never designed to protect it. The Security Rule applies to every one of those systems.

1. Keep PHI out of non-production environments

The single most common infrastructure failure I’ve seen is teams using real patient data to test and develop. Development and staging environments rarely carry production-grade controls, yet teams routinely populate them with copies of live databases. PHI belongs only in environments built to protect it. Non-production environments should use synthetic or de-identified data, and de-identification has to meet HIPAA's defined standards rather than a superficial find-and-replace.

2. Manage secrets outside your codebase

Few mistakes are as difficult to clean up as committing secrets to source control. Database credentials, API keys, and encryption keys become accessible to anyone with repository access, and deleting them doesn't remove them from the commit history. Store secrets in a dedicated secrets manager, inject them at runtime, and never write them into source code, configuration files, or container images. Scan both your codebase and commit history for exposed secrets as part of the CI/CD pipeline.

3. Build compliance checks into the pipeline

Compliance is far more reliable when it's built into the CI/CD pipeline than when it depends on developers remembering another checklist. Run static analysis, dependency scanning, infrastructure-as-code scanning, and automated authorization tests on every change. Controls that execute automatically on every build are far less likely to fail than those that rely on manual review.

4. Establish BAA with your infrastructure providers

When PHI runs on a cloud platform, the provider becomes a business associate, and a business associate agreement (BAA) is legally required before any PHI touches their services. This holds even when the provider cannot see the data. A provider storing only encrypted PHI, without the decryption key, is still a business associate and still needs a signed BAA. Major providers offer BAAs and publish the specific in-scope services each one covers. Processing PHI through a service outside that scope is a gap that teams often discover only during an audit.

The shared responsibility model is where this gets misread. The provider secures the underlying infrastructure, but configuring it correctly and staying within the covered services is your team's responsibility. Here’s what the split looks like:

5. Log and monitor infrastructure access

Teams often focus on who accessed patient records while overlooking who accessed the infrastructure that stores them. Log and monitor every administrative action involving the servers and cloud services that host PHI. Unmonitored production access is a gap that routinely surfaces during security reviews.

These pipeline and infrastructure controls represent the clearest overlap between HIPAA compliance and broader security engineering. For a deeper dive, see our guides about DevSecOps best practices and integrating security into CI/CD pipelines.

What are the most common HIPAA compliance mistakes in software development?

The failures that surface in audits and breach investigations are rarely the result of a single catastrophic mistake. More often than not, they're the cumulative effect of small engineering decisions that weaken your system over time. Here are the seven most common HIPAA compliance mistakes I’ve observed.

1. Assuming HIPAA compliance is a certification

There is no official HIPAA certification for software. A product described as "HIPAA certified" is relying on a self-assessment or a third-party attestation. Compliance is demonstrated through controls and documentation, not a badge.

2. Skipping safeguards without documenting why

Under the current rule, "addressable" has never meant optional. Organizations must either implement the safeguard, adopt an equivalent measure, or document why it doesn't apply. The proposed rule removes that flexibility altogether, but even today, undocumented omissions are exactly the kind of gap auditors look for.

3. Using real PHI in development & testing

Using live patient data outside production remains one of the most common and serious HIPAA violations. Development and staging environments are built for speed and flexibility, not the level of protection required for PHI.

4. Enforcing access control only in the interface

A hidden button isn't access control. Enforce authorization in the server and data layers, where every request to PHI passes through an explicit permission check.

5. Neglecting the business associate chain

Compliance obligations flow up and down the chain of vendors. Using a subcontractor or cloud service that handles PHI without a signed BAA breaks the chain, regardless of how well the rest of the system is built.

6. Logging PHI in application logs

Application logs, error traces, and monitoring tools frequently capture patient records when a system crashes. PHI does not belong in your logging aggregation tools, encrypted or not. A stack trace that includes a patient record stored in an infrastructure tool is a massive liability.

7. Deferring compliance to the end of the project

Retrofitting HIPAA controls onto an architecture that was not designed for them is expensive and often forces rework of core components. It's far easier to build your compliance boundaries into the architecture than to discover them after the system has grown.

Make HIPAA compliance an engineering discipline

HIPAA compliance in software development comes down to one consistent principle: protect PHI wherever it lives, and be able to prove it. That protection never comes from a single control or a final review before launch. It builds up gradually, through decisions made across architecture, access management, delivery pipelines, and infrastructure, each one documented and each one defensible when an auditor asks.

The teams that get this right treat compliance as an engineering discipline from the very first design conversation, rather than a retrofit forced by a deadline or a failed assessment. That approach costs far less than reworking a system that was never built for PHI in the first place, and it results in software that healthcare organizations can scale beyond the pilot phase.

If you're building software for the healthcare and life sciences industry, Modus Create can help you engineer compliance from the start and make it a part of your culture. Learn more about our product development services ->

Frequently asked questions