HITRUST Certification: e1, i1 and r2 Assessments for Health-Tech Vendors

HITRUST certification has become a common requirement for software and service vendors selling into US healthcare. Hospitals, health systems and payers each used to send vendors their own security questionnaire; HITRUST offers one framework and one independently validated certification that many of them accept instead. For health-tech companies, a HITRUST certificate can shorten procurement and replace dozens of questionnaires.

HITRUST is a private framework, not a government requirement, and it is not a "HIPAA certification". It harmonises HIPAA, NIST, ISO/IEC 27001, PCI DSS and other sources into one control set, and offers three main assessment types, e1, i1 and r2, with increasing depth, plus an AI security add-on. This guide explains the framework, the assessments, the process and timelines, inheritance from cloud providers, costs and common mistakes.

What is HITRUST?

HITRUST (originally the Health Information Trust Alliance) is a private organisation that maintains the HITRUST CSF, a certifiable framework of security and privacy requirements, and the HITRUST Assurance Program, which defines how organisations are assessed and certified. Its main components:

• HITRUST CSF: a harmonised set of requirement statements drawn from many authoritative sources, including the HIPAA Security Rule, NIST SP 800-53 and the NIST Cybersecurity Framework, ISO/IEC 27001 and 27002, PCI DSS, state privacy laws and others, organised into assessment domains.
• MyCSF: HITRUST's platform where assessments are scoped, performed, documented and submitted.
• Authorised external assessor firms that validate an organisation's assessment.
• HITRUST quality assurance, which reviews every validated assessment before a certification is issued.
• Shared Responsibility and Inheritance Program, which lets organisations inherit requirements already validated for their cloud and service providers.

History and why HITRUST was introduced

HITRUST was founded in 2007 by healthcare and technology organisations frustrated by the inconsistency of security expectations in healthcare. HIPAA's Security Rule is flexible and does not prescribe specific controls, so every covered entity interpreted it differently and sent vendors different questionnaires. The first CSF was released in 2009 to provide a prescriptive, certifiable framework that mapped to HIPAA and other standards.

Over time HITRUST added more authoritative sources, privacy requirements, and a range of assessment types. Version 11 (2023) introduced the e1 and i1 assessments alongside the r2, and a threat-adaptive approach in which requirement statements are updated based on threat intelligence. HITRUST updates the CSF regularly; v11.9.0 was released in September 2026. In 2024 HITRUST introduced an AI security assessment and certification that can be added to e1, i1 or r2 assessments.

Who needs HITRUST?

• Health-tech SaaS vendors whose products handle protected health information for providers and payers.
• Business associates such as billing, coding, claims, analytics and telehealth companies.
• Cloud and managed service providers serving healthcare.
• Healthcare organisations themselves, as a structured way to manage and show their security.

It is required only by contract. Some large US health systems and payers require vendors to obtain a specific HITRUST assessment type within a set period, often depending on the vendor's risk tier. Outside US healthcare, demand is lower, though HITRUST is used in other sectors too.

Assessment types: e1, i1 and r2

	e1 (Essentials, 1-year)	i1 (Implemented, 1-year)	r2 (Risk-based, 2-year)
Purpose	Foundational cybersecurity hygiene	Leading security practices against a broad threat set	Broad, risk-based assurance
Requirement statements	Fixed baseline (44 in recent versions)	Fixed baseline (182 in recent versions)	Tailored by scoping and risk factors; typically several hundred
Scoring	Implementation	Implementation	Maturity across policy, procedure, implementation and optionally measured and managed
Validity	One year	One year	Two years, with an interim assessment
Typical use	Lower-risk vendors, first step	Moderate-risk vendors	High-risk vendors and those required by customers to hold r2

The i1 baseline is a subset of the r2, so moving from i1 to r2 builds on existing work. Each assessment type has minimum score requirements per domain for certification; check HITRUST's current assessment handbook.

AI security certification

HITRUST offers an AI security assessment that can be added to e1, i1 or r2 assessments for organisations deploying AI systems, with requirements covering AI-specific threats such as model and data poisoning, prompt injection and supply chain risks. It results in an AI security certification alongside the core certification.

Key requirement areas

The CSF organises requirements into assessment domains covering, among others: information protection programme; endpoint protection; portable media security; mobile device security; wireless security; configuration management; vulnerability management; network protection; transmission protection; password management; access control; audit logging and monitoring; education, training and awareness; third-party assurance; incident management; business continuity and disaster recovery; risk management; physical and environmental security; and data protection and privacy.

