HIPAA-Compliant Software Development: 2026 Checklist

Most guidance on HIPAA-compliant software development has the same problem. It’s either a legal summary that never touches a line of code, or a vendor checklist that quietly conflates what the law requires with what that vendor happens to sell.

This is the version we wish we’d had. It covers what the HIPAA Security Rule actually obligates a software team to do, what it doesn’t, what is currently only proposed, and which architectural decisions determine whether HIPAA compliance costs your team a week or a full rewrite.

One thing to state up front, because a lot of published guidance currently gets it wrong: the widely-cited 2026 changes to the HIPAA Security Rule — mandatory encryption, mandatory MFA — are still a proposed rule, not law. More on that below, in its own section.

Treat what follows as a working HIPAA compliance checklist for software development. Each section maps to a specific obligation, and the technical safeguards section is written so you can walk it line by line against your own codebase.

---

What HIPAA-compliant software development actually means

There is no such thing as HIPAA-certified software.

This is the first thing to get straight, because it reframes the whole exercise. No government agency certifies products. The Office for Civil Rights (OCR), which enforces HIPAA, does not run a certification programme, does not maintain an approved-vendor list, and does not issue badges. Any vendor selling you a “HIPAA certification” is selling their own attestation.

What exists instead is a posture: a set of safeguards you have implemented, documented, and can evidence if asked. HIPAA compliance is demonstrated through a documented risk analysis, implemented administrative, physical and technical safeguards, signed Business Associate Agreements with every vendor touching patient data, and records showing the whole thing operates.

That distinction matters for how you plan. There’s no exam to pass and no date to hit. HIPAA-compliant software development is a standard of care you either meet continuously or you don’t — which is precisely why it belongs in your architecture decisions rather than in a pre-launch audit.

---

Do you even fall under HIPAA? Start here

Before writing a line of code, establish which of three positions you’re in — because the obligations differ sharply.

You are a covered entity if you’re a health plan, a healthcare clearinghouse, or a healthcare provider that transmits health information electronically in connection with a covered transaction. HIPAA applies to you directly.

You are a business associate if you create, receive, maintain, or transmit protected health information on behalf of a covered entity. This is where the overwhelming majority of software companies land. A telehealth platform, a patient intake tool, an analytics product used by a hospital, a remote-monitoring app sold to a clinic — all business associates. Obligations reach you through a Business Associate Agreement, and since the HITECH Act, business associates are directly liable for Security Rule violations.

You are neither if you handle health-adjacent data with no covered entity relationship. A consumer fitness tracker sold direct to users, with no provider on the other end, generally sits outside HIPAA — though it may well sit inside GDPR, state privacy law, or FTC Health Breach Notification obligations instead. Falling outside HIPAA is not the same as falling outside regulation.

Get this wrong in either direction and you pay for it. Assume you’re covered when you aren’t and you’ll gold-plate an architecture for no reason. Assume you aren’t when you are and you’ll be retrofitting under contractual pressure.

---

The distinction that trips up every engineering team: required vs. addressable

This is the single most misunderstood mechanic in the Security Rule, and it produces two opposite failure modes.

Each implementation specification in the Security Rule is labelled either required or addressable.

Required means implement it. No discretion.

Addressable does not mean optional. It means: assess whether the specification is reasonable and appropriate for your environment. If it is, implement it. If it genuinely isn’t, you must document why, and implement an equivalent alternative measure that achieves the same protection.

So the honest translation of “addressable” is: implement it, or write down a very good reason and do something equally strong instead. “We decided not to” is not a reason. An undocumented decision is the worst of both worlds — you carry the risk and have nothing to show for it.

Teams that misread addressable as optional skip encryption and audit logging. Teams that misread it as required over-engineer everything equally, including things that don’t matter. Neither is what the rule asks for.

---

The 2026 status check: what’s law, and what’s only proposed

You will find a great deal of published content — including from development agencies ranking well for this exact topic — stating that as of 2026, HIPAA now mandates encryption, requires MFA on all systems accessing ePHI, and demands continuous monitoring.

That is not accurate as of this writing.

In January 2025, OCR published a Notice of Proposed Rulemaking to modernise the Security Rule. It is significant, and if finalised it would be the largest change to the rule in two decades. But it has not been finalised. The initial target for a final rule was missed, and projected timelines have since moved into 2027. Until OCR issues a final rule with an effective date and a compliance date, the Security Rule in force is the one that has been in force.

Here’s the accurate picture:

Control	Status today (in force)	Under the proposed rule
Encryption of ePHI at rest and in transit	Addressable	Required, with limited exceptions
Multi-factor authentication	Not specified as such	Required
Required vs. addressable distinction	Exists	Largely eliminated — nearly all become required
Asset inventory and network map	Not explicit	Required, maintained and reviewed
Network segmentation	Not explicit	Required
Penetration testing	Not explicit	Annual
Vulnerability scanning	Not explicit	Every six months
Restoration of critical systems	Contingency plan required	Within 72 hours
Business associate verification	BAA required	Annual written verification of safeguards

