In 2023, OCR settled with a telehealth platform for $1.25 million after an investigation revealed the company's software transmitted protected health information without encryption and lacked even basic access controls. The vendor had marketed itself as "HIPAA certified" — a term that gave its healthcare clients false confidence. Here's the uncomfortable truth about HIPAA certification for software: HHS does not certify, endorse, or approve any software product as HIPAA compliant. Understanding what that means — and what you actually need to demonstrate — is critical if your organization develops or deploys health technology.

Why There Is No Official HIPAA Certification for Software

Unlike HITRUST or SOC 2, HIPAA does not have a formal certification body or program that reviews and stamps software products. The Department of Health and Human Services has stated this explicitly: no government agency or private organization is authorized to issue official HIPAA certification.

This catches many software vendors off guard. They assume that passing an audit or purchasing a compliance badge means their product is "HIPAA certified." It does not. What the Security Rule under 45 CFR §164.306 actually requires is that covered entities and business associates implement administrative, physical, and technical safeguards that are reasonable and appropriate for their environment.

So when a healthcare organization asks whether your software has HIPAA certification for software compliance, they're really asking: can you demonstrate that your platform meets the Security Rule's requirements and that you'll sign a Business Associate Agreement (BAA)?

What Software Vendors Must Actually Demonstrate

If your software touches, stores, transmits, or processes protected health information (PHI), your organization almost certainly qualifies as a business associate under HIPAA. That designation triggers a full set of obligations under the HIPAA Omnibus Rule.

Here's what OCR expects you to have in place:

  • A thorough risk analysis — 45 CFR §164.308(a)(1)(ii)(A) requires you to conduct an accurate and thorough assessment of potential risks and vulnerabilities to ePHI. This is the single most cited deficiency in OCR enforcement actions.
  • Encryption in transit and at rest — While the Security Rule treats encryption as "addressable," OCR has made clear through enforcement that failing to encrypt ePHI without a documented, equivalent alternative is a significant risk.
  • Access controls and audit logging — Your software must enforce role-based access, unique user identification, and automatic logoff provisions per 45 CFR §164.312.
  • A signed Business Associate Agreement — Every covered entity that uses your platform needs a BAA in place before any PHI is exchanged. No exceptions.
  • Workforce training — Every employee at your organization who handles PHI must receive documented HIPAA training. Completing a recognized HIPAA training and certification program gives your team the foundation to handle PHI responsibly and demonstrates good faith compliance efforts.

The Risk Analysis Gap That Sinks Software Companies

In my work with covered entities and their technology partners, the most common failure point is the risk analysis. Software companies often treat security as an engineering concern — penetration tests, vulnerability scans, code reviews — while ignoring the broader administrative and physical safeguards that HIPAA demands.

A proper risk analysis under the Security Rule isn't a one-time checklist. It requires identifying every system that touches ePHI, evaluating threats and vulnerabilities specific to your environment, assessing the likelihood and impact of each threat, and documenting the security measures you've implemented in response. OCR's 2024 enforcement trends show that inadequate or missing risk analyses remain the top finding in settlement agreements.

Your development and operations teams need to understand these requirements firsthand. Investing in workforce HIPAA compliance training ensures that engineers, product managers, and support staff all understand the regulatory guardrails they're building within.

Third-Party Certifications That Strengthen Your Position

While official HIPAA certification for software doesn't exist, several third-party frameworks can help you demonstrate compliance rigor to prospective healthcare clients:

  • HITRUST CSF Certification — Maps directly to HIPAA requirements and is widely recognized by large health systems and payers.
  • SOC 2 Type II — Validates that your organization maintains effective controls for security, availability, and confidentiality over time.
  • ISO 27001 — An international standard for information security management systems that covers many Security Rule requirements.

None of these replace your HIPAA obligations. They supplement them. A covered entity reviewing your software will still want to see your BAA, your risk analysis documentation, your breach notification procedures, and evidence that your workforce has been trained.

Handling Breach Notification When Your Software Is the Source

Under the Breach Notification Rule (45 CFR §§164.400-414), if your software experiences an unauthorized disclosure of PHI, you must notify every affected covered entity without unreasonable delay — and no later than 60 days after discovery. The covered entity then bears the responsibility for notifying individuals and, if 500 or more are affected, HHS and local media.

Software vendors that lack incident response plans or breach notification procedures put their clients at regulatory and legal risk. OCR has pursued enforcement actions against business associates directly since the Omnibus Rule expanded their liability in 2013.

Applying the Minimum Necessary Standard to Software Design

Healthcare organizations consistently struggle with the minimum necessary standard, and software vendors can either make this easier or harder. Your platform should be architected so that users only access the PHI they need for their specific function. Broad, unrestricted data access across roles is a design failure with regulatory consequences.

Build minimum necessary principles into your product — granular permissions, data segmentation, and field-level access controls. When covered entities evaluate your software, this is often a deciding factor.

How to Prove Compliance Without a Government-Issued Certificate

Since you can't obtain an official government HIPAA certification for software, your goal is to build a compliance package that withstands scrutiny from healthcare clients, auditors, and OCR investigators. That package should include:

  • A current, documented risk analysis and risk management plan
  • Written policies and procedures addressing all Security Rule standards
  • Evidence of regular workforce training with completion records
  • A template or executed BAA
  • An incident response and breach notification plan
  • Any third-party audit reports (SOC 2, HITRUST, penetration test results)

This documentation tells prospective clients — and OCR — that your organization takes HIPAA seriously, even without a formal certification to point to. Healthcare organizations increasingly require this level of evidence before onboarding any technology vendor, and the vendors who prepare proactively win contracts faster.

The bottom line: don't wait for a covered entity to ask whether your software is compliant. Build the program now, train your workforce, and document everything. That's the closest thing to HIPAA certification for software that actually exists — and it's what regulators and clients are looking for.