For a SaaS product, assessors focus heavily on access control (MFA, least privilege, access reviews), audit logging and monitoring, encryption in transit and at rest, vulnerability and patch management, secure configuration, incident response, third-party risk management and backup and recovery.

How r2 scoping and maturity scoring work

The r2 differs from the e1 and i1 in two ways that drive most of its effort.

Tailoring by scoping factors

Instead of a fixed list, an r2 starts with questions about the organisation and the system in scope: for example, the volume of records handled, number of users and interfaces, whether the system is accessible from the internet, whether it is hosted by a third party, and which regulatory factors apply (HIPAA, PCI DSS, state privacy laws, NIST frameworks and so on). MyCSF uses the answers to generate the requirement statements for the assessment. Adding regulatory factors your customers do not actually require can add many statements without adding value, so choose them deliberately.

Maturity levels

For each requirement statement in an r2, the assessor scores maturity across levels based on HITRUST's adaptation of a maturity model: whether there is a policy requiring the control, a procedure describing how it is done, evidence that it is implemented consistently across the scope, and, optionally, whether it is measured and managed with metrics and corrective action. Each level is scored on how fully it is met. Organisations with good technical controls but thin documentation are often surprised by r2 results, because policy and procedure levels count. Writing short, accurate procedures that match practice is one of the most effective preparation steps.

What the i1 means for engineering teams

The i1's fixed baseline concentrates on practices that defend against common attacks. For a software team, the work typically includes: enforcing MFA for remote and privileged access; maintaining asset and software inventories; hardening and patching servers, containers and endpoints on defined timelines; scanning for vulnerabilities and tracking remediation; encrypting sensitive data at rest and in transit; centralising logs and reviewing security events; backing up data and testing restores; managing vendor risk for critical providers; training staff; and running an incident response process with tests. Teams already running SOC 2 or ISO/IEC 27001 controls usually find the gaps are in consistency and evidence rather than in missing technology.

How the HITRUST process works

1. Decide the assessment type based on customer requirements and risk.
2. License MyCSF and define scope: the platform, systems, facilities and services.
3. For r2, answer scoping factors (organisational, system and regulatory factors) that determine which requirement statements apply.
4. Use inheritance for requirements your cloud provider has already had validated.
5. Run a readiness or self-assessment to find gaps, and remediate.
6. Engage an authorised external assessor to perform the validated assessment, testing evidence for each requirement statement.
7. Submit to HITRUST for quality assurance review.
8. Receive the certification letter if scores meet thresholds; otherwise a validated report without certification, and corrective action plans as required.
9. Maintain: annual reassessment for e1 and i1, interim assessment and biennial recertification for r2.

Documentation you will need

• Scope definition, system descriptions and data flow diagrams.
• Policies and procedures covering each domain (essential for r2 maturity scoring).
• Evidence of implementation for each requirement: configurations, screenshots, logs, reports and records.
• Risk assessment and risk treatment records.
• Third-party inventory and assurance documents.
• Incident response and business continuity plans with tests.
• Training records.
• Inheritance records from service providers.

Timeline and cost considerations

Timelines depend on assessment type and readiness. An e1 is designed to be achievable quickly; an i1 takes longer; an r2 commonly takes many months from scoping to certification, including remediation, assessor fieldwork and HITRUST QA. Costs include the MyCSF subscription and assessment fees paid to HITRUST, external assessor fees, remediation and tools, and significant internal staff time. Inheritance from certified cloud providers can reduce effort.

Benefits and the risk of not having it

HITRUST gives a recognised answer to healthcare customers' security due diligence, reduces questionnaire volume, and provides a structured programme mapped to HIPAA and other standards. The r2 maturity scoring also helps organisations see whether controls are just implemented or actually managed.

There is no legal penalty for not having HITRUST, but vendors may lose deals or face contract deadlines to obtain it. HITRUST certification does not guarantee HIPAA compliance or protect against breaches; HHS does not recognise any certification as proof of HIPAA compliance.

Common mistakes and challenges for IT companies

• Choosing r2 when customers would accept i1, or the reverse. Ask customers which assessment they require.
• Scope that is too broad. Limit scope to the platform customers use.
• Weak policies and procedures, which hurt r2 maturity scores even when technical controls are good.
• Not using inheritance from certified cloud providers.
• Underestimating evidence collection: every requirement statement needs testable evidence.
• Calling HITRUST "HIPAA certified".