What to do with this. Build to the proposed rule anyway. Not because it’s law — it isn’t — but because every control in that right-hand column is defensible security practice you’d want regardless, most of it is already expected by enterprise procurement, and doing it now means a future final rule costs you a documentation exercise rather than an engineering programme.

Be precise in how you describe your own posture, though. Claiming compliance with a rule that doesn’t exist yet is its own kind of exposure, and sophisticated healthcare buyers notice.

---

HIPAA technical safeguards checklist (45 CFR § 164.312)

These are the five standards that map most directly onto code and infrastructure — the core of any HIPAA compliance checklist for software development.

Access control

• not doneUnique user identification (required) — every user has their own identity. No shared accounts, no shared admin credentials, no service account passed around a team channel.
• not doneEmergency access procedure (required) — a documented, tested way to reach ePHI during an outage or incident.
• not doneAutomatic logoff (addressable) — sessions terminate after a defined idle period. Implement it.
• not doneEncryption and decryption (addressable) — AES-256 or equivalent at rest, covering databases, object storage, backups, snapshots and any file exports.
• not doneRole-based access enforced server-side, with the minimum necessary principle applied at the API layer — endpoints return only the fields that role actually needs, not the whole record filtered in the client.

If you’re implementing centralised authentication across multiple internal systems, our guide to single sign-on implementation covers the protocol choices in depth.

Audit controls

• not doneAudit controls (required) — hardware, software or procedural mechanisms that record and examine activity in systems containing ePHI.

In practice this means an append-only log answering: which identity accessed which record, when, from where, and what they did. Not application debug logging — a deliberate access trail, tamper-resistant, queryable, and separated from the data it describes. Build it as an event log and you’ll find it doubles as your best product telemetry.

Integrity

• not doneMechanism to authenticate ePHI (addressable) — controls proving records haven’t been improperly altered or destroyed. Checksums, versioning, database-level integrity constraints, immutable audit trails.

Person or entity authentication

• not doneAuthentication (required) — verify that a person seeking access is who they claim to be.

The rule doesn’t prescribe MFA today. Implement it anyway, on every path that reaches ePHI, including administrative and support tooling. It’s the proposed rule’s most likely survivor and it’s the control that prevents the largest category of real breaches.

Transmission security

• not doneIntegrity controls (addressable) — ePHI isn’t improperly modified in transit.
• not doneEncryption (addressable) — TLS 1.2 minimum, 1.3 preferred. All API traffic, webhooks, service-to-service calls, and database connections — including internal ones inside your VPC.

---

Administrative and physical safeguards developers actually touch

The Security Rule’s administrative and physical standards read like policy work, but several land squarely on engineering.

Risk analysis (required) — a documented, periodic assessment of risks to the confidentiality, integrity and availability of ePHI. This is the most frequently cited failing in OCR enforcement actions, and it is the one item most teams skip because it produces a document rather than a feature. Do it. Date it. Redo it when the architecture changes.

Business Associate Agreements (required) — a signed BAA with every vendor that touches ePHI. Enumerate honestly: cloud provider, database host, email and SMS delivery, error monitoring, session recording, analytics, support desk, backup service, log aggregation. Error monitoring and analytics are where most teams have an unpapered gap, because those SDKs get added casually and quietly capture request payloads.

Contingency plan (required) — data backup plan, disaster recovery plan, emergency mode operation. Backups must themselves be encrypted and access-controlled; a backup bucket is a full copy of your ePHI with none of your application’s access logic in front of it.

Workforce security and training (required) — access granted by role, revoked promptly on departure, and documented training for anyone who touches the system.

Device and media controls (required) — how ePHI is disposed of and how media is reused. In cloud terms: cryptographic erasure, retention policies on object storage, and a real answer for what happens to detached volumes and old snapshots.

---

The five violations we see most often in real codebases

From actual engagements, these recur far more than anything exotic:

1. PHI in application logs. A request logger capturing full bodies, an exception handler serialising a patient object, a debug statement that survived review. Logs then replicate into monitoring platforms, alert payloads, and cold storage nobody remembers. Fix: structured logging with field-level redaction, enforced in a shared logging library rather than left to individual discretion.

2. Production data in non-production environments. Staging seeded from a production dump so QA can test “realistically.” Those environments almost never carry production’s access controls, encryption posture, or monitoring. Fix: de-identified or synthetic fixtures, and a hard rule that production dumps never leave production.

3. Shared administrative accounts. One admin login used by four engineers destroys unique user identification and makes your audit trail worthless — you can prove a record was accessed but not by whom.

4. Unpapered vendor SDKs. Session replay tools in a clinical workflow are the sharpest version of this. They are designed to capture exactly what a user sees and types, which in a clinical context is protected health information, transmitted to a third party you may have no BAA with.

5. Backups outside the compliance boundary. Encryption on the primary database, nothing on the nightly dump. Or a legacy snapshot in a bucket that predates your current IAM policy.

