Nobody can sell you a HIPAA certification, including us. HHS does not certify software, developers or agencies — there is no credential to hold, no badge that means anything, and no vendor logo that changes that fact. What you can do is check your product against the same safeguards a hospital's security team, a covered entity's compliance officer or an investor's technical diligence pass will actually look for. That is what this checklist is: fifteen questions across seven categories, built from the same list we work through on every HIPAA-aware build.
We also built an interactive version of this checklist that scores your answers, bands the result and shows exactly which of the seven categories is weakest. This page is the explanation behind each item; the tool is the fifteen-minute version.
Why a checklist instead of "are you HIPAA compliant"
That question has no yes-or-no answer, because HIPAA compliance is not a state a product achieves once — it is a set of administrative, physical and technical safeguards applied to a specific system handling specific data, reviewed against a specific covered entity's risk analysis. A vendor's "HIPAA compliant" badge on a landing page is marketing copy, not a legal status.
What a real review actually does is walk through categories like the seven below and ask, for each one, whether the safeguard exists and whether it is documented. That is a checklist exercise, which is why this page is one instead of a definition.
The seven categories
1. Data inventory
- We've documented every place PHI enters, is stored and leaves our system.
- We know exactly which third-party vendors and subprocessors ever touch PHI, and have a current list.
This is the precondition for everything else. You cannot secure, log access to, or write a breach plan for data whose location you have not mapped. Teams that skip this step almost always discover, mid-audit, a place PHI landed that nobody remembered — a support ticket attachment, a CSV export someone emailed themselves, a staging database seeded from production.
The practical exercise: trace one patient record from the moment it's created to every system that ever touches a copy of it, including logs, backups, analytics and support tools. Most teams find at least one surprise the first time they do this honestly.
2. Vendor agreements & tracking SDKs
- Every vendor that touches PHI — hosting, analytics, email, SMS, error-tracking — has a signed BAA with us.
- We've reviewed our analytics and crash-reporting SDKs to confirm none of them receive PHI in event payloads.
This is where we see the most expensive gaps in practice, and it is rarely the database. It's the marketing and observability stack: a session-replay script recording an intake form, an analytics event carrying a patient's name or diagnosis in its properties, a crash report that captures the screen state — including whatever was on it — at the moment of the crash.
A few vendor positions worth knowing before you assume anything:
- Twilio SendGrid will not sign a BAA at any tier. SendGrid's own documentation states it is not a HIPAA-eligible service and must not be used for any purpose involving PHI — including as a delivery layer for transactional emails that reference patient data. A common wrong assumption: a Twilio BAA does not extend to SendGrid, even though Twilio owns it. (Twilio's own HIPAA documentation)
- Firebase Analytics, Crashlytics and Cloud Messaging are not on Google Cloud's HIPAA-covered products list. Firestore, Cloud Storage, App Engine and Identity Platform are. If your app fires a Firebase Analytics event on an authenticated, PHI-adjacent screen, that event is leaving a covered environment. (Google Cloud's HIPAA compliance page)
- Sentry signs a BAA on Business tier and above, non-trial accounts only. A team running error tracking on a lower tier or a trial account has no agreement in place, whatever the invoice says about "enterprise features." (Sentry's support documentation)
The rule of thumb we build to: no third-party tag runs on an authenticated screen, an intake form, or any URL whose path itself reveals a condition, unless that vendor has signed a BAA and the integration is configured to exclude identifiers. Marketing pages, yes. Anything past login, no — by default, not by exception.
3. Encryption
- PHI is encrypted at rest in our database and file storage.
- PHI is encrypted in transit on every endpoint that touches it, including internal service-to-service calls.
This is the safeguard everyone already has an opinion about, and the one least likely to be the actual gap in a real review. Encryption at rest and in transit is table stakes on any modern cloud platform — the mistake is usually coverage, not technique: an internal service that talks to another internal service over plain HTTP because "it's inside the VPC," a backup that isn't encrypted the same way the primary store is, a third-party webhook payload logged in plaintext before it reaches the encrypted store.
4. Access control & identity
- Access to PHI is role-based, not shared logins or blanket admin access.
- We can revoke a single user's access to PHI immediately, without affecting anyone else.
- Sessions accessing PHI expire automatically after a period of inactivity.
One shared clinic login used by six front-desk staff. A contractor whose credentials still work months after the engagement ended. A support tool where every agent can see every patient's record regardless of which one they're helping. None of this shows up in a product demo. All of it shows up in a review, and the fix is unglamorous rather than technically hard: unique identities, roles scoped to a job function, automatic session expiry, and an offboarding process that actually revokes access the day someone leaves.
5. Audit logging
- Every read and write of a PHI record is logged with who, what and when.
- Audit logs are tamper-evident and retained for at least six years.
The first question a hospital security reviewer asks is rarely about your cipher suite. It's whether you can produce, for a given patient and a given week, the list of every account that viewed the record. Products that log writes but not reads cannot answer that question, and retrofitting a read-audit trail into a schema that was never designed for it is a genuinely expensive project — expensive enough that it's worth doing before the schema exists rather than after.
Six years is not an arbitrary number: it's the retention period specified in the HIPAA Security Rule's documentation requirements at 45 CFR 164.316(b)(2)(i).
6. Breach response
- We have a written breach-notification plan naming who does what within the legally required window.
- We've actually rehearsed the breach plan, not just written it down.
A written plan is table stakes; almost every team that's thought about compliance at all has one. What almost nobody has is a plan they've actually run once — a tabletop exercise where someone plays "we just found evidence of unauthorized access" and the team works through who gets notified, in what order, and what gets said. The gap between a document and a rehearsed process is exactly the gap that shows up in the first confused hour of a real incident.
7. Segregation of the regulated core
- The parts of our system that handle PHI are architecturally separated from the parts that don't.
- A new engineer joining the team could explain, from documentation alone, exactly where PHI lives.
A marketing site, a general analytics pipeline and a PHI-handling core that are architecturally tangled together mean every safeguard above has to be applied everywhere, all the time, which in practice means it gets applied inconsistently. Segregating the regulated core early — a separate service, a separate database, a clear boundary a new hire can point to — is what makes every other item on this list tractable instead of a permanent audit risk.
What HIPAA actually requires you to be, first
Before any of the above matters, it's worth confirming HIPAA reaches your product at all. It applies directly to covered entities — providers, health plans, clearinghouses — and to the business associates handling PHI on their behalf under a signed agreement. A direct-to-consumer wellness app with no provider or payer relationship is often outside HIPAA entirely, though other regimes (the FTC's health-data rules, state privacy laws) can still apply.
If you're not sure which category you're in, that's an hour of legal counsel's time well spent before it costs you a quarter of engineering budget building safeguards a different regime doesn't actually require — or worse, skipping them because you assumed you were exempt.
What it costs when this goes wrong
HIPAA civil penalties are tiered by the degree of culpability, and the dollar figures adjust annually for inflation. For 2026, effective 28 January (using the 1.02598 inflation multiplier applied that year), the per-violation minimums across the four tiers are $145, $1,461, $14,602 and $73,011, with an annual cap of $2,190,294 per violation category at the top tier. (HIPAA Journal's penalty summary)
Those figures are civil penalties from HHS's Office for Civil Rights, not the full cost of a breach — breach notification, credit monitoring, legal fees, lost deals during a security review that surfaces the gap, and reputational damage with the covered entities you were trying to sell to all sit on top.
One more thing worth knowing if you're tracking where the regulatory ground might move: a Security Rule update was proposed via an NPRM published 6 January 2025, with the comment period closing 7 March 2025. As of this writing it remains a proposed rule, not law — worth watching, not worth building to yet.
How to actually use this
- Score yourself honestly on the interactive checklist. Leave a box unchecked if you're not sure — an unverified safeguard behaves like a missing one the moment someone asks you to prove it.
- Start with your weakest category, not your favorite one. The tool ranks them for you. Most teams are strong on encryption (it's the easy part) and weak on audit logging and the vendor/SDK map (the parts that require actually auditing your own stack, not just picking a cloud provider with a good compliance page).
- If you're pre-launch, fix this before the schema exists. Retrofitting audit logging and access control onto a system already holding real PHI is a materially harder and more expensive project than designing them in from day one. This is the single highest-leverage moment to run this checklist — before you've shipped, not after a hospital's security team asks you to.
- If a specific gap is a genuine engineering project, that's what HIPAA-compliant app development and the Healthtech & Mental Health MVP Blueprint — a seven-day, $1,999 planning engagement that adds an intended-use boundary, a sensitive-data and claims inventory and a clinical dependency map — exist for. Both are credited toward the build.
Frequently asked questions
What is a HIPAA compliance checklist?
A structured list of the administrative, physical and technical safeguards a HIPAA-covered product needs — data inventory, vendor agreements (BAAs), encryption, access control, audit logging, breach response and system segregation. It's a practical proxy for what a real security review checks, not a legal reading of the Security Rule's full implementation specifications.
Is my app HIPAA compliant?
There's no single yes-or-no test. HIPAA compliance is a property of how a specific system handles specific data, reviewed against safeguards like the seven categories above — and it starts with confirming HIPAA applies to you at all, which depends on whether you're a covered entity, a business associate, or neither. Score your product against the checklist as a starting point, and get a legal opinion before making a compliance claim to a buyer.
Can I get HIPAA certified?
No — there is no such thing. HHS does not certify software, developers or agencies. Any badge or certificate claiming to be "HIPAA certified" is a training company's marketing, not a government credential. What you can hold is a signed BAA, documented safeguards, and a clean answer when a covered entity's security team asks how you handle PHI.
What is the most common HIPAA gap in software products?
Analytics and crash-reporting SDKs receiving PHI in event payloads without anyone noticing — a field name or a raw error message carrying a patient's name or diagnosis straight into a tool with no BAA behind it, like Firebase Analytics or an unsigned Sentry tier. It's rarely the database that fails a review; it's the observability and marketing stack layered on top of it.
Do I need a BAA if I don't store PHI myself?
If any vendor in your stack — hosting, analytics, email, SMS, error tracking, customer support — ever receives or processes PHI on your behalf, yes. This includes vendors you might not think of as "handling health data," like a crash reporter that captures screen state or an email service that includes patient details in a notification. See BAAs explained for what signing one actually commits you to.
How much does HIPAA compliance cost to build in?
It's rarely a separate line item — it's how the build is done. A healthcare prototype on synthetic data starts at $3,500. A Healthtech & Mental Health MVP Blueprint, which includes the sensitive-data and claims inventory, is $1,999 over seven days. MVP builds with the PHI-handling core segregated start at $12,000. The full breakdown is in what HIPAA compliance actually costs a startup.
What happens if I fail a hospital's security review?
Usually a list of specific findings and a chance to fix them before the deal proceeds — not an automatic rejection. Most failed reviews we see aren't exotic: missing audit trails, shared admin accounts, PHI in logs, or a subprocessor with no BAA in place. Those are fixable without a rewrite, which is what an App / Product Rescue engagement ($2,500 over 10 days) is built to assess and fix.