Best practices, tools and technologies

• Build on an ISO/IEC 27001 or SOC 2 programme; much evidence carries over.
• Automate evidence where possible from identity, cloud, logging and scanning tools.
• Write procedures that match how teams actually work, with owners and frequencies.
• Use cloud providers that participate in HITRUST inheritance.
• Start with an e1 or i1 to show progress while preparing for r2.

We build the technical safeguards HITRUST assessors look for into health-tech products and SaaS platforms.

HITRUST vs SOC 2 vs ISO/IEC 27001

	HITRUST	SOC 2	ISO/IEC 27001
Owner	HITRUST Alliance	AICPA	ISO and IEC
Output	Certification and validated report	Attestation report	Certification
Controls	Prescriptive requirement statements harmonised from many sources	Organisation-designed controls against Trust Services Criteria	Risk-selected controls against Annex A
Main market	US healthcare	US enterprise	Global

How HITRUST relates to other frameworks

Framework	Relationship
HIPAA	HITRUST maps to the HIPAA Security Rule, but certification is not a government recognition of HIPAA compliance.
SOC 2	Some firms issue combined SOC 2 and HITRUST reports; evidence overlaps.
ISO/IEC 27001	One of the sources harmonised in the CSF.
NIST CSF and NIST SP 800-53	Mapped into the CSF.
HITECH Act	Amended HIPAA; HITECH's recognised security practices provision can take account of frameworks such as HITRUST in enforcement.

Real-world implementation examples

Many large health-tech and cloud companies publish their HITRUST certifications, and HITRUST publishes annual reports on certified organisations' breach rates and threat trends. Several large US health systems publicly require HITRUST from vendors above a risk threshold.

An illustrative case for a telehealth SaaS company: two health system prospects require HITRUST within a year of signing. The company, already SOC 2 certified, chooses an i1 first, inherits physical and infrastructure requirements from its certified cloud provider, writes missing procedures, and closes gaps in mobile device management and log review. It achieves i1 certification, then plans an r2 for the following year as the larger customer requires.

Next steps

1. Ask customers which HITRUST assessment type and timeline they require, and whether an existing SOC 2 report can bridge the gap meanwhile.
2. Define a tight scope around the product they use.
3. Run a readiness assessment in MyCSF.
4. Close gaps and arrange inheritance from providers.
5. Engage an authorised assessor and plan for annual or biennial cycles, budgeting staff time for evidence collection each time.
6. Publish your certification status for customers on a trust page or in your security documentation.

Frequently asked questions

Is HITRUST required by law?

No. It is a private framework. It becomes required when customers write it into contracts.

Is HITRUST the same as HIPAA compliance?

No. HITRUST maps to HIPAA requirements and provides evidence, but HHS does not recognise any certification as proof of HIPAA compliance.

What is the difference between e1, i1 and r2?

e1 covers essential cybersecurity hygiene, i1 covers a broader fixed set of leading practices, and r2 is a tailored, risk-based assessment with maturity scoring and two-year validity.

How long is a HITRUST certification valid?

One year for e1 and i1, and two years for r2 with an interim assessment.

What is the current HITRUST CSF version?

Version 11, with v11.9.0 released in September 2026. HITRUST sets which versions may be used for new assessments.

Can we inherit controls from our cloud provider?

Yes, through HITRUST's Shared Responsibility and Inheritance Program, when the provider has validated the requirements.

Should we get SOC 2 or HITRUST?

Follow customer demand. US healthcare customers often ask for HITRUST; other US enterprises usually ask for SOC 2. Many health-tech vendors hold both.

Who performs HITRUST assessments?

HITRUST-authorised external assessor firms, with HITRUST performing quality assurance before certification.

Does HITRUST cover AI?

Yes. HITRUST offers an AI security assessment and certification that can be added to e1, i1 or r2 assessments.

What happens if we do not reach the certification threshold?

You receive a validated assessment report without certification, and you can remediate and reassess. Customers can still see the report, but most contracts that require HITRUST expect certification.

Can offshore development teams be in scope?

Yes. If staff in other countries access the in-scope systems, their devices, access and processes are part of the assessment, and assessors will want evidence for them too.

Can a non-US company get HITRUST?

Yes. Vendors anywhere can be assessed, which is common for offshore development and support providers to US healthcare.