None of these are sophisticated failures. All of them are findable in an afternoon, and all of them are cheap to fix early and expensive to fix once there’s real patient data in the system.

---

Architecture decisions that make HIPAA cheap instead of expensive

The gap between a compliant build and an expensive retrofit comes down to a handful of decisions, and they’re nearly free when made at the start. This is where HIPAA-compliant software development is won or lost — not in the checklist, but in the first week of architecture.

Isolate ePHI behind one boundary. One service, or at minimum one schema, holding identifiers and clinical fields. Everything else in the system references a pseudonymous ID. This single decision collapses the scope of your audit, your access control, your encryption requirements and your breach assessment. Skip it and protected data spreads into every table, every export and every log you ever write — and each becomes an obligation.

Choose your cloud, region and BAA before the first commit. All three major providers sign BAAs and publish lists of HIPAA-eligible services. Only those services may process ePHI. Confirm this before you architect, because migrating a live system holding patient data is among the least pleasant projects in software.

Make the audit trail a first-class append-only event log, not something bolted onto an ORM callback later.

Treat encryption as a default, not a feature. On managed services, at-rest encryption is a configuration flag. Turn it on everywhere at provisioning time and it costs nothing.

Apply minimum necessary at the API contract, not the UI. If an endpoint returns a full patient record and the frontend renders three fields, you’ve disclosed the full record.

If you’re building a first release under these constraints, the same principle we apply to MVP development services holds especially strongly here: the fastest regulated build is the one that holds the least regulated data. Ask what the smallest amount of PHI is that still lets you validate the product. Every field you don’t store removes obligations permanently.

Teams handling EU patients should read this alongside how GDPR applies to US companies — the two regimes overlap but their deletion and breach-notification requirements differ sharply, and GDPR’s right to erasure puts pressure on architecture that HIPAA does not. If you’re also processing card payments, PCI compliance solutions adds a third, more prescriptive set of controls on top.

---

What this looked like on a real build

We delivered a cross-platform fitness and remote-care product for a health-tech client that needed Bluetooth device integration, secure data synchronisation, and real-time communication between patients and their providers — under HIPAA and GDPR obligations from the first release rather than added later.

Because the constraints were fixed before design started, the architecture absorbed them: an isolated data layer, encrypted sync, role-scoped access, and audit logging built into the event model rather than retrofitted. The product launched, reached 75% daily active engagement, and passed its regulatory compliance checks.

Nothing about the approach was exotic. The difference was sequencing — the compliance requirements cost design time instead of rebuild time. That is the whole lesson of HIPAA-compliant software development, and it is why the checklist above belongs at the start of a project rather than the end of one.

You can see more of how we approach this in our healthcare product engineering work, and our HIPAA compliance services cover assessment and remediation for teams who are further along than they’d like to be.

---

Frequently Asked Questions

Can software be HIPAA certified?

No. There is no official HIPAA certification and no government body that certifies software as HIPAA compliant. HIPAA compliance is a posture you maintain and must be able to evidence — through a documented risk analysis, implemented safeguards, signed Business Associate Agreements and audit records. Any vendor selling a “HIPAA certification” is selling their own attestation, not a government one.

Does HIPAA require encryption?

Under the Security Rule as it stands in 2026, encryption of ePHI is an addressable specification, not a required one. Addressable does not mean optional: you must implement it, or document why it is not reasonable and appropriate for your environment and implement an equivalent alternative safeguard.

In practice, encrypting ePHI at rest and in transit is the only defensible position. The proposed 2025 Security Rule update would make encryption explicitly mandatory, but that rule is not yet final.

Is my app a covered entity or a business associate under HIPAA?

A covered entity is a health plan, healthcare clearinghouse, or healthcare provider that transmits health information electronically. A business associate is any organization that creates, receives, maintains or transmits protected health information on behalf of a covered entity.

Most software vendors serving healthcare clients are business associates, which means HIPAA obligations reach them through a Business Associate Agreement rather than directly.

Can I use production patient data in a test environment?

You should not. Protected health information in staging, QA or development environments is one of the most common HIPAA findings in software teams, because those environments rarely carry the same access controls, encryption, logging and monitoring as production.

Use de-identified or synthetic data instead. If PHI must exist outside production, that environment inherits the full set of Security Rule obligations.

How long must HIPAA audit logs and documentation be retained?

HIPAA requires that required documentation — including policies, procedures, and records of required actions and assessments — be retained for six years from the date of creation or the date it was last in effect, whichever is later. Many organizations apply the same six-year window to audit logs of ePHI access for consistency, though the rule specifies documentation rather than log retention directly.

Is AWS, Azure or Google Cloud HIPAA compliant?

The major cloud providers will sign a Business Associate Agreement and offer HIPAA-eligible services, but that does not make your application compliant. Cloud providers operate a shared responsibility model: they secure the infrastructure, while you remain responsible for configuration, access control, encryption settings, logging, and which services you use.

Only services explicitly listed as HIPAA-eligible under your BAA may process ePHI.

Building a product that handles protected health information? Talk to our team about HIPAA compliance services.