Few words appear on human services software marketing pages more often than "HIPAA compliant." Few phrases mean less on their own. This article explains what HIPAA actually regulates, when it applies to human services organizations, and how to evaluate what a vendor is really claiming.

HIPAA does not automatically apply to every organization

The Health Insurance Portability and Accountability Act's privacy and security rules apply to covered entities and, through them, to their business associates [1]. Covered entities are three specific kinds of organizations:

  • health plans,
  • health care clearinghouses, and
  • health care providers who transmit health information electronically in connection with certain standard transactions (such as billing a health plan) [1].

Many human services organizations are none of these. A workforce development program or a mentoring initiative that never bills health insurance may not be a covered entity at all — while a behavioral health agency billing Medicaid almost certainly is. Some organizations are "hybrid entities" where only part of the organization is covered. And organizations outside HIPAA entirely may still face confidentiality obligations from other law — 42 CFR Part 2 for substance use disorder records, FERPA for education records, state privacy statutes, and their own funding contracts. "HIPAA doesn't apply to us" is the beginning of a privacy analysis, never the end of one.

The vocabulary that matters

  • PHI (protected health information). Individually identifiable health information held or transmitted by a covered entity or business associate, in any form [2].
  • Business associate. A person or entity that performs functions or services for a covered entity involving PHI — which is exactly what a software vendor hosting your client records is, if you are a covered entity [1].
  • BAA (business associate agreement). The written contract HIPAA requires between a covered entity and each business associate, establishing what the associate may do with PHI and what safeguards it must maintain [4]. If your organization is covered and your vendor will touch PHI, a signed BAA is not optional.
  • Safeguards. The Security Rule requires covered entities and business associates to maintain administrative safeguards (policies, training, access management, risk analysis), physical safeguards (facility and device controls), and technical safeguards (access controls, audit controls, integrity, transmission security) for electronic PHI [3]. Note how much of that list is about people and policies, not software.

Why "HIPAA compliant software" is not a thing you can buy

HIPAA regulates organizations and their practices, not products. Software can be built to support compliance — encryption, access controls, audit logging, backup, the willingness to sign a BAA — but compliance itself depends on implementation, policies, training, user behavior, agreements, and the rest of your environment. The same system can be part of a compliant operation in one organization and a violation waiting to happen in another that shares passwords and never runs a risk analysis.

So when a vendor says "HIPAA compliant," the useful translation is: "ask us specific questions." A checklist that stops at the marketing phrase tells you almost nothing.

Vendor responsibilities vs. your responsibilities

A vendor acting as your business associate is directly responsible under HIPAA for safeguarding the PHI it holds, complying with its BAA, and reporting breaches to you [1] [4].

Your organization remains responsible for its own compliance program: risk analysis, policies and procedures, workforce training, minimum necessary access decisions, client rights processes, and choosing and configuring vendors appropriately [2] [3]. Buying well-designed software transfers none of that.

Questions to ask a vendor

These questions work regardless of whether HIPAA technically applies to you — they are simply good due diligence for any system holding sensitive client information.

  1. Will you sign a BAA? If you are a covered entity and the answer is no, the conversation is over.
  2. How is data encrypted — in transit and at rest?
  3. How is access controlled? Role-based permissions, unique accounts, multi-factor authentication. (See role-based permissions and security controls.)
  4. Are user actions logged, and can we review those logs? (See audit trails.)
  5. How are backups handled, tested, and restored?
  6. How are security incidents handled, and what are your breach notification commitments and timelines?
  7. What subprocessors do you use (hosting, subcontractors), and do you have agreements with them?
  8. Where is data stored, and what happens to it across environments?
  9. How is account termination handled — both a departing staff member's access and your data if you leave the vendor?
  10. How do documents and integrations handle PHI? Attachments and data flowing through document storage or an API are still PHI.

Our product research records what vendors document about several of these areas — see the security sections of individual product profiles — but verifying answers for your own procurement remains your work.

The bottom line

HIPAA is narrower than the marketing suggests (it may not apply to you at all) and broader than a feature list (if it applies, it governs your whole operation, not just your software). Establish whether and where it applies to your organization, demand a BAA when it does, ask vendors concrete questions about safeguards — and remember that the strongest encryption in the world does not compensate for a program that never trained its staff.