When your healthtech startup needs HITRUST (and when it does not)
A Series A healthtech CEO called me last summer because his board had just told him he needed to be HITRUST CSF (Health Information Trust Alliance Common Security Framework) certified. Not e1, not i1. The board member said “HITRUST,” and he wrote it down. He had budgeted $80,000 for it. He thought he could start in Q3 and have it by end of year.
I asked him one question: “How many of your top ten prospects have asked for HITRUST in writing?”
He paused. He went back through his pipeline. The answer was one. A health system in the Midwest had mentioned it as part of a vendor questionnaire, but it was not a contract requirement. The other nine prospects had asked for SOC 2 and HIPAA documentation, nothing more.
He saved $80,000 and a year of distraction by asking the question before signing the engagement letter. That conversation is the post I wish someone had written for me four years ago, so I am writing it now.
What HITRUST actually is, briefly
HITRUST is a private certification body that publishes a control framework called the CSF. The CSF maps to most major regulatory and industry frameworks: HIPAA, the National Institute of Standards and Technology (NIST) Cybersecurity Framework, ISO 27001, SOC 2 trust service criteria, and others. When you pursue HITRUST certification, an authorized external assessor evaluates your environment against the CSF and HITRUST itself issues the certification report.
HITRUST publishes three certification tiers. The choice between them is the most consequential decision in this entire process, and most founders make it backwards.
| Tier | Controls | Validity | Typical use |
|---|---|---|---|
| e1 | 44 | 1 year | Foundational cyber hygiene; entry point |
| i1 | 182 | 1 year | Standard health system vendor requirement |
| r2 | ~385 average | 2 years | High-risk vendors, large payers, federal |
Two updates from the last 24 months are worth flagging because they change the math. Common Security Framework version 11 reduced the i1 control set from 219 down to 182, so any timeline or cost figure you read from a 2023 article is overstated. And in 2024, HITRUST introduced a combined e1 and i1 assessment (advisory HAA 2024-004), which lets a startup pursue e1 now and i1 in the same engagement instead of paying for two separate efforts.
There is also a new ai1/ai2 AI Security Assessment released in 2025 that adds 44 AI-specific controls mapped to the NIST AI Risk Management Framework. This is only relevant if you are deploying proprietary models. If you are calling OpenAI or AWS Bedrock, you are not eligible for ai1.
That is the framework. Now the question that actually matters.
The pipeline test
Before you open a quote with an external assessor, before you let a board member’s offhand comment turn into a budget line, do this.
Pull your top ten active or target prospects. Open each of their security questionnaires, RFPs (Requests for Proposal), or vendor contracts. Count the ones that have explicitly named HITRUST as a requirement. Not “we expect strong security.” Not “we prefer vendors with industry certifications.” HITRUST, by name, in writing.
If the count is zero or one, you do not need HITRUST yet.
If the count is two, you have a watchlist signal. Get to know which tier those buyers actually require (more on this below) and revisit in a quarter.
If the count is three or more, you have a real business case. Now we can talk about which tier.
This sounds simple. It is also the step almost no founder does before committing. The pressure to “be ready” pushes them past the diagnostic, and they spend $100,000 chasing a certification their pipeline does not require. The HITRUST 2025 Trust Report shows that more than 60% of new HITRUST customers start with e1, which tells me the market is full of organizations realizing, after the fact, that they needed less than they thought.
I have never seen a healthtech startup regret skipping HITRUST when no buyer asked for it. I have seen many regret pursuing it on speculation.
The tier is not about your size, it is about how the buyer classifies you
The second mistake founders make: they pick a tier based on their company size or maturity. “We are Series B, so we should do r2.” This is the wrong axis.
The tier you need is determined by how your buyer classifies your vendor risk, not by your headcount. The Provider Third Party Risk Management (PTRM) Council, a group of health system Chief Information Security Officers (CISOs), announced in March 2022 that they accept i1 certification for low-to-moderate risk vendors. That is the most concrete primary source you will find for “what tier do I actually need.”
Most early-stage healthtech vendors fall into the low-to-moderate risk bucket. You are at the edge of clinical workflows, not inside them. Your product handles protected health information (PHI) but does not drive clinical decisions in real time. For these vendors, i1 is the standard. r2 is overkill.
If your product processes PHI for large-scale clinical decision support, sits inside the electronic health record (EHR), or your buyer is a major federal contractor, you may need r2. The most demanding health plans and federal mandates still require it. But “may” is doing real work in that sentence. Confirm before you commit.
The conversation to have with your prospect, before you spend a dollar on certification, is one sentence: “How does your procurement team classify a vendor that does what we do?” If they say low-to-moderate risk, i1 is your target. If they say high-risk or critical, r2 is on the table. If they cannot answer, i1 is still your safer bet, because you can upgrade to r2 later if a specific buyer requires it. You cannot down-shift from r2 once you have committed budget and time.
What it actually costs and how long it takes
Most of the cost and timeline figures floating around online are out of date or vendor-optimistic. Here is what current data shows for a first certification.
| Tier | All-in first-year estimate | Realistic timeline (first cert) |
|---|---|---|
| e1 | ~$35K-$65K | 1-3 months to submission, plus 4-8 weeks of QA |
| i1 | ~$65K-$105K | 4-9 months from kickoff to certification |
| r2 | ~$90K-$180K+ | 9-18 months for the first certification |
These ranges include the assessor fee, the report credit, and a MyCSF subscription ($18,100 as of HITRUST’s March 2024 pricing guide). They do not include internal labor costs. In my experience, a from-scratch i1 runs another 200 to 400 engineering and security hours of internal effort.
Two timeline notes. HITRUST’s own i1 page lists 6-12 months as the typical range, which is more conservative than what well-prepared organizations achieve with a compliance platform. r2 includes a mandatory 90-day evidence collection window that no amount of preparation can compress, plus QA and remediation cycles that typically push the total past a year.
If anyone tells you i1 takes 3 to 4 months for a first certification, they are either describing a best-case scenario with a mature compliance program already in place, or they have not been through it.
One cost note worth flagging for early-stage founders. HITRUST runs a RightStart Program for companies founded within the last three years with under 50 full-time employees. Discount terms are not publicly disclosed, but the program exists specifically for the audience reading this post. Ask your assessor whether you qualify before you sign a quote.
The SOC 2 head start is real, and bigger than most realize
If you already have SOC 2 in place, HITRUST is not a fresh start. The overlap is significant and well documented.
For e1, HITRUST’s own data shows 36 of the 44 controls map directly to SOC 2 trust service criteria. The same source quantifies it as “90%+ of evidence and controls required for e1 can come from a SOC 2 audit.” That is the highest-confidence overlap figure in the entire HITRUST literature, and it comes from HITRUST itself.
For r2, SOC 2 gets you about 60% of the way there. The remaining 40% is the work that makes r2 r2: the deep risk management documentation, the broader scope, the maturity scoring against each control, and the specific HITRUST-only requirements like incident response testing at a defined cadence.
The implication for sequencing: if your pipeline tells you i1 is coming, start with SOC 2 first. Not because SOC 2 is easier (it is not, in healthtech), but because the SOC 2 evidence base becomes the foundation for everything that follows. Pursuing HITRUST without a SOC 2 program in place means you are building two evidence sets in parallel, which is the most expensive way to do this.
The 2026 HIPAA Security Rule changes I wrote about a few weeks ago make this even more pronounced. As the addressable specifications become required, the gap between “SOC 2 + HIPAA” and “HITRUST i1” shrinks further. A startup building to the new HIPAA baseline already covers more of the i1 control set than the same startup would have two years ago.
When to pursue HITRUST anyway
I have spent most of this post talking founders out of HITRUST. To be fair, here is when I tell them the opposite.
Three or more named-prospect requirements. Your pipeline test came back at three or more buyers asking by name. The math now favors certification. Lost deal value will exceed the certification cost.
A signed contract conditional on certification. A health system has executed an agreement with a clause requiring HITRUST i1 within 12 months. This is the cleanest business case. The deal is real. The deadline is real. Start.
A category where HITRUST is table stakes. Some categories (revenue cycle management, claims processing, large-scale care coordination platforms) have effectively standardized on HITRUST. If your competitors are all certified and your category buyers reflexively ask for it, the certification is the ticket to be considered. Not having it costs you the meeting.
Federal contracting in your near-term roadmap. Federal healthcare contracts and contracts with federally regulated entities increasingly reference HITRUST. r2 is often the implicit floor.
If you fit one of these patterns, the next conversation is about sequencing and tier, not whether to do it. If you do not fit any of them, the answer is to keep building on SOC 2 and HIPAA and revisit in two quarters.
A few things that are commonly wrong
Three misconceptions I correct in almost every founder conversation.
HITRUST does not replace HIPAA. HIPAA is federal law. HITRUST is a voluntary certification that maps to HIPAA controls. Getting HITRUST certified does not mean you have completed a HIPAA audit. You still need your Business Associate Agreements (BAAs), your risk analysis, and your HIPAA-specific documentation.
HITRUST does not replace SOC 2 either. Health system procurement teams routinely require both. SOC 2 is the baseline enterprise credibility document. HITRUST is the healthcare-specific assurance. They overlap on controls, but the deliverables are different and so are the buyer use cases.
You do not have to certify your entire organization. HITRUST is scoped to a defined environment. A startup can scope to its PHI-handling systems and exclude adjacent infrastructure that has nothing to do with healthcare data. Scope discipline is one of the most consequential decisions in the entire process.
The ROI question, with appropriate hedging
The most cited statistic in HITRUST marketing right now comes from HITRUST’s 2026 Trust Report, which states that 99.62% of HITRUST-certified environments remained breach-free in 2025, and that none of the top 50 healthcare breaches reported to the Office for Civil Rights occurred in HITRUST-certified environments.
That number is striking. It is also self-reported by HITRUST, drawn from breach disclosures within their certified population, and not independently audited. I cite it because it is the best data we have, and because the directional claim (certified environments experience meaningfully fewer breaches) is consistent with what I see in practice. But I would not put it on a slide as if it were a peer-reviewed result. Use it as evidence of a trend, not proof of one.
The honest ROI argument for HITRUST is simpler than the breach statistic. Certification unlocks a category of buyer that will not otherwise sign a contract with you. If those buyers are in your pipeline, the certification pays for itself in one closed deal. If they are not, no statistic will make the math work.
The short version
Before you commit to HITRUST, do the pipeline test. Count the prospects asking for it by name. If the answer is zero or one, your time and money belong somewhere else. If the answer is three or more, ask each buyer how they classify your vendor risk. That answer determines your tier.
Build SOC 2 first. The overlap is too significant to ignore, and the evidence base becomes the foundation for whatever comes next. If you are already doing the work to meet the 2026 HIPAA Security Rule changes, you are closer to i1 than you think.
If you are reading this in the middle of a HITRUST scramble that started without that diagnostic, it is not too late to stop, regroup, and re-scope. The cost of pausing is much smaller than the cost of finishing the wrong tier.
The pattern I keep coming back to with HITRUST is the same one I see across compliance work generally. The expensive mistakes are not the ones founders make during the engagement. They are the ones made before the engagement starts, when a board member’s offhand comment turns into a budget line and nobody asks the prospects what they actually need. The diagnostic is cheap. The certification is not. Run the diagnostic first.