HIPAA Compliance Checklist

Work through every requirement for your software, EMR, or website. See your gaps, track progress, and export the results. Nothing you check here ever leaves your browser.

  • No signup required
  • 100% free
  • Nothing leaves your browser

Before you start

This checklist is an educational tool, not legal advice. HIPAA compliance depends on your specific systems, data, and business relationships. Consult a qualified healthcare compliance attorney or auditor before relying on any assessment.

Step 1 of 2

What are you building?

Select everything that applies. We'll filter the checklist to what's actually relevant.

HIPAA compliance for software teams covers three Security Rule safeguard categories: administrative (risk analysis, training, signed BAAs), physical (facility and device controls), and technical (encryption, audit logs, MFA), plus the Privacy and Breach Notification Rules. This checklist breaks all of them into 30-plus plain-English requirements for web apps, EMRs, mobile apps, and cloud infrastructure.

01 The Security Rule

What HIPAA actually requires from software teams

Three safeguard categories cover almost everything on this checklist. None of them are optional based on company size.

Administrative

The paperwork and process layer: risk analysis, a named security official, workforce access policies, training, incident response, and signed BAAs with every vendor touching PHI. Not code, but it's what auditors ask for first.

Physical

Who can reach a server room, what happens to a laptop when someone leaves, how backup media gets disposed of. Cloud shifts most of this to your provider, but workstations and any physical media you still handle stay in scope.

Technical

Unique logins, automatic session timeouts, encryption at rest and in transit, audit logs, and MFA. This is where engineering teams spend most of their actual effort, and where a code review can catch real gaps.

On top of the Security Rule, the Privacy Rule adds patient-facing obligations: a published Notice of Privacy Practices, minimum necessary access enforced in your application's permission model, a patient's right to access their own records, and an accounting of disclosures on request. If something goes wrong despite all of this, the Breach Notification Rule gives you a strict 60-day clock. Notify affected individuals first, and in larger incidents, HHS and the media as well.

02 Common gaps

The mistakes we see most often

These are the same five issues that show up over and over in code review, not hypothetical edge cases.

  • 01
    PHI ends up in application logs
    Error trackers and logging libraries capture whatever gets thrown at them, including request bodies. A stack trace from a patient record endpoint can silently log a name, diagnosis, or record ID. This is the single most common gap we find in code review, and it's almost always accidental.
  • 02
    Analytics and chat widgets run on authenticated pages
    A product analytics script or chat widget dropped into every page for convenience also runs on the patient dashboard, sending page content or form fields to a third party that never signed a BAA.
  • 03
    A subprocessor never signed a BAA
    Teams sign a BAA with their cloud host and stop there, missing chat platforms, error monitoring, email providers, and their vendors' own subprocessors buried in the fine print.
  • 04
    Real patient data seeded into staging
    Staging environments almost always have fewer access controls and a wider circle of developers than production. Copying a slice of production data into staging to reproduce a bug turns a lower-security environment into a live PHI exposure.
  • 05
    Patient identifiers land in the URL
    A record ID, name, or email in a query string gets written into browser history, server access logs, referrer headers, and third-party analytics tools. None of those destinations are built to treat that value as protected health information.

03 By project type

HIPAA for specific contexts

The baseline safeguards apply everywhere. Here's what shifts depending on what you're building.

EMR / EHR integrations

Usually the deepest PHI exposure on this list, full clinical records, not just contact details. Audit logging and minimum-necessary access control matter more here than almost anywhere else, since one over-permissioned role can expose an entire patient population.

Mobile health apps

Mobile adds local storage to the risk surface: cached PHI on the device, screenshots, and third-party SDKs (crash reporters, push notification services) that may not be HIPAA-aware by default. Confirm they'll sign a BAA, or exclude PHI from what you send them.

Cloud infrastructure (AWS, Azure, GCP)

Cloud providers will sign a BAA, but it only covers services on their HIPAA-eligible list. Using a non-eligible service to touch PHI isn't covered even after the BAA is signed. Confirm every service in your architecture, not just your database.

Websites and marketing sites

A site without patient-facing features can still collect PHI-adjacent data through a contact form, a symptom checker, or a "request an appointment" flow. If a field can capture health information tied to an identifiable person, that data path is in scope.

Before you rely on this

This checklist is an educational tool, not legal advice. HIPAA compliance depends on your specific systems, data, and business relationships. Consult a qualified healthcare compliance attorney or auditor before relying on any assessment.

Stay on topic

More on healthcare

Building healthcare software?

We've shipped HIPAA-aligned products for EMR integrations, telehealth, and patient portals. Tell us what you're building.

How it works

Structured around the HIPAA Security Rule's three safeguard categories (administrative, physical, technical) plus privacy and breach notification requirements and the vendor/development mistakes we see most often reviewing healthcare software builds. This is an educational tool, not a compliance certification, and does not replace review by a qualified healthcare compliance attorney or auditor.

Frequently asked questions

Two categories: covered entities (health plans, healthcare clearinghouses, and providers who transmit health information electronically) and business associates. A business associate is any vendor that creates, receives, maintains, or transmits PHI on a covered entity's behalf, most software vendors, cloud hosts, and SaaS platforms serving healthcare clients included. If your software touches PHI for a healthcare client, you're almost certainly a business associate.
A covered entity has the direct relationship with the patient, a hospital, clinic, insurer, or provider. A business associate is a vendor the covered entity uses to handle PHI on its behalf, an EMR vendor, a billing platform, a cloud host, an analytics tool. Business associates have their own direct HIPAA obligations and sign a Business Associate Agreement (BAA) with each covered entity they serve.
Encryption is technically "addressable," not strictly mandatory, but it's the standard and the safe-harbor path: encrypted PHI that's lost or stolen generally isn't a reportable breach. If you choose not to encrypt something, you need a documented reason and an equivalent alternative safeguard. For software handling PHI, encrypt at rest and in transit as the default.
AWS will sign a Business Associate Agreement and offers a defined list of HIPAA-eligible services, but AWS itself isn't "HIPAA compliant" as a blanket status, compliance depends on how you configure and use those specific services. Using a non-eligible AWS service to process PHI isn't covered by the BAA even after you've signed it.
Under HHS's tiered civil penalty structure, fines range from roughly $100 to $50,000+ per violation depending on culpability, with an annual cap per identical violation type that runs into the millions at the highest tier. Willful neglect that isn't corrected can also trigger criminal referral. Penalties scale with whether the violation was known, reasonably preventable, or the result of willful neglect.
Yes, with every vendor that can access, store, or transmit PHI on your behalf. That includes cloud hosts, error-monitoring and analytics tools, email and SMS providers, customer support platforms, and any subprocessor those vendors use in turn. A vendor that never touches PHI, only de-identified or aggregate data, doesn't need one, but that's a narrower carve-out than most teams assume.