A healthcare customer's security team writes "HITRUST" into a vendor requirement, and nobody on either side says which HITRUST. The framework now supports three validated assessments, the e1, the i1 and the r2, and they differ in depth, effort and how long the result lasts.
Picking the wrong one is expensive in a quiet way. Pursue an r2 when your buyer would have accepted an i1 and you spend months on maturity documentation nobody asked for. Pursue an e1 when the contract says r2 and you do the work twice.
This article lays out what each assessment is, how they relate to each other, and the questions that settle which one you need.
What the HITRUST CSF is, briefly
The HITRUST CSF is a control framework maintained by HITRUST. It harmonizes requirements from many authoritative sources, including the HIPAA Security Rule, NIST publications, ISO/IEC 27001 and PCI DSS, into a single set of requirement statements. You are assessed against those requirement statements, not against each source separately.
Three features set HITRUST apart from most frameworks a SaaS team meets first:
It is prescriptive. You do not write your own control set against broad criteria. HITRUST tells you the requirement, and you show you meet it.
HITRUST issues the result. An authorized external assessor performs the testing, but HITRUST reviews the assessor's work through its own quality assurance process and issues the report and any certification.
The work happens in MyCSF. HITRUST's platform holds the scope, the requirement statements, the scores and the assessor's testing.
Each of the three assessment types can also be run as a readiness assessment, which you score yourself. A readiness assessment is a planning tool. It produces no certification.
The three assessments side by side
| e1 | i1 | r2 | |
|---|---|---|---|
| What it targets | Foundational cybersecurity hygiene | Leading security practices against current threats | Risk-based coverage tailored to your organization |
| Requirement set | Fixed | Fixed, refreshed by HITRUST as threats change | Tailored through scoping factors you declare |
| What is scored | Implementation | Implementation | Five maturity levels, from policy to managed |
| Certification length | One year | One year | Two years, with an interim assessment in between |
| Relative effort | Lowest | Moderate | Highest |
The names carry the logic. The "1" in e1 and i1 means a one-year certification, and the "2" in r2 means two years. The letters stand for essentials, implemented and risk-based.
What each one asks of you
e1: the essentials
The e1 covers basic cybersecurity practices: the controls a buyer would be alarmed to find missing. Think access control, malware protection, logging, backup, vulnerability management and incident response at a foundational level.
It suits an early-stage company, or a vendor whose access to sensitive data is limited and whose buyers want a validated signal rather than a deep one. It is not a stepping stone you are obliged to take. Some organizations go straight to an i1.
i1: implemented leading practices
The i1 is a larger fixed set of requirements chosen to address the threats HITRUST sees as most relevant. HITRUST describes it as threat-adaptive: it reviews the requirement set against threat intelligence and adjusts it as the CSF is updated.
Because the set is fixed, you know the scope before you start. Your work is showing that each requirement is implemented across the in-scope systems. Written policies and procedures still matter as supporting evidence, but they are not scored as separate maturity levels the way they are in an r2.
r2: risk-based and tailored
The r2 is the most comprehensive assessment. You answer scoping questions about your organization, your technical environment and the regulations you want covered. Those answers determine which requirement statements apply, so two r2 assessments can look very different.
Each requirement statement in an r2 is scored across five maturity levels: policy, procedure, implemented, measured and managed. That is the biggest practical difference from the e1 and i1. A requirement you have implemented well can still score poorly if there is no written policy or procedure behind it. HITRUST publishes a scoring rubric for each level, and it is worth reading before you commit to an r2.
The r2 certification lasts two years, and staying certified requires an interim assessment at roughly the one-year mark.
How the three relate to each other
The assessments are designed to build on one another. The e1 requirements sit largely within the i1, and the i1 requirements sit largely within a typical r2. Work you do for one is rarely wasted when you move up.
What does change is the standard of proof. Moving from an i1 to an r2 means adding documented policies and procedures for every applicable requirement statement, plus evidence of measurement and management where you want to score at those levels. Teams that underestimate the r2 usually underestimate this documentation, not the technical controls.
Choosing the right assessment
Four questions settle most decisions.
What does your buyer actually require? Read the contract, the security addendum or the vendor questionnaire. If it says "HITRUST certified" without a type, ask the buyer's vendor risk team which assessment they accept. That one email can save months.
What data do you handle, and how much? A vendor storing large volumes of protected health information for a health system faces different expectations from one processing scheduling metadata. If you are unsure where your data falls under HIPAA, start with our overview of the HIPAA Security Rule's safeguards.
Which regulations do you need mapped? If you need the assessment to speak to specific regulatory requirements, the r2's tailoring is built for that. The e1 and i1 are fixed sets by design, so ask your assessor how the current version handles regulatory coverage for each type.
Can you sustain the documentation? An r2 assumes a program mature enough to write, approve and follow procedures, and to measure its own controls. If that program does not exist yet, an i1 gives you a validated result while you build it.
A reasonable default for a SaaS company selling into healthcare for the first time: confirm the buyer's requirement, and if it is open, start with an i1. Move to an r2 when a contract demands it or when your program is ready for maturity scoring.
What people get wrong
Treating a readiness assessment as a result. A readiness score is your own view of yourself. Buyers who ask for HITRUST almost always mean a validated assessment issued by HITRUST, and a readiness report will not satisfy them.
Assuming the requirement count is fixed for an r2. It depends on your scoping answers. Declaring more regulatory factors, more system types or more exposure adds requirement statements. Make those choices deliberately, with the buyer's requirement in front of you.
Confusing HITRUST with HIPAA compliance. No HITRUST assessment makes you HIPAA compliant, and HHS does not certify HIPAA compliance at all. A HITRUST report is evidence that a defined set of controls was assessed. Whether that satisfies a legal obligation is a question for counsel.
Forgetting the clock. The e1 and i1 expire after one year, so you are re-assessed annually. The r2's two years depend on passing the interim. Plan the next assessment the day the current one is issued.
For a fuller picture of how HITRUST fits with the other frameworks you may already run, see our HITRUST framework page and the glossary for the terms that recur in assessor conversations.
How TrustLynce helps
TrustLynce maps the controls you already run for SOC 2, ISO 27001 or HIPAA to the requirements of the framework you are adding, so evidence is reused rather than gathered again (compliance automation). The readiness dashboard shows your gaps per framework before your assessor does.