Navigating HITRUST v11 Requirements: What Has Changed for Healthcare Orgs

Recently, we have observed that Healthcare organizations are facing various kinds of cybersecurity issues while protecting their patient data. They also have to secure their systems while keeping the clinical systems, cloud infrastructure, API, and various digital applications operational. The implementation of HITRUST v11 will redefine cybersecurity assurance in healthcare organizations.

Organizations can secure sensitive information through a shift to a more threat-adaptive approach, nested assessment levels, and better alignment with existing cybersecurity risks. New versions of the v11 framework keep adding new requirements and authoritative source mappings.

This HITRUST migration guide is designed to explain the most important changes, differences between HITRUST e1, i1, and r2 requirements, the migration process, and typical mistakes of migration to v11.

Key Takeaways

• v11 includes e1, i1, and r2 evaluations.
• E1 is the baseline security evaluation, and I1 adds another 182 controls for threats.
• r2 takes i1 a step further by requiring risk-based controls.
• MFA, Cloud computing, APIs, Ransomware, and Encryption need better controls.
• Begin the migration process with a gap assessment, not a MyCSF assessment.
• Gathering evidence continuously will help avoid any assessment gaps and delays.

Why Did HITRUST Introduce Version 11 (v11)?

Version 11 of HITRUST was released in order to increase relevance to today’s threats, as well as minimize redundant assessments. In addition, v11 shifts away from being a rigid list of compliance controls to taking a threat-based approach with nested assessments.

Responding to Modern Threats

Outdated compliance methods may no longer be effective when security controls remain unchanged while attack techniques continue to evolve. Checklists rapidly go out of sync with real attack techniques, leading to false confidence.

HITRUST version 11 requirements are intended to respond to threats like:

• Credential theft and credential stuffing: Safeguarding against automated brute-force attacks and credential theft directed at the workforce.
• Ransomware and data extortion: Protection against malicious software and extortion schemes intended to disable clinical workflows.
• Exploitation of internet-facing applications: Protecting publicly exposed internet applications against remote code execution and tampering.
• Security vulnerabilities related to API: Protection against data breaches by preventing broken object-level authorizations and unauthenticated API calls.
• Privilege escalation and unauthorized access: Prevention of lateral movement within sensitive network segments and administrative consoles.
• Health data exposure across the cloud: Protection against cloud security misconfigurations and permissive access policies.

Making Scope Easier

The new version also makes assessment entry points clear via e1, i1, and r2. This means that there are some tools to choose a proper assurance level for a specific organization according to its risks, environment, and needs. Rather than applying one standard control load for every assessment.

This is especially helpful for startups working in the field of health technologies or Software as a Service. It helps in providing security assurance for their enterprise healthcare customers without taking a full assessment burden at once.

What Are the Major Differences Between HITRUST v10 and v11 Frameworks?

What Are the Major Differences Between HITRUST v10 and v11 Frameworks?

The key difference between the HITRUST v11 vs v10 frameworks is the shift to a more systematic and threat-adapted approach to assessments. The HITRUST v11 included nested assessment baselines, allowing organisations to extend their existing efforts from lower assessment baselines.

Threat-Adaptive Baseline Assessment

The i1 assessment tool is made up of 182 requirements aimed at offering moderate, threat-adaptive assurance. According to HITRUST, the controls are chosen to tackle current and new cyber threats and make the primary, foundational baseline of r2.

The fact that there is a structural emphasis gives the assessment much more real-life application value. The test evaluates whether necessary technical and administrative controls are applied effectively to mitigate real-world threat vectors. It goes beyond checking whether policy manuals exist.

Nested Controls Reduce Rework

Version 11 employs a nested model. This includes:

• e1: Foundational cybersecurity assurance 
• i1: 182 requirement statements, including the full e1 baseline
• r2: Includes the 182 i1 requirements in its baseline and incorporates customized requirements based on risk-based scoping.

The original version 11 e1 baseline includes 44 requirement statements. The updated version 11.7/11.8 e1 baseline includes only 43 requirement statements, while i1 has remained unchanged at 182. 

