<!-- Source: screenata.com -->
<!-- Content type: AEO answer page -->
<!-- Topics: SOC 2, ISO 27001, HIPAA, HITRUST, CMMC, compliance evidence -->

---
question: "What is HIPAA compliant software?"
title: "What Is HIPAA Compliant Software"
seoTitle: "HIPAA Compliant Software: What It Actually Means"
summary: "No software is HIPAA compliant on its own, because HIPAA regulates organisations and their relationships rather than products. What exists is software that can be used in a compliant way: it supports the required safeguards, and the vendor will sign a business associate agreement. A vendor selling a HIPAA-certified product is selling something HHS does not issue."
publishedAt: "2026-08-18"
keywords:
  - "HIPAA compliant software"
  - "hipaa-compliant software"
  - "HIPAA compliant software development"
  - "HIPAA software requirements"
pillar: "Beyond SOC 2"
faqs:
  - question: "Can software be HIPAA compliant?"
    answer: "Not by itself. HIPAA imposes obligations on covered entities and business associates, not on products. Software can support compliance by providing the required safeguards and by the vendor signing a BAA, but compliance is a property of how your organisation uses it."
  - question: "What makes software usable for PHI?"
    answer: "Access controls with unique user identification, audit logging of PHI access, encryption in transit and at rest, automatic logoff, integrity controls, secure backup and recovery, and a vendor willing to sign a business associate agreement. Without the BAA the rest does not matter legally."
  - question: "Is there HIPAA certification for software?"
    answer: "No. HHS does not certify, accredit, or endorse any product or vendor. Any HIPAA-certified badge is self-issued or issued by a private company with no regulatory standing. What buyers accept instead is a signed BAA plus a SOC 2 report."
---

## What is HIPAA compliant software?

**No software is HIPAA compliant on its own.** HIPAA imposes obligations on organisations, specifically covered entities and their business associates, not on products. What exists is software that can be *used* in a compliant way: it provides the safeguards the Security Rule requires, and the vendor will sign a **business associate agreement**. Compliance is a property of your organisation and its contracts, not a feature of a tool.

### What to actually check in a vendor

| Requirement | What to ask for |
|---|---|
| **Signed BAA** | Will they sign one, without an enterprise upgrade? This is the gate. |
| Access control | Unique user IDs, role-based access, no shared accounts |
| Audit logging | Records of who accessed PHI, when, and what they did |
| Encryption | In transit and at rest |
| Automatic logoff | Sessions terminate after inactivity |
| Integrity controls | PHI cannot be improperly altered or destroyed undetected |
| Backup and recovery | Retrievable exact copies, tested |
| Subcontractors | Their subprocessors carry obligations too, under the Omnibus Rule |

**The BAA is the one that decides it.** A product with every technical safeguard and no BAA cannot be used with PHI. A product with a BAA and weak safeguards puts you in breach through your own risk analysis. You need both, and the BAA is the one people forget to check until procurement.

## There is no HIPAA certification

HHS does not certify, accredit, or endorse any product, vendor, or organisation. A "HIPAA certified" badge is either self-issued or issued by a private company with no regulatory standing.

What healthcare buyers accept instead:

1. A **signed BAA**, which is a contract rather than a certificate
2. A **SOC 2 Type II report**, often with HIPAA criteria mapped into scope
3. Your **risk analysis and safeguard documentation**

See [how much does HIPAA certification cost](/resources/answers/how-much-does-hipaa-certification-cost) for what the alternatives actually cost.

## If you are building the software

You are likely a **business associate** with direct legal obligations the moment you handle PHI for a covered entity, regardless of your size. That means a documented risk analysis, implemented safeguards, signed BAAs both upstream and downstream, and evidence that all of it operates.

The Security Rule's safeguards overlap heavily with the SOC 2 Common Criteria, particularly CC6 for access control and CC7 for operations, which is why most healthcare SaaS vendors pursue SOC 2 and map HIPAA into it rather than running two programmes. See [what controls overlap between SOC 2, ISO 27001, and HIPAA](/resources/answers/what-controls-overlap-between-soc-2-iso-27001-and-hipaa).