--- question: "How do you know if software is HIPAA compliant?" title: "How to Know If Software Is HIPAA Compliant" seoTitle: "How to Tell If Software Is HIPAA Compliant: 4 Checks" summary: "No software is HIPAA compliant by itself; compliance attaches to how an organization uses it. The practical test is 4 checks: (1) the vendor will sign a Business Associate Agreement (BAA), (2) the product supports the required technical safeguards (encryption, access controls, audit logs, automatic logoff), (3) the vendor holds third-party security attestations such as SOC 2, ISO 27001, or HITRUST as supporting evidence, and (4) it is configured and used correctly on your side. A vendor that refuses a BAA is disqualifying on its own. 'HIPAA certified' badges are marketing; there is no official HIPAA certification, so a badge proves nothing without the four checks behind it." publishedAt: "2026-08-22" keywords: - "how to know if software is HIPAA compliant" - "HIPAA compliant software checklist" - "BAA software vendors" - "HIPAA technical safeguards software" pillar: "Beyond SOC 2" faqs: - question: "Is there an official HIPAA certification for software?" answer: "No. HHS does not certify software, vendors, or organizations, and no government body issues a HIPAA certificate. Any 'HIPAA certified' badge reflects at most a private assessment the vendor paid for, and sometimes nothing at all. Evaluate software on whether the vendor signs a BAA and whether the product supports the required safeguards, not on badges." - question: "Does a BAA make software HIPAA compliant?" answer: "No. A BAA is necessary but not sufficient. It creates the legal relationship HIPAA requires with a vendor that handles PHI, but compliance also depends on the product's technical safeguards and on your configuration: who has access, whether audit logging is on, and how your staff actually use it. A signed BAA with a misconfigured account is still a violation waiting to be found." - question: "Is SOC 2 the same as HIPAA compliance?" answer: "No. SOC 2 is a general security attestation against the AICPA Trust Services Criteria; HIPAA is a US law about protected health information with its own required safeguards and the BAA mechanism. A vendor's SOC 2 report is good supporting evidence that its security controls operate, and many SOC 2 reports include a HIPAA mapping, but neither one substitutes for the other." - question: "What is the difference between HITRUST and HIPAA?" answer: "HIPAA is a US law; HITRUST is a private, certifiable security framework. HITRUST consolidates requirements from HIPAA, NIST, ISO, and other sources into one assessment a vendor can be certified against, and healthcare enterprises often accept that certification as strong evidence toward HIPAA expectations. Holding a HITRUST certification is still not the same thing as complying with the law." - question: "How do I become HIPAA certified?" answer: "It depends on whether you mean an organization or a person. An organization cannot become HIPAA certified, because no official certification exists; it complies with the rules and evidences that through a risk assessment, safeguards, BAAs, and, when buyers ask, a private third-party attestation. An individual can buy a HIPAA training certificate from a training provider, which has no legal standing but is commonly kept as a workforce training record." --- ## How do you know if software is HIPAA compliant? You cannot, because no software is HIPAA compliant on its own. HIPAA regulates organizations, covered entities and their business associates, and compliance attaches to how a tool is used, not to the tool. The practical test is 4 checks: the vendor signs a BAA, the product supports the required technical safeguards, the vendor has independent security attestations as supporting evidence, and the software is configured and used correctly on your side. Fail any one and PHI in that software is a problem, whatever the marketing page says. ### The 4 checks and what to ask for | # | Check | What to ask the vendor for | |---|---|---| | 1 | Will they sign a BAA? | A signed Business Associate Agreement before any PHI enters the system. A refusal is disqualifying by itself; note that some vendors sign only on higher-priced plans | | 2 | Does it support the technical safeguards? | Encryption in transit and at rest, role-based access controls, unique user accounts, audit logs of who accessed what, and automatic logoff or session timeout | | 3 | Is there independent evidence of their security? | A SOC 2 Type II report (under NDA), an ISO 27001 certificate, or a HITRUST assessment. Supporting evidence only; none of these equals HIPAA compliance | | 4 | Is it configured and used correctly by you? | Their admin or implementation guide for HIPAA settings; then do your part: restrict access, enable logging, train staff, include the tool in your risk assessment | ## "HIPAA certified" badges are marketing There is no official HIPAA certification. HHS does not certify software and does not accredit anyone else to. When a product page says "HIPAA certified," it means the vendor paid for a private assessment, or in the worst case, that someone made a badge. Private assessments can be genuinely useful evidence, but the badge alone tells you nothing you can rely on. The checks above are what the badge is trying to shortcut. ## Where the checks come from Checks 1 and 2 map directly to the law. The BAA requirement comes from the Privacy Rule: any vendor that creates, receives, or transmits PHI on your behalf is a business associate and must be under a BAA. The technical safeguards in check 2 come from the Security Rule, which names access control, audit controls, integrity, authentication, and transmission security as the categories a covered system has to address. Check 3 is not in the law at all, which is exactly why it matters to say so. A SOC 2 report tells you the vendor's security controls were examined by an independent auditor, which is the best generally available signal that checks 1 and 2 are more than promises. Treat it as evidence about the vendor, never as proof of your own compliance. Check 4 is where most real-world failures happen. A compliant-capable product with shared logins, logging disabled, and no offboarding process puts you in violation with every safeguard technically available and none of them operating. ## Where Screenata fits If you are the software vendor on the receiving end of these questions, Screenata's HIPAA and SOC 2 programs produce the artifacts buyers ask for in checks 1 through 3: a documented risk assessment, policies generated from scans of your actual infrastructure, and cryptographically signed evidence packs, with about 70% of evidence collected automatically. Which vendors sign BAAs, and on which plans, is tracked in our [BAA directory](/hipaa).