The HITRUST organization confirmed that all the e1 requirements are fully incorporated in the i1, and all i1 requirements are fully incorporated in r2.

What Are the Different HITRUST v11 Assessment Levels?

The three main HITRUST assessment levels are e1, i1, and r2. Each provides a distinct level of cybersecurity assurance suited for different business stages and operational profiles.

The HITRUST e1 i1 r2 differences:

HITRUST’s current materials confirm e1 as 43 core controls, i1 as 182 control requirements, and r2 as its highest-level tailored assurance.

What Is HITRUST e1?

HITRUST e1 certification ensures basic cybersecurity coverage. This certification is concerned with security measures that organizations must implement in order to address basic cybersecurity risks.

Some of these focus areas include:

• Two-factor authentication: Enforced two-factor authentication at critical administrative access points.
• Patch management: The process of discovering and fixing known vulnerabilities in software applications.
• Asset management: Accurate tracking and documentation of hardware and software assets.
• Access control: Enforcement of access roles to limit exposure to sensitive information.
• Basic security monitoring: Recording of necessary event logs to identify suspicious actions.
• Safeguarding of sensitive information: Critical controls on the handling of sensitive health information.

The common consensus is that it works well for organizations that want to prove basic security assurance to their partners without implementing i1 or r2. One notable change is the fact that the latest version of the e1 baseline (v11.7) has a total of 43 requirements after the revision carried out by HITRUST in December 2025.

What Is HITRUST i1?

HITRUST i1 certification provides moderate, threat-adaptive assurance based on 182 requirement statements. The certification places significant emphasis on the implementation of security controls in the production environment.

It means showing that the organization is able to defend against existing cyber threats. They can defend by implementing practical safeguards, and not simply through documented policies and procedures.

Technical evidence required for an I1 assessment would include:

• Security configurations: Screenshots, exported policies, and system baselines.
• System and access logs: Audits that show evidence of central logging and logging of events.
• Vulnerability management: Scan reports indicating timely discovery and mitigation of vulnerabilities.
• Authentication configurations: Parameters for Active Directory or Identity Provider authentication.
• Backup configurations: Automated logs that show proof of backups being run regularly.
• Network security configurations: Firewall rules, security group rules, and network segment diagrams.

According to HITRUST requirements, i1 is specific to implementation and adaptability to threats and is valid for one year.

What Is HITRUST r2?

HITRUST’s r2 assessment represents the most robust level of assurance. It involves a custom risk-based methodology specific to the technical size and risk profile of the organization.

r2 does not use a static checklist but builds up the I1 foundation and adds more requirements depending on the risk profile of the organization as well as other assessment-specific tailoring factors.

This assessment assesses security maturity across five separate grading scales:

• Policy: Written policies that outline organizational standards for administration.
• Procedure: Detailed instructions for implementing the process of technical implementation.
• Implementation: Enforcement of controls throughout all in-scope systems.
• Measurement: Auditing, testing, and monitoring of control effectiveness.
• Management: Means for fixing identified weaknesses in the controls and updating the controls.

The r2 assessment is valid for two years from when it was conducted, depending on the interim assessment requirements carried out after one year.

Struggling with HITRUST V11 Compliance? We Can Help.

Our compliance experts help you achieve and maintain Hitrust v11 certification — from gap assessment to remediation to final audit support.

Book Your Assessment Now
→

What are the Key Security Updates in HITRUST V11 Impacting Healthcare Organizations?

The key healthcare cybersecurity compliance updates for HITRUST v11 focus on stronger MFA, cloud and API security, and ransomware protection. It also focuses on encryption.

Strong MFA Protection

MFA is not just another layer of authentication or sending out another message through text message anymore. Healthcare organizations should look at how resistant their methods are to sophisticated attacks aimed at MFA systems.

Phishing-resistant MFA, such as FIDO2 tokens or certificate authentication, has become one of the expectations during HITRUST compliance reviews. That applies to:

• Remote access and corporate VPNs
• Privileged administrative accounts and root environment access
• Management of cloud platforms and continuous integration tools
• Any systems with sensitive health data stored or processed
• Make sure that a stolen password or even a One-Time Password can’t be misused

