HIPAA Compliance Checklist for Software Teams

TL;DR: HIPAA is a US federal law, not a certificate you can buy. For software teams it comes down to three things: sign Business Associate Agreements with everyone who touches protected health information (PHI), implement the required administrative, physical and technical safeguards, and keep evidence that you did. This hipaa compliance checklist walks through the controls that genuinely reduce your risk and satisfy an auditor.

What is HIPAA and who does it actually apply to?

HIPAA (the Health Insurance Portability and Accountability Act of 1996, later expanded by the HITECH Act and the Omnibus Rule) governs how protected health information is handled in the United States. It splits regulated organisations into two roles that matter to you as a builder:

• Covered entities — health plans, healthcare clearinghouses and most providers who bill electronically.
• Business associates — vendors that create, receive, store or transmit PHI on a covered entity's behalf. If you build software that handles patient data for a clinic, hospital or insurer, you are almost certainly a business associate, and your subcontractors (cloud host, email provider, analytics) become subcontractor business associates.

A common myth is that HIPAA is a US-only concern. If you are a founder in the UK, Europe or Australia selling healthtech to US customers, or processing US patient data, HIPAA follows the data. It sits alongside GDPR and the UK Data Protection Act rather than replacing them, and you will often need to satisfy both regimes at once. There is no government-issued "HIPAA certificate" — compliance is something you demonstrate through documented safeguards and, if you want external validation, a third-party attestation such as HITRUST or a SOC 2 report that maps to the HIPAA Security Rule.

How is the HIPAA compliance checklist structured?

The Security Rule organises requirements into three categories of safeguards. Each control is flagged either Required (you must do it) or Addressable (you must implement it, adopt an equivalent alternative, or document a defensible reason not to — "addressable" does not mean optional). Here is the practical breakdown.

Safeguard category	What it covers	Examples engineers own
Administrative	Policies, people, risk management	Risk analysis, access approval workflow, workforce offboarding, incident response plan
Physical	Facilities and devices	Data-centre selection (via your cloud BAA), device encryption, screen-lock and workstation policy
Technical	The software controls themselves	Access controls, audit logging, encryption in transit and at rest, integrity checks, authentication

Administrative safeguards

• Conduct a documented risk analysis — the single most-cited failure in enforcement actions. Map every place PHI lives, moves and is backed up.
• Assign a Security Official responsible for policies (a named person, even in a small team).
• Role-based access with a documented approval and review process — enforce least privilege.
• Workforce training and a clean joiner/mover/leaver process that revokes access promptly.
• Written incident response and breach notification procedures (see timelines below).

Physical safeguards

• Use a cloud provider that will sign a BAA (AWS, Google Cloud and Azure all do, and publish which services are in scope).
• Enforce full-disk encryption and remote-wipe on any laptop or device that could access PHI.
• Document facility and workstation-use policies even if you are fully remote.

Technical safeguards — the engineering core

• Unique user identification — no shared accounts, ever.
• Encryption in transit (TLS 1.2+, HSTS) and at rest (AES-256). Encryption is technically "addressable", but in practice not encrypting PHI is indefensible.
• Audit controls — immutable, tamper-evident logs of who accessed which record and when. Retain them (six years is the common benchmark for HIPAA documentation).
• Automatic logoff and strong authentication, ideally MFA on anything privileged.
• Integrity controls so PHI cannot be improperly altered or destroyed — hashing, versioning, backups with tested restores.

Why do Business Associate Agreements matter so much?

A BAA is the contract that legally extends HIPAA obligations to a vendor. Without one in place before PHI is shared, the disclosure itself can be a violation regardless of how secure your systems are. The rule is simple: if a third party can see PHI, you need a signed BAA with them. That includes your cloud host, transactional email service, SMS gateway, error-monitoring tool and any analytics that could capture patient data.

Practical tip: keep a living BAA register. For every subprocessor, record the signed date, the services in scope, and whether PHI actually flows to it. Auditors ask for this, and it forces you to notice tools that quietly ingest patient data.

A frequent, avoidable mistake is piping PHI into a general-purpose product analytics or session-replay tool that will not sign a BAA. Segregate PHI from your marketing and telemetry stack from day one.

How do HIPAA, SOC 2 and HL7/FHIR fit together?

These are often confused. They solve different problems and you may need all three:

Framework	What it is	Why you'd use it
HIPAA	US law with mandatory safeguards	Legally required when handling US PHI
SOC 2	Voluntary audit report on security controls	Sales/trust signal; overlaps heavily with HIPAA technical controls
HITRUST	Certifiable framework mapping to HIPAA	When enterprise health customers demand a certificate
HL7 / FHIR	Healthcare data interoperability standards	Exchanging records with EHR/EMR systems — see our EHR/EMR integration guide

HIPAA tells you what data protection you must have; SOC 2 or HITRUST give you an independent report proving it; HL7 and FHIR govern how you exchange clinical data with other systems. Getting FHIR integration right is a compliance concern too, because that is often where PHI crosses trust boundaries.

How much does HIPAA compliance cost and how long does it take?

There is no fixed price, and anyone quoting one precisely is guessing. As rough, clearly-labelled industry estimates: a focused risk analysis and policy set for an early-stage product is typically a few weeks of work; a SOC 2 Type II observation window runs several months; HITRUST certification is a larger, longer effort usually reserved for teams selling into big health systems. The bigger cost driver is architectural — retrofitting audit logging, access controls and PHI segregation into a live product is far more expensive than designing for them upfront. Building compliance in from the first sprint is the cheapest path, which is exactly the argument for a HIPAA-compliant healthtech MVP rather than bolting it on after launch.

What are the most common ways software teams fail an audit?

• No documented risk analysis — or one done once and never updated.
• Missing BAAs with a subprocessor that turned out to touch PHI.
• Weak or absent audit logs — you cannot prove who accessed a record.
• PHI leaking into logs, analytics, error trackers or test databases.
• No tested backup/restore and no breach-notification runbook.

On breach timelines: HIPAA requires notifying affected individuals without unreasonable delay and within 60 days of discovery; breaches affecting 500 or more people must also be reported to the US Department of Health and Human Services within that window. Having the runbook written before you need it is what separates a contained incident from a reportable disaster.

This is the discipline we bring to healthtech builds at CodeVix Labs — QA-first engineering where safeguards, audit logging and BAA hygiene are part of the definition of done, not a later scramble. You can see how we approach regulated builds on our healthtech page and in our portfolio. If you are weighing build cost and scope, our pricing page explains how we structure compliant projects, and if you have PHI questions specific to your product, get in touch.

Frequently asked questions

Is there an official HIPAA certification I can get?

No. The US government does not certify or endorse any product as "HIPAA compliant." You demonstrate compliance through documented safeguards and risk management. Third-party attestations like SOC 2 or HITRUST provide external validation, but they are not the same as a government certificate.

Does HIPAA apply if my company is based in the UK, Europe or Australia?

Yes, if you handle US protected health information or serve US covered entities. HIPAA follows the data, not your headquarters. You will typically need to comply with HIPAA and your local regime (GDPR, UK DPA, or the Australian Privacy Act) simultaneously.

Do I need a BAA with my cloud provider?

Yes. AWS, Google Cloud and Azure will all sign a BAA and publish which of their services are covered under it. You must sign it and use only the in-scope services for PHI before you store any patient data.

Can I use standard analytics or error-monitoring tools with PHI?

Only if the vendor signs a BAA and the data is in scope. Most general-purpose analytics and session-replay tools will not, so you must strip or segregate PHI before it reaches them. Treat any tool that could ingest patient data as a business associate until proven otherwise.