Does Your Series B Healthtech Company Need a Standalone HIPAA Attestation?

It usually starts the same way. Your company closes a Series B, growth is real, and your sales team lands a health plan or a hospital system as a customer. Somewhere in the contracting process, their security or vendor risk team sends over a questionnaire — and buried in it is a line item asking for "your HIPAA attestation."

Your team pauses. You have a SOC 2 report. You've never heard anyone ask for a "HIPAA attestation" specifically, and a quick search doesn't clear things up, because there's no single, universally recognized certificate called that. So what are they actually asking for, and do you need to go get one?

This comes up often enough at this stage of company that it's worth a straight answer: sometimes yes, often the better answer is a differently-scoped SOC 2, and the difference matters more for your budget and timeline than most companies realize until they're already mid-negotiation with an auditor.

What a Standalone HIPAA Attestation Actually Is

Start with what it isn't. There is no HIPAA certification issued by the Department of Health and Human Services, no government seal of approval, and no accrediting body that "certifies" a company as HIPAA compliant. HHS enforces HIPAA; it doesn't attest to anyone's compliance with it.

A standalone HIPAA attestation is a report — typically issued by a CPA firm or a qualified independent assessor — in which the assessor evaluates a company's controls against the requirements of the HIPAA Security Rule (and sometimes the Privacy and Breach Notification Rules, depending on scope) and issues an opinion on whether those controls are suitably designed and, in some cases, operating effectively over a period of time.

It's "standalone" in the sense that it isn't wrapped inside a broader SOC 2 report — it's its own deliverable, scoped specifically to HIPAA requirements rather than the AICPA's Trust Services Criteria. Some assessors structure it similarly to a SOC 2 Type I or Type II, with a point-in-time design assessment or a period-based operating effectiveness assessment. Others follow a HITRUST-adjacent control framework. The specifics vary by assessor, which is exactly why the customer asking for one usually can't tell you precisely what they mean either — they've just been told by their own compliance team to get one from every vendor touching PHI.

The Real Triggers at Series B and C

Very few companies wake up and decide, unprompted, that they need a standalone HIPAA attestation. It's almost always a response to external pressure. At the Series B/C stage, the trigger is typically one of these:

A health plan or provider customer's vendor risk team requires it contractually. This is the most common path. Once you're selling into payer or health system customers directly — rather than through channel partners who absorb some of this diligence — their own compliance obligations under HIPAA extend to you as a business associate, and their vendor risk process reflects that.

An RFP references HITRUST or "HIPAA attestation" as a requirement. Enterprise health system procurement, in particular, sometimes bakes this into RFP language even when the requesting team isn't entirely sure what deliverable satisfies it. This is worth clarifying directly with the prospect rather than guessing.

A fundraise or M&A due diligence process flags a gap. Growth-stage investors and acquirers increasingly ask compliance-related diligence questions that a standard SOC 2 doesn't fully answer if your business model touches PHI directly. This tends to surface the need earlier than a customer-driven request would.

Cyber insurance underwriting asks for it. Less common, but increasingly present as insurers scrutinize healthcare-adjacent risk more closely at renewal.

A useful signal for whether you're approaching this threshold: rising covered-entity customer count, growing PHI volume in your systems, and an increasing number of Business Associate Agreements (BAAs) you're signing. If you're tracking double-digit BAAs and most of your enterprise pipeline is direct-to-payer or direct-to-provider, this is worth getting ahead of rather than reacting to mid-deal.

Standalone HIPAA Attestation vs. SOC 2 + HIPAA vs. HITRUST

This is where most of the confusion — and most of the wasted budget — actually happens. Three different paths get conflated constantly:

For most Series B/C healthtech companies that already have or are pursuing a SOC 2, the more efficient path is usually a SOC 2 report scoped to explicitly include HIPAA-relevant criteria and controls, rather than running two fully separate engagements. It satisfies the broader enterprise audience and gives HIPAA-focused reviewers what they need, without duplicating evidence collection and audit fieldwork across two engagements.

A fully standalone HIPAA attestation makes more sense when your customer base is overwhelmingly HIPAA-focused (direct-to-payer or provider, minimal general enterprise sales) and a SOC 2 report either isn't relevant to your buyers or would require scope well beyond what you actually need.

HITRUST certification is its own conversation — it's the most rigorous and most expensive of the three, and it tends to make sense specifically when a large health system or payer customer requires it by name, since HITRUST has become something of a de facto standard for the most mature payer/provider vendor risk programs. It's rarely the first move for a Series B company; it's more often a Series C+ decision once a specific customer or class of customers requires it explicitly.

What the Process Actually Looks Like

Regardless of which path fits, the sequence is similar:

Readiness assessment. Before any formal attestation work begins, a gap assessment against the relevant control set identifies where your current policies, technical controls, and documentation fall short. This is the stage most companies underestimate — skipping it is the single most common cause of a delayed or failed first attestation.

Gap remediation. Address what the readiness assessment surfaces — this might be policy documentation that doesn't exist yet, access control gaps, missing risk assessments, or incomplete BAA tracking.

Attestation period (for Type II-style reports). If you're pursuing an operating-effectiveness opinion rather than a point-in-time design opinion, controls need to operate for a defined period — commonly 3-6 months for a first attestation — before the assessor can test them.

Fieldwork and report issuance. The assessor tests controls, gathers evidence, and issues the final report.

For a company starting from a reasonably mature security baseline (you already have a SOC 2 or are actively pursuing one), a realistic timeline from kickoff to a Type I-equivalent HIPAA attestation is 2-4 months. A Type II-equivalent report, given the operating period requirement, typically runs 6-9 months end to end for a first cycle.

The Question to Actually Ask First

Before starting any engagement, it's worth going back to whoever asked for the "HIPAA attestation" and getting specific: what deliverable are they actually expecting, and what did their own vendor risk process specifically require? Sometimes the honest answer is that a SOC 2 report with HIPAA-relevant controls clearly documented satisfies the request entirely, and no separate engagement is needed at all.

If you're trying to figure out which of these paths actually fits your situation — rather than guessing based on what a procurement email happened to say — that's usually a short, straightforward conversation, not the start of a sales process.