Skip to main content

Explainers

HIPAA Eligible vs HIPAA Compliant: What the BAA Requires

HIPAA eligible is an infrastructure claim, not a certificate. Here is what the BAA obliges you to configure and how to read a covered services list.

Solomon AmosPublished 21 Sep 202610 min read

"HIPAA eligible" and "HIPAA compliant" turn up on the same vendor pricing page more often than not, and buyers treat the two phrases as interchangeable. They are not. Eligible is an infrastructure claim: the cloud platform underneath a product has the encryption, logging and access controls that a compliance programme could rely on. Compliant describes an outcome that belongs to the customer, not the vendor, because HIPAA regulates covered entities and their business associates, not software products. No product ships compliant the way it ships encrypted at rest. A buyer who reads eligible and assumes the whole platform is safe to hold patient records in is skipping the two documents that actually settle the question: the Business Associate Agreement (BAA) and the covered services list inside it. This piece works through what eligible is doing in that sentence, what the BAA obliges the customer to configure, and how to read a covered services list so a rollout does not stall on a service that was never in scope. See CertReports' HIPAA framework page for the current index of vendors with a signed BAA on file.

Why vendors say eligible instead of compliant

When a cloud platform's legal team writes "HIPAA eligible", they are describing a technical baseline: the region, service or product has the controls a covered entity's Security Rule safeguards could plug into, things like encryption at rest, encryption in transit, audit logging, and a willingness to sign a BAA. That word choice is deliberate. Compliance under the Security Rule at 45 CFR 164.308 to 164.312 depends on how the customer configures access, retains logs, trains staff and runs risk assessments, none of which the vendor controls. A vendor that promised "compliant" would be making a claim about someone else's environment. Eligible is the honest version of that sentence: the plumbing exists, the customer still has to turn the taps.

HIPAA has no certificate, so what does compliant even mean

Unlike PCI DSS, which ends in a signed Attestation of Compliance, or ISO 27001, which ends in a certificate from an accredited body, HIPAA has no accrediting scheme for products or companies. When a vendor's sales page says "HIPAA certified", the phrase is inaccurate: no government agency or accreditation body issues that certificate, and the Department of Health and Human Services' Office for Civil Rights does not pre-approve or badge products. What OCR does is investigate complaints and reported breaches, and it can issue corrective action plans or civil penalties against covered entities and business associates after the fact. Compliant is a state a covered entity's whole environment is in, checked retrospectively by an auditor, a regulator or a breach investigation, never handed out in advance as a badge.

A business associate is a person or entity that performs functions or activities on behalf of, or provides certain services to, a covered entity that involve access to protected health information.

The Business Associate Agreement: the only document that matters

The BAA is the contract that turns a vendor from an anonymous processor into a party the Privacy Rule can hold accountable. It sets out the permitted and required uses of protected health information, the safeguards the vendor must apply, the timeline for breach notification, and what happens if the vendor uses a subcontractor who also needs a downstream BAA. None of that is visible from a marketing page. If a vendor cannot produce a BAA on request, or only offers one after a sales call and a higher-tier contract, treat the word eligible on its homepage as a starting point, not an answer.

Diagram comparing HIPAA eligible infrastructure against a signed BAA and a named covered service
Eligible is a vendor claim about infrastructure. Covered is a specific service named in a signed BAA.

Who signs the BAA, and who doesn't

The covered entity, typically the healthcare provider, insurer or clearinghouse, or its downstream business associate, signs the BAA with the vendor as the second business associate in the chain. On the vendor side, it is usually the legal or compliance team, not sales, because the agreement carries liability for breach notification and indemnification. What often trips buyers up is scope: a BAA signed by procurement for the enterprise contract does not automatically extend to a free trial account, a personal workspace created before the contract existed, or a subsidiary using its own billing entity. Each of those needs its own signed agreement or an explicit amendment naming it.

TermWhat it actually meansWho determines it
HIPAA eligibleThe vendor states its infrastructure can support PHI processing once configured correctly and a BAA is signedThe vendor, in its own documentation
HIPAA compliant, as a product claimAn unverifiable claim, since HIPAA has no product certification; the phrase actually describes a customer's whole control environment, not a SKUNo one; treat it as marketing language, not evidence
BAA-covered serviceA specific named service listed in the vendor's Business Associate Addendum as approved for protected health informationThe vendor's legal or compliance team, listed by name
Configured for PHIThe customer has applied the vendor's required settings, such as encryption, logging and access controls, inside a covered serviceThe customer, checked against the vendor's own configuration guide

Four phrases that get flattened into one sentence on a pricing page.

How to read a covered services list

Large platforms rarely put the whole product under a BAA. AWS, Microsoft and Google each publish a named list of HIPAA-eligible services, and only the services on that list may be used to store, process or transmit protected health information under the agreement. A team that spins up a new managed service, a beta feature, or a third-party integration outside that list has moved outside the BAA even though the parent account is covered. The fix is procedural, not technical: check the list before architecture decisions are made, not after go-live.

  1. 1

    Locate the current BAA or addendum

    Ask the vendor directly or check their trust or legal page. A cached PDF from a sales call two years ago is not evidence of the current terms.

  2. 2

    Open the covered services list by name

    Match it against the exact service names you intend to use, not the product family. "Storage" is not a service name; the specific bucket or database product is.

  3. 3

    Map your architecture against the list

    Flag any service, integration or beta feature in your stack that is not explicitly named as covered.

  4. 4

    Apply the vendor's HIPAA configuration guide

    A covered service still needs encryption, logging and access settings turned on; coverage is not automatic.

  5. 5

    Keep the signed BAA and the dated services list on file

    Both documents change over time. Re-check them at renewal, not just at signing.

