HITRUST is an assurance program built on one control framework, the HITRUST CSF, with three main assessment levels: e1, i1 and r2. A CTO's decision is which level buyers will accept, how much of the environment goes in scope, and whether work done now carries forward to a deeper level later.
What are the levels?
According to HITRUST's own site, the e1 provides foundational assurance with 43 core controls for lower-risk entities. The i1 has 182 controls focused on leading security practices. The r2 is the most comprehensive, a risk-based and tailored assessment for complex environments, and it is described as a two-year validated assessment. HITRUST also lists an AI Security Assessment and Certification.
HITRUST says assessments are designed so that work from an e1 or i1 can be applied toward a deeper i1 or r2. Treat that as a design intention and ask your assessor what actually transfers in your case.
How is this different from HIPAA?
HIPAA is law. HITRUST is a private certification program that many healthcare buyers use as evidence of security. Passing one does not mean you satisfy the other. Compliance posts like this one explain the framework only; your counsel and assessor determine what applies to you.
How should a CTO choose?
Start from the buyer, not the badge. A constructed example: a health data startup sells to two hospital systems. One accepts a SOC 2 report plus a questionnaire. The other insists on r2. Pursuing r2 immediately would delay both deals. A sequence that fits: answer the first buyer with existing assurance, run an e1 or i1 to build the control set, and plan r2 for the second buyer with a realistic date.
Scope is the cost lever. Every system, location and data flow in scope has to produce evidence. Keep the assessed environment as tight as the buyer's requirement allows, and make the boundary explicit.
What does engineering have to deliver?
Whatever the level, expect evidence on access control, change management, vulnerability management, encryption, logging, incident response and third-party risk. Teams that already collect evidence continuously find the assessment far calmer than teams reconstructing it from memory.
What do teams underestimate?
Two things: evidence breadth and remediation time. HITRUST assessments look at implementation across the scoped environment, so a control that works in production but is undocumented in staging, or the reverse, shows up as a gap. Teams also underestimate how long it takes to fix findings that involve other departments, such as HR onboarding steps or vendor contracts, which engineering cannot close alone.
Build a gap list early and give each gap an owner outside engineering where needed. A readiness review by an assessor before the formal assessment turns surprises into a plan, and it is much cheaper than discovering gaps during validation. Also confirm whether your buyers care about the level or only about the certification existing.
How to check or apply this
- Ask each target customer in writing which HITRUST level, if any, they require and by when.
- Compare that against what your existing reports already prove.
- Define the assessment scope: systems, data flows and sites.
- Choose an authorized external assessor early and ask for a readiness review.
- Close gaps in order of how many controls each fix affects.
- Plan evidence collection for the whole assessment period, not only the final weeks.
- Calendar the renewal and interim work from day one.
Dependency inventories and vulnerability management records are common evidence items, and Safeguard's SBOM and dependency scanning can help produce them. It does not make you HITRUST certified.
Quick check
Is e1 a smaller version of r2?
It covers a smaller control set aimed at lower-risk environments. HITRUST states the work can be applied toward deeper assessments, but confirm the specifics with an assessor.
Can we skip straight to r2?
Yes if a buyer demands it, but it is the heaviest option. Check whether a lower level would satisfy the contract first.
Sources
Last reviewed: 18 October 2026.