Cloud and API Visibility

Current applications in healthcare usually rely on complex cloud environments such as AWS, Azure, and GCP. They also rely on SaaS systems, microservices, APIs, containerization, and CI/CD processes.

The security team should have real-time visibility into:

• Drift from cloud configurations: Identifying unauthorized changes that bypass security baseline controls.
• Internet-facing services: Identification of all endpoints facing outwards and public assets.
• Authorisation of third-party APIs: Enforcing least privilege scoping on integrations.
• Securing CI/CD pipeline: Protection of deployment pipelines from unauthorized code commits.
• Access and identity permissions: Review of cloud IAM roles for unnecessary permissions.
• Security groups of networks: Checking for restricted ingress and egress control.
• Flow of data between cloud services: Monitoring PHI flow between microservices.

API security is highly important because a wrongly authorized API endpoint might end up revealing huge amounts of data. It doesn’t care about the application being highly secure.

Ransomware Resilience

It is vital for healthcare organizations to show that they are capable of recovering rapidly from damage caused by malware and extortion. You also need to prove having to pay a ransom or losing their critical information.

The key technological controls are:

• Immutable backups: Making sure that no encryption or deletion can happen on the backups by malicious domain administrators.
• Disaster recovery staging environments: Keeping staging environments that are clean in order to test recovery.
• Proven recovery strategies: Checking the recovery times against the recovery time objective (RTO).
• Ransomware strain incident response drills: Executing real-life incident responses against known ransomware strains.
• Backup retention period definition: Making sure that the backup retention periods are defined by the operational policy.

The HITRUST framework requires organizations to maintain offline and immutable backups for a defined retention period.

Encryption and Key Management

Private healthcare data have to be effectively secured when it is stored within data storage infrastructure as well as during transmission over internal and external networks.

The ability of technical teams to prove the right implementation of encryption technology would involve the following conditions:

• Where is the encryption implemented within databases, file servers, and backup storages
• What systems work with sensitive data, processing, storing, or transmitting it
• How are encryption keys generated, stored, and secured in hardware security modules 
• What is the key rotation policy, and how is it controlled
• Is there any use of up-to-date and secure data transfer protocols, such as TLS 1.3, etc.

That is why encryption has to be treated not as a configuration item, but as an operational technical measure.

How Can an Organization Prepare for HITRUST v11?

An organization can prepare for HITRUST v11 through evaluation of existing controls, determining gaps, selecting an assessment, and collecting evidence.

I. Perform a Gap Analysis

Determine what is currently in place compared to the specific v11 requirement statement.

If an organization is considering i1, then it involves analysing the 182 requirement statements and determining:

• Technical security controls missing in production.
• Inadequate or out-of-date audit documentation
• Weaknesses in configuration management in cloud environment or operating system environment
• Operational procedures that are now out of date about technology
• Centralized logging, SIEM coverage, or alerting not included
• Secondary systems or networks that were once outside the scope of the assessment

II. Choose the Right Assignment

Use e1, i1, or r2 based on specific business need, customer requirement, technical difficulty, risk tolerance, and the level of assurance required from the enterprise customers.

Choosing the right assessment level will save money and effort in implementing controls that are not really needed.

III. Create The MyCSF Assessment

MyCSF is the central system for configuring and managing the assessments.

It is recommended to check the appropriate version of the current CSF before setting up a new assessment. As per the current HITRUST process, a new e1 and i1 assessment needs to be set up using the latest version of CSF. For example, after May 2026 v11.8.0, new assessments need to be set up using v11.8.0.

IV. Reuse Existing Control Work

The nesting structure of the framework is deliberately engineered to shield prior assessment efforts. If an organization transitions from e1 to i1, then all 43 e1 requirements carry over to i1. 

Transitioning from i1 to r2 includes 182 out of 182 i1 requirements carried over into the r2 effort.

Common Pitfalls When Transitioning to HITRUST v11