The configuration the BAA pushes onto you

Signing a BAA transfers obligation, not automation. The agreement typically requires the customer to apply a specific set of settings inside the covered service before it can legally hold protected health information, and most of these are off by default because they cost performance, storage or usability.

  • Encryption at rest and in transit turned on for every dataset touching PHI, using keys the customer controls where the vendor offers that option
  • Audit logging enabled and retained for the period the vendor's HIPAA guide specifies, not the platform default
  • Role-based access control and multi-factor authentication applied to any account with PHI access
  • Subprocessors restricted to the vendor's own published, BAA-covered list, with none of your own third-party add-ons bypassing it
  • Data residency and backup settings checked against the covered region, since a backup routed through an uncovered region breaks the chain
Flowchart of the four checks a healthcare buyer runs before storing PHI in a SaaS product
Eligible, BAA, covered service list, and customer configuration: four separate checks, not one.

Why BAA coverage often stops at the enterprise tier

Audit logging, single sign-on and dedicated infrastructure cost the vendor money to run, so they tend to sit behind the highest-priced plan. A team that signs up on a starter or team tier and later discovers PHI capability was never on offer at that level has not misread the contract; it read a homepage that said eligible without checking which tier the BAA actually attaches to. CertReports' BAA checklist walks through the specific clauses to confirm before a contract is signed, including whether the plan you are buying is the plan the BAA names.

What CertReports records against a HIPAA entry

CertReports does not score HIPAA compliance, because there is no scheme to score against. What the index records is dated evidence: whether a vendor publishes a BAA, the URL and date it was last checked, and the named covered services list where one is published. Where a vendor makes no BAA available, the entry says exactly that, with no public evidence, rather than guessing at a status the vendor has not disclosed.

0
HIPAA certificates that exist for SaaS products
there is no accrediting body for HIPAA; only a signed BAA and configuration evidence, confirmed in the CertReports index on 2026-09-21
3
hyperscale clouds offering a standard BAA
AWS, Microsoft Azure and Google Cloud each publish one, in the CertReports index on 2026-09-21
2
documents a buyer actually needs
the signed BAA and the named covered services list, not a homepage badge, in the CertReports index on 2026-09-21

Intercom's trust report shows how that looks on a real vendor. The HIPAA line sits among its other frameworks, but the detail beside it says whether a BAA offer was captured or only a badge, which is the difference this article is about.

Intercom logo

Intercom · Trust report

Customer support · Public evidence as of 21 Sep 2026

Visit trust centreFull evidence

Framework overview

CertReports state for each framework with public evidence: 1 verified, 10 vendor-stated.

2 more frameworks on the evidence page

2Documents and agreements

Legal and review documents Intercom publishes or offers, as of 21 Sep 2026.

1Security practices

Public statements from Intercom, shown as statements, not attestations, as of 21 Sep 2026.

  • Penetration testing · annual

14Subprocessors

Named on Intercom's public subprocessor list, last seen 21 Sep 2026.

A HIPAA badge on a trust centre, recorded as a badge until the BAA is captured. Every line is a dated public record from the Data Privacy Framework list and Intercom's trust centre. A framework not shown means no public evidence was found, not that Intercom lacks it.CertReports

Three mistakes that create false confidence

  • Treating a BAA as a completed risk assessment, when it is a legal agreement that still requires the customer's own Security Rule documentation and staff training
  • Assuming a whole account is covered because one workspace or one business unit signed a BAA, when sibling accounts and lower tiers often were not included
  • Skipping the covered services list because the parent platform is described as eligible, then storing PHI in a new or beta feature that was never named in the agreement

People also ask

What does HIPAA eligible mean?

It means a vendor's infrastructure, such as a specific cloud service or region, has the technical controls a HIPAA-covered organisation could rely on: encryption, logging and a willingness to sign a Business Associate Agreement. It is a statement about the platform's readiness, not proof that any particular customer account is actually covered or correctly configured. You still need a signed BAA naming the exact service you plan to use.

Can a SaaS product be HIPAA certified?

No. There is no government agency or accreditation body that issues a "HIPAA certified" mark, unlike ISO 27001 or PCI DSS, which do end in a certificate or attestation. HIPAA compliance is a state a covered entity's whole environment is in, assessed through risk analysis, audits or an OCR investigation after a complaint or breach, never awarded in advance as a badge on a pricing page.

Who signs the BAA?

The covered entity, such as a healthcare provider or insurer, or its downstream business associate, signs the BAA with the vendor providing the service. On the vendor's side it is usually the legal or compliance team rather than sales, since the agreement carries liability for breach notification, subcontractor oversight and permitted uses of protected health information.

Does a BAA cover every plan tier?

Usually not. Features that make PHI processing feasible, such as audit logging, single sign-on or dedicated infrastructure, are often restricted to the highest-priced tier, and the BAA typically names only that tier or those specific services. A team signed up on a lower tier may find the vendor is HIPAA eligible in principle but the BAA does not actually extend to the plan it bought.

hipaabaahealthcare saascompliance evidencebusiness associate agreement
S

Solomon Amos · Founder, CertReports

Solomon builds CertReports, the public evidence index for vendor security reviews. PhD in machine learning and cybersecurity, two years embedded at HMRC digital programmes, founder of TapTax. He writes about what registries, trust centres and auditors actually publish, and how buyers can use it before the questionnaire goes out.

Read next on CertReports

You might also like