What HIPAA Compliance Actually Requires From a Software Vendor

"We'll sign a BAA" is the answer we hear from a lot of vendors when a healthcare client asks about HIPAA compliance, and it's true as far as it goes — a Business Associate Agreement is a legal requirement for anyone handling protected health information on a covered entity's behalf. But a signed BAA describes an obligation, not a capability. It says nothing about whether the vendor's engineering practices, infrastructure, and processes actually meet that obligation day to day. We've worked with healthcare clients enough to know exactly where that gap shows up.

Technical safeguards go well beyond "our data is encrypted"

Encryption at rest and in transit is table stakes and gets mentioned in nearly every vendor pitch. HIPAA's Security Rule requires a broader set of technical safeguards, and the details matter more than the headline claim:

• Access controls with unique user identification. Every person touching PHI needs a traceable, individual login — shared service accounts or generic admin credentials are a common finding in security assessments we've run, and they're a direct compliance gap, not just a bad practice.
• Audit logging that's actually reviewed. Logging who accessed what PHI and when is required, but logs that are collected and never reviewed don't satisfy the intent of the rule. A real program includes periodic access review — someone checking whether the access pattern makes sense, not just that logs exist.
• Automatic session timeout and encryption key management with documented rotation policies, not a key generated once at system setup and never rotated.

The practical test we recommend clients run: ask the vendor to walk through, concretely, how a specific engineer would access a specific patient record for a specific debugging task, and what's logged and reviewed as a result. Vague answers here are the tell.

Administrative safeguards are where most vendors are actually weakest

Technical controls get the attention because they're demonstrable in a system walkthrough. Administrative safeguards — workforce training, access authorization procedures, incident response planning — are less visible and more often where gaps hide, because they require ongoing process discipline rather than a one-time configuration.

Ask specifically for:

1. A documented risk assessment, updated at least annually, covering how PHI flows through the vendor's systems — not a generic security policy template, but one that references the vendor's actual architecture.
2. Workforce training records showing HIPAA-specific training completion, not just general security awareness training, and including what happens when someone doesn't complete it.
3. A minimum necessary access policy — engineers and support staff should have access scoped to what their role requires, with a documented process for granting and revoking access as roles change. "Everyone on the engineering team has database access for debugging" is a common and avoidable gap.

Incident response has to be specific, not aspirational

Every vendor will say they have an incident response plan. Ask when it was last tested — a tabletop exercise or an actual incident — and what the documented breach notification timeline is. HIPAA requires notification within 60 days of discovering a breach affecting PHI; a vendor's contractual notification commitment to you should be faster than that, because you need runway to meet your own obligations to patients and regulators.

Subcontractors and the data supply chain are frequently overlooked

A vendor can have excellent internal practices and still create risk through subcontractors — a cloud hosting provider, a third-party analytics tool, an error-monitoring or logging service that PHI might flow into unintentionally through application logs. Every subcontractor that touches PHI needs its own BAA in the chain, and it's worth asking directly whether error logs, application performance monitoring tools, or analytics pipelines could inadvertently capture PHI (a patient name in a URL parameter or an error stack trace is a common accidental leak point).

We run a standard check on this for every new engagement: mapping every system that PHI touches, including logging and monitoring infrastructure, and confirming a BAA or equivalent exists for each one, or that PHI is explicitly excluded from that system by design (scrubbed before logging, for instance).

What good evidence actually looks like

When we're evaluated by healthcare clients, the conversations that go well are the ones where we can produce: a current risk assessment document, a list of subcontractors with BAA status, recent access audit samples, and a description of an actual incident (even a minor one) and how it was handled. Vendors who can produce these on request, rather than promising to "put something together," are the ones with a real program rather than a compliance posture built for the sales conversation.

None of this replaces your own legal counsel's review of the BAA itself. But the BAA is the floor, not the assessment — the questions above are what determine whether a vendor's actual practices meet the obligation they're signing up for, which is the part that protects your patients and your organization when something goes wrong.