The common pitfalls to avoid during HITRUST v11 migration are incomplete scoping, poor evidence gathering, delayed preparations, and underestimating third-party dependencies. Considering these risks will help the organisation avoid assessment delays and remediation problems.

1. Scope Creep and Untracked Assets

Not accounting for staging environments, developer sandboxes, legacy microservices, or third-party vendor APIs in your initial scoping document will create friction in the validation process.

2. Assuming That Having Documentation Is Proof

Just having a security policy document is not going to be enough for I1-type assessments. It requires evidence in terms of screenshots of configuration, logs, and system reports.

3. Delaying Your Migration

Waiting until legacy versions reach their deadlines will result in scheduling problems with the assessors.

4. Collecting Evidence at the Last Minute

Scrambling to gather 90 days of logs or scan reports the week before an audit leads to missed findings. Automated, continuous evidence collection is essential.

5. Ignoring Third-Party and Vendor Dependencies

Failing to verify the HITRUST status or security posture of your upstream cloud providers, SaaS tools, and managed service providers can leave major gaps in your shared responsibility model.

How Qualysec Accelerates Your HITRUST v11 Compliance Journey

Qualysec can help you to be audit-ready, putting your infrastructure under continuous pentesting before assessors get their hands on it. We perform human led ai powered penetration testing, which helps organizations achieve HITRUST v11.

• Scoping & Asset Identification: We review your cloud architecture, data paths, and microservices (AWS, Azure, GCP) to identify the scope. This prevents you from unnecessarily dragging non-production sandboxes or out-of-scope services into your assessment boundary.
• Technical Remediation Guidance: Our security engineers give you practical advice not just about the problems but also about how to remediate them, quickly closing configuration, IAM, and encryption loopholes.
• Strict Technical Penetration Testing: Rather than relying on automated checklist scans, it is important to perform deep manual penetration testing. The scope of testing should be web applications, cloud environments, and internal/external APIs to surface exploitable vulnerabilities. 
• Audit-Ready Evidence Mapping: Structuring and mapping your technical evidence against HITRUST v11 standards is also mandatory after testing. We can help your organization to collect and secure every technical detail before MyCSF submission

Conclusion

HITRUST v11 allows healthcare organizations to overcome static compliance and adopt controls for addressing present-day threats. The e1, i1, and r2 assessments provide healthcare organizations the freedom to select the assurance level according to their particular risks and requirements. 

Successful transition requires starting by conducting a gap analysis, selecting the appropriate assessment scope, and utilizing the already completed control activities. Adequate implementation of MFA, cloud and API security, ransomware protection, encryption, and continuous evidence gathering is also very important.

Speak Directly With Qualysec’s Certified Security Experts

Discover vulnerabilities before attackers exploit them

Schedule Free Consultation
→

FAQs

1. What are the primary differences between HITRUST v10 and v11?

HITRUST v11 provides a threat-adaptive and nested approach (e1, i1, and r2), whereby the lower-level controls are directly integrated into higher-level assessments. Other changes include a reduction in control overlap, revision of the mapping of authoritative sources, and changing assessment standards to technical implementation rather than policy.

2. Is penetration testing required for all HITRUST v11 assessments?

Penetration testing is necessary for all r2 HITRUST assessments and most i1 assessments that have external application components or APIs. Entry-level e1 assessments tend to rely primarily on cybersecurity hygiene practices, but penetration testing is mandatory at higher levels.

3. Can we still submit a HITRUST v10 assessment?

No, all new submissions under old schemes are completely outdated. All new assessment objects submitted in MyCSF have to conform to HITRUST v11, because earlier versions are not acceptable for new certifications anymore.

4. How often do you need to recertify under HITRUST v11?

Recertification schedules are determined by your assessment level: e1 and i1 are good for 1 year, and they both must be completed through a full annual assessment. HITRUST r2 certification is valid for two years, but an interim assessment is required after one year to maintain the certification. 

5. How does HITRUST v11 handle cloud security and API integrations? 

HITRUST v11 focuses on cloud and API risks through continuous monitoring of cloud misconfiguration, least-privilege IAM, and encryption of all data-in-transit. It focuses on healthcare microservices and third-party APIs.