HITRUST e1 vs i1 vs r2: Which Assessment Is Right for Your Organization?

HITRUST CSF offers three validated assessments — e1, i1, and r2 — that build on each other. This guide breaks down what each covers, how they are scored, what they cost in effort, and a practical decision framework for picking the right one.

If you sell software or services to healthcare organizations, you have probably been asked for a HITRUST certification. What that request rarely specifies is which HITRUST assessment the buyer expects — and getting that choice wrong is expensive in both directions. Aim too low and you re-do the work a year later when a bigger customer demands more. Aim too high and you sink months into a risk-based assessment your market never required.

HITRUST CSF resolves into three validated assessment types: e1, i1, and r2. They are deliberately nested — the controls in e1 are a subset of i1, which are a subset of r2 — so effort carries forward as you climb. The question is almost never "should we do HITRUST?" It is "which tier matches our size, our buyers, and how far along our security program already is?" This guide answers that.

The one-paragraph version

e1 is the fastest validated HITRUST certificate — 44 foundational controls proving essential cyber hygiene, valid for one year. i1 (Implemented, 1-year) covers roughly 182 controls drawn from leading practices and is the common starting point for health-tech companies selling to the mid-market. r2 (Risk-based, 2-year) is the gold standard: controls are risk-scoped to your specific environment and scored across the full five-level maturity model. Larger deals, health systems, and payers increasingly expect it. Because the tiers nest, everything you do for e1 counts toward i1 and r2.

How HITRUST scores maturity (and why it matters for the choice)

HITRUST does not just check whether a control exists — it scores maturity using the PRISMA model across five levels:

Policy – the control is documented and approved
Procedure – there is a defined process for operating it
Implemented – the control is actually in place
Measured – you collect metrics on whether it works
Managed – you review those metrics and act on them

Here is the crucial detail: e1 and i1 evaluate only the "Implemented" level. You need the control turned on, but you do not have to prove you measure and manage it. r2 evaluates all five levels. That single difference is why an r2 assessment is a materially heavier lift — it rewards organizations that not only run controls but monitor and continuously improve them.

The comparison at a glance

| Dimension | e1 (Essentials) | i1 (Implemented) | r2 (Risk-based) | | --- | --- | --- | --- | | Approx. control count | 44 | ~182 | Risk-scoped (~300+, from a 2,000+ pool) | | Certificate validity | 1 year | 1 year | 2 years | | Maturity levels scored | Implemented only | Implemented only | All 5 (Policy → Managed) | | Typical effort | Weeks | 1–3 months | 3–9+ months | | Best for | Baseline hygiene, low-risk vendors | Health-tech SaaS selling to mid-market | Selling to health systems/payers; maximum assurance | | Assurance level | Moderate | Strong | Highest |

Numbers are directional — HITRUST periodically updates the control counts, and r2 scope depends entirely on your risk factors (data volume, system complexity, regulatory exposure). Treat the table as a shape, not a spec.

A decision framework

Rather than starting from the tiers, start from three questions about your business.

1. Who are your customers, and what do their contracts say?

This is the single strongest signal. If you sell to individual practices or small clinics, an e1 certificate is usually enough to clear vendor review. If you sell to mid-market health-tech buyers or regional providers, i1 is the sweet spot — it is the tier most of those procurement teams recognize and accept. If you are selling into large health systems, hospital networks, or payers, or if a security addendum explicitly names risk-based assessment, you are looking at r2. Read the actual contract language before deciding; "HITRUST certified" in a redline often has a specific tier behind it.

2. How large and complex is your organization?

Size correlates with both risk and readiness. A small team with a simple, cloud-hosted stack can realistically stand up e1 quickly and grow into i1. A larger organization handling significant volumes of PHI across multiple systems has both the risk profile that buyers scrutinize and, usually, the control maturity that r2 rewards. If you handle PHI at all, treat i1 as your practical floor — e1 rarely satisfies a covered entity's diligence for a vendor touching patient data.

3. How mature is your existing security program?

If you have already done serious HIPAA or SOC 2 work, you are closer to HITRUST than you think. HITRUST was built substantially from the HIPAA Security Rule and NIST, and it overlaps heavily with SOC 2's Trust Services Criteria. Evidence you have already produced — access control policies, encryption attestations, audit logging, incident response — maps directly onto HITRUST controls. A strong existing posture (say, a completed SOC 2 Type II) means the incremental lift to i1 is modest and even r2 is within reach. A thin posture argues for starting at e1 to build momentum.

The nesting advantage: why "start lower" is rarely wasted

A common worry is that choosing e1 or i1 means throwing away work when you later need r2. Because the tiers are nested, that is not how it plays out. Every control you implement and every piece of evidence you collect for a lower tier is reused at the higher one. The realistic path for most health-tech companies looks like this:

Year 1: achieve i1 to unblock mid-market sales
As enterprise deals appear: extend to r2, reusing the i1 control base and layering in the "Measured" and "Managed" maturity levels

The only genuine waste comes from over-shooting — spending months on r2's measurement and management evidence for a customer base that only ever needed i1.

Common mistakes to avoid

Treating "HITRUST" as one thing. Always pin down the tier a customer actually requires before scoping work.
Jumping straight to r2 for credibility. Unless your buyers demand it, i1 delivers strong assurance at a fraction of the effort.
Ignoring cross-framework leverage. If you have HIPAA or SOC 2 evidence, map it to HITRUST controls first — your starting score is rarely zero.
Underestimating r2's maturity bar. The "Measured" and "Managed" levels require ongoing monitoring you have to demonstrate over time, not stand up the week before assessment.

How Shieldra helps you choose — and get there

Shieldra treats HITRUST as a first-class framework alongside HIPAA and SOC 2. It recommends a tier from your organization's profile — size, whether you handle PHI, who you sell to — blended with your current HIPAA/SOC 2 readiness. From there, a tier-scoped roadmap shows exactly which controls are in scope, a gap analysis tells you how many controls you are away from each tier (and which your existing work already covers), and a timeline planner estimates when you will be ready at your current pace. For r2, Shieldra tracks PRISMA maturity progression over the observation window and maps your control statuses straight into a MyCSF-ready export.

The bottom line

Choose the lowest HITRUST tier that satisfies your customers today, knowing the work compounds toward the next one. For most health-tech companies that means i1 — with e1 as an on-ramp for early-stage teams and r2 as the destination once you are selling into health systems and payers. Anchor the decision in your contracts, your risk, and the security work you have already banked, and the right tier usually chooses itself.