Beyond SOC 2
How do you know if software is HIPAA compliant?
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.