What Is HITRUST CSF?
HITRUST CSF harmonizes cybersecurity/control requirements and maps authoritative sources into one control framework and assurance methodology. Certification scope and assessment type determine what assurance a resulting report actually supports.
A HITRUST certification should not be represented as compliance with every regulation mapped into the CSF without considering scope and authoritative-source selection.
Current Version in 2026
HITRUST announced CSF v11.9.0 on September 24, 2026. It refreshes authoritative-source mappings and e1/i1 baselines. HITRUST also publishes transition/decommission deadlines for older libraries.
Confirm exact MyCSF library version and creation/submission deadlines before project planning; 'HITRUST v11' is not precise enough in late 2026.
e1 vs i1 vs r2
| Assessment | Model | Current public description | Validity |
|---|---|---|---|
| e1 | Foundational | 44 v11.9 baseline requirement statements | 1 year |
| i1 | Leading practices | 182 controls | 1 year |
| r2 | Risk-based tailored | Customized requirements based on risk/scope/source factors | 2 years |
Choose the assessment that satisfies relying-party and risk needs rather than defaulting to the most comprehensive option.
Scoping and Tailoring
Scope determines which systems, facilities, processes, cloud services and third parties are assessed. r2 uses risk-based scoping/tailoring; e1/i1 use predefined baselines with options to incorporate additional authoritative sources.
Cloud inheritance can reduce duplicate effort, but provider certification does not automatically cover customer identity configuration, application code or operating procedures.
Assessment Evidence
- Policies/standards establishing control requirements.
- Procedures and operational mechanisms.
- Technical configuration/system-generated evidence.
- Sample records showing operation over time.
- Ownership/review evidence.
- Remediation evidence.
- Third-party/inheritance evidence.
Validated assessment evidence should be repeatable and tied to control ownership; screenshots produced only for audit are weaker than continuous system evidence.
Certification Workflow
- Select assessment type/scope.
- Confirm CSF version/deadlines.
- Perform readiness assessment.
- Remediate gaps.
- Complete assessment in MyCSF.
- Engage authorized external assessor.
- Resolve testing/evidence issues.
- HITRUST quality assurance/review.
- Maintain evidence for certification period.
Common Readiness Gaps
- Critical SaaS/cloud dependencies outside scope.
- Policies without implementation evidence.
- Weak access-review remediation.
- Unmeasured vulnerability SLAs.
- Unmapped shared responsibility.
- Logging controls without coverage evidence.
- Exceptions without owner/expiry.
- Testing begins before evidence collection is operational.
APIs and HITRUST
APIs processing regulated/sensitive data belong in inventories, access control, secure development, monitoring, vulnerability management and incident response evidence. Gateways and identity providers are often key dependencies.
Related Ammune reading: FHIR API security best practices and API sensitive data exposure.
Maintaining Certification
e1/i1 certifications are one year; r2 is two years. Maintain evidence continuously, monitor HITRUST version/advisory updates and reassess scope when systems/providers change.
Choosing Between e1, i1 and r2
Assessment selection should begin with the assurance question a customer, regulator or board is trying to answer. e1 provides a foundational certified baseline; i1 evaluates a broader set of leading security practices; r2 tailors requirements to organizational risk, scope and authoritative sources and provides the most comprehensive certification path.
A smaller organization is not automatically an e1 candidate, and a large enterprise does not automatically need r2 for every scope. Consider the sensitivity of the service, contractual requirements, customer expectations, regulatory sources that need to be included and whether relying parties explicitly require a particular HITRUST certification.
| Question | Implication |
|---|---|
| Need foundational certified assurance quickly? | Evaluate e1 |
| Need broader standardized security assurance? | Evaluate i1 |
| Need tailored risk/regulatory assurance over a complex scope? | Evaluate r2 |
| Customer contract names a HITRUST assessment type? | Use that requirement as a primary constraint |
| Planning future progression? | Use HITRUST traversability to avoid recreating evidence |
Whichever assessment is chosen, stabilize scope before evidence collection. Late additions of cloud environments, products or shared services can change testing requirements and invalidate earlier readiness assumptions.
HITRUST e1: 43 Controls vs 44 v11.9 Requirement Statements
Late-2026 HITRUST materials use two numbers that can look contradictory. The September 24, 2026 v11.9.0 release advisory states that the e1 baseline size is 44 requirement statements. HITRUST’s public e1 certification page still describes the offering as 43 foundational controls.
Do not “resolve” that difference by silently choosing one number in an audit plan. Controls and requirement statements are not necessarily identical counting units, and product pages can lag assessment-library changes. Record the exact MyCSF version used by the assessment and use that library’s requirement statements as the project baseline.
HITRUST Assessment Selection Questions
| Question | Why it matters |
|---|---|
| What certification does the customer/contract explicitly require? | Can determine e1, i1 or r2 before internal preference |
| How complex is the assessed environment and regulatory scope? | Influences whether a tailored risk-based r2 assessment is justified |
| Is foundational certified assurance sufficient? | May point toward e1 |
| Is broader standardized security assurance expected? | May point toward i1 |
| Will the organization progress to a deeper assessment later? | Encourages reusable evidence and stable scope |
Freeze the scope and exact MyCSF library before building a control matrix. In late 2026, the distinction between product-level descriptions and version-specific requirement-statement counts makes version control especially important.
HITRUST Checklist
- Confirm CSF v11.9.0/current version.
- Choose e1/i1/r2 appropriately.
- Define scope/shared responsibility.
- Perform readiness before validation.
- Assign owners and recurring evidence.
- Centralize policy/procedure/technical artifacts.
- Close critical gaps.
- Use authorized external assessor for validated certification.
- Monitor advisory/version deadlines.
- Maintain evidence continuously.
Frequently Asked Questions
What is the current HITRUST CSF version?
HITRUST released v11.9.0 on September 24, 2026.
What is e1 vs i1 vs r2?
e1 is foundational one-year assurance, i1 broader one-year leading-practices assurance, and r2 tailored risk-based two-year assurance.
How many controls are in e1?
HITRUST’s current assessments page describes e1 as 44 v11.9 baseline requirement statements.
How many are in i1?
The current assessments page describes i1 as 182 controls.
Do validated certifications use an external assessor?
Yes, validated assessments involve a HITRUST Authorized External Assessor and HITRUST review.
Primary References
Make Runtime API Evidence Part of HITRUST Readiness
Connect API inventory, monitoring and threat evidence to the larger set of policies, controls and recurring evidence your HITRUST assessment requires.