HITRUST CSF Guide: e1, i1 and r2 Certification

Healthcare buyers increasingly ask suppliers for a HITRUST certification, and teams that pick the wrong assessment tier, scope it badly or underestimate the scoring rules lose months and money. HITRUST is an assurance programme built on the HITRUST CSF, a control framework that harmonises dozens of regulations and standards into one set of requirements, with testing by authorised external assessors and quality assurance by HITRUST itself. This guide explains the e1, i1 and r2 assessments, how MyCSF, PRISMA-based maturity scoring, corrective action plans, inheritance, interim and bridge assessments work, where the AI security assessment fits, and how HITRUST compares with SOC 2 and HIPAA. It is written for security, compliance and GRC leads at health technology firms, payers, providers and their suppliers who need to plan or run a HITRUST programme.

Key takeaways

Three tiers, three questions. e1 (43 controls) answers "do you have the basics", i1 (182 controls) answers "do you follow leading practice against current threats", and r2 (tailored, highest assurance) answers "is your programme mature for your specific risks".
Scoring is stricter than it looks. e1 and i1 need core requirement statements in each domain to score at least 83; r2 needs each domain to score at least 62 across up to five maturity levels.
Corrective action plans are part of the deal. Certified organisations still carry CAPs, and an r2 interim assessment checks that at least half of required CAPs have started or finished.
Inheritance is the biggest effort saver. Controls already validated by a cloud provider or an internal shared service can be inherited in MyCSF, and HITRUST says participating cloud providers can cover up to 70% to 85% of requirements.
HITRUST is not HIPAA compliance by itself. There is no official HIPAA certification; HITRUST maps to HIPAA and can produce a HIPAA insights report, but the legal obligations remain yours.

What the HITRUST CSF is

The HITRUST CSF (the name comes from the HITRUST Common Security Framework) is a certifiable control framework. HITRUST describes it as a "comprehensive, threat-adaptive control library" that "harmonizes over 70 regulations, standards, frameworks, and other authoritative sources". At the time of writing the current release is CSF v11.9, and HITRUST publishes a comparison document for each version change, so check which version your assessment will be built on when you create it.

Three ideas set HITRUST apart from a plain control catalogue:

Requirement statements: each control is expressed as testable requirement statements with evaluative elements, scored individually and averaged by domain.
Threat adaptation: HITRUST says it analyses threat intelligence and breach data to update control requirements, which is why the i1 control set changes between versions.
Centralised assurance: an external assessor tests the controls, but HITRUST performs quality assurance on every validated assessment and issues the report and certificate itself. That is different from SOC 2, where the CPA firm issues its own opinion.

HITRUST is widely used across US healthcare, but it is not healthcare-only. The same framework and assessments are used by technology, financial and other suppliers who want one assessment to answer many customer questionnaires. For the regulation that usually drives demand, see the HIPAA Security Rule Guide.

HITRUST assessment tiers: e1, i1 and r2

Attribute	e1	i1	r2
Purpose (HITRUST description)	Foundational, "entry-level validated assessment"	"Threat-adaptive assurance" for leading practice	"Tailored assurance with the highest level of control requirements"
Control requirements	43 core controls	182 control requirements, fixed set	Tailored to risk factors such as data sensitivity, system complexity and regulatory obligations
Maturity levels scored	Implemented only	Implemented only	Policy, Procedure, Implemented, plus optional Measured and Managed
Certification threshold	Core statements in each domain score at least 83	Core statements in each domain score at least 83	Each domain scores at least 62
Validity	1 year	1 year, with rapid recertification in year two on approximately 60 core controls	2 years, with an interim assessment at year one
Typical fit	Start-ups and lower-risk suppliers, first step to i1 or r2	Maturing programmes, suppliers needing moderate assurance, stepping stone to r2	Organisations handling highly sensitive data or critical systems, large payers and providers

The HITRUST assessment tier you choose should follow your customers' contracts, not ambition. If a large health system's third-party risk team demands a HITRUST r2 certification, a HITRUST i1 will not satisfy it, and a HITRUST e1 even less so. A HITRUST r2 assessment is also the only tier with interim and bridge assessments, so the HITRUST r2 commitment runs for two years. If nobody has asked for r2, an e1 or i1 delivers validated assurance in far less time: HITRUST says an e1 can take "as few as 4-6 weeks".

Readiness versus validated assessments

The HITRUST Assessment Handbook distinguishes two kinds of assessment. A HITRUST readiness assessment is a self-assessment that helps an organisation "identify and remediate gaps prior to performance of a validated assessment"; HITRUST does not quality-check it and it cannot lead to certification. A HITRUST validated assessment includes testing by an authorised HITRUST external assessor, goes through HITRUST QA, and is the only route to an e1, i1 or r2 certification. If thresholds are not met, HITRUST issues a validated report without certification.

Maturity scoring: the PRISMA levels

HITRUST maturity levels, often called the HITRUST PRISMA levels, are, in the handbook's words, "based upon HITRUST's version of the PRISMA maturity model". Each requirement statement is scored at each applicable level, and each level is rated Non-Compliant, Somewhat Compliant, Partially Compliant, Mostly Compliant or Fully Compliant (NC, SC, PC, MC, FC).

Level	What the assessor checks	Used in	Evidence that usually satisfies it
Policy	"the overall intention and direction as formally expressed by management", and whether policy requires each evaluative element	r2	Approved, current policy or standard naming the requirement
Procedure	"a description of the steps necessary to perform specific operations", derived from policy and applied to in-scope systems	r2	Runbooks, work instructions, configuration standards
Implemented	Whether the control is in place across all in-scope systems	e1, i1, r2	Configuration exports, samples, screenshots, system-generated reports
Measured	Separate monitoring that tests or measures the control's effectiveness	r2 (optional)	Metrics, automated compliance checks, internal audit testing
Managed	Corrective action or improvement driven by the measurement results	r2 (optional)	Tickets and remediation records tied to measurement findings

Two practical consequences follow. First, Policy and Procedure gaps alone can sink an r2 domain even when the technology works, so write and approve documents early. Second, Measured and Managed are optional in r2; include them only when you can show a real metric and remediation loop, because scoring them is chosen when the assessment is configured.

Corrective action plans, gaps and risk acceptance

A HITRUST corrective action plan (CAP) is a recorded, measurable commitment to fix a deficient requirement statement. The handbook sets when one is mandatory:

r2 (section 13.9.2): a CAP is required where the requirement statement scores below 71, its Implemented level is below fully compliant, and its control reference averages below 71, for control references required for certification.
i1 and e1 (section 13.9.1): a CAP is required where a core statement is below fully compliant and its control reference average is below 80.
Gaps: deficiencies that do not meet the CAP criteria are recorded as gaps rather than CAPs.
Risk acceptance: for requirements scoring 62 or higher, the organisation may accept the risk instead, but must "perform and document a risk analysis".

Each CAP in MyCSF needs a name, a specific corrective action, a status (Not Started, Started On Track, Started At Risk or Completed), an owner and a scheduled completion date. External assessors review CAPs for specificity before submission, and inherited CAPs that a service provider must fix are still tracked by the assessed organisation. Treat CAPs as programme work with owners and budgets, not as paperwork: the r2 interim assessment retests them.

Inheritance and shared responsibility

HITRUST inheritance and HITRUST shared responsibility work together. HITRUST describes its Shared Responsibility and Inheritance Program as allowing organisations "to reuse inheritable controls from internal and external third-party organizations". In practice:

External inheritance: a cloud provider or other service provider with its own HITRUST assessment publishes which requirements it fully or partly covers. You request inheritance in MyCSF and the provider approves it. HITRUST says organisations "can inherit as much as 70%-85% of requirements" from participating cloud service providers.
Internal inheritance: a central shared service, such as a corporate identity platform or security operations team, is assessed once and inherited by several business unit assessments.
Shared responsibility matrices: HITRUST publishes matrices for major cloud providers and a free baseline template, which help you split each requirement into provider, customer and shared portions before scoping.
Currency matters: inherited results must come from an active assessment in good standing. During a bridge assessment, for example, the handbook requires evidence that the inherited assessment is still active.

Inheritance never covers your own configuration choices. A cloud provider's physical security is inheritable; how you configured access policies, logging and key management in your tenant is not. See the Third-Party Risk Management Guide for how customers read the resulting reports.

MyCSF, external assessors and HITRUST quality assurance

HITRUST MyCSF: HITRUST calls it "the all-in-one platform for managing HITRUST assessments". It holds scoping and tailoring, requirement statements, evidence, scores, CAPs and inheritance requests, and its Report Center lets you invite recipients and revoke access to your reports.
HITRUST external assessor: assessor firms are approved by HITRUST through an application process and must employ at least five Certified CSF Practitioners (CCSFP) and two Certified HITRUST Quality Professionals (CHQP). The firm must be a separate legal entity from the assessed organisation, and staff who implemented or operated the assessed controls in the prior 12 months cannot test them.
Fieldwork window: the handbook sets a maximum 90-day fieldwork window for validated e1, i1 and r2 assessments, so evidence collection must be planned rather than open-ended.
HITRUST quality assurance: after submission HITRUST performs QA during a reserved QA block. Open check-in items must be resolved before the block starts or the reservation is cancelled. Draft reports can be reviewed for up to 30 days before they are approved automatically.

Interim, bridge and recertification

Event	Applies to	Timing	What is tested
HITRUST interim assessment	r2	Submitted in the 90-day window before the one-year anniversary of certification	One random requirement statement per domain, all statements that had required CAPs, a sample of add-on requirements; at least 50% of required CAPs started or complete
HITRUST bridge assessment	r2 only	Created from 60 days before to 30 days after expiry; certificate valid for 90 days from the previous expiry	19 requirement statements randomly selected by MyCSF; eligibility requires no reportable breaches or significant scope changes
i1 rapid recertification	i1	Year two	Approximately 60 core controls instead of the full 182
Full recertification	e1, i1, r2	Before the certificate expires	A new validated assessment

The interim is not a formality. If a sampled score drops, the assessor must judge whether the control environment has degraded and may expand testing; HITRUST can suspend or revoke the certification. Completed CAPs are generally expected to score fully compliant across Policy, Procedure and Implemented and to have passed a 90-day incubation period. A bridge certificate is limited assurance, not an extension: the 90 days are deducted from the next r2's 24-month validity.

HITRUST AI security assessment

HITRUST launched the "HITRUST AI Security Assessment with Certification" on 19 November 2024. It targets "AI platforms and deployed systems" and can be taken standalone or added to an e1, i1 or r2 assessment, with a one or two year certification period depending on the assessment chosen. HITRUST says its controls are aligned with the AI security elements of ISO, NIST and OWASP publications. The handbook refers to the add-on as ai2 within r2, and bridge and interim assessments include add-on requirements. Separately, HITRUST offers an AI Risk Management assessment with 51 controls aligned with ISO 23894 and the NIST AI RMF, which addresses governance rather than technical security. For the broader governance picture see the AI Governance Guide.

HITRUST vs SOC 2 vs HIPAA

Question	HITRUST	SOC 2	HIPAA
What is it?	Certifiable control framework and assurance programme	Attestation report under AICPA standards against the Trust Services Criteria	US law; the Security Rule sets safeguards for electronic PHI
Who tests?	Authorised external assessor, then HITRUST QA	Licensed CPA firm, which issues its own opinion	No certifying body; HHS OCR enforces
Output	HITRUST report and certificate (e1, i1, r2)	Type 1 (design at a point in time) or Type 2 (operating effectiveness over a period)	Your own risk analysis and documentation
Control set	Prescriptive requirement statements with scoring thresholds	Criteria with organisation-defined controls	Standards and implementation specifications, some addressable
Validity	1 year (e1, i1) or 2 years (r2)	Report covers a period; customers usually expect annual reports	Ongoing obligation

HITRUST vs HIPAA is not either-or: HITRUST maps to HIPAA and offers insights reports that translate results into HIPAA, PHIPA, HICP, NIST SP 800-171 and GovRAMP terms, but no assessment transfers your legal duties. HITRUST vs SOC 2 is often both: healthcare customers ask for HITRUST while technology customers ask for SOC 2, and many suppliers test controls once and report twice. HITRUST also offers a NIST CSF 2.0 add-on report to r2. See the SOC 2 Guide and the Control Mapping Guide.

How to implement: from scoping to certification

Confirm the requirement. Read customer contracts and questionnaires to establish which tier is required and by when. Do not assume r2.
Define scope. List the systems, facilities and teams that handle in-scope data. Narrow scope shortens fieldwork but must match what customers rely on.
Map inheritance early. Identify cloud and service providers with HITRUST assessments, download shared responsibility matrices and plan inheritance requests.
Run a readiness assessment in MyCSF. Score yourself honestly against the same rubric, then remediate gaps. For r2, write and approve missing policies and procedures first.
Engage an authorised external assessor. Confirm independence, agree the 90-day fieldwork window and book the QA slot.
Run validated fieldwork. Provide system-generated evidence and full populations for sampling. Expect retesting where evidence is weak.
Enter CAPs and submit. Write specific, owned CAPs with dates, sign the representation letter, and submit for HITRUST QA.
Close QA and review drafts. Respond quickly to QA questions and review draft reports within the 30-day window.
Operate the certificate. Track CAP progress monthly, put the r2 interim window and recertification date in the risk calendar, and plan a bridge only as a fallback.

If remediation stalls, roll back the plan rather than the scope: move to a lower tier such as i1 for the first cycle and target r2 for the next, instead of shrinking scope until the certificate no longer covers what customers use.

Decision guidance by organisation size

Start-up or small supplier: start with e1, inherit heavily from your cloud provider, and use the result as the base for i1 later. A SOC 2 may still be needed for non-healthcare customers.
Mid-sized health technology firm: i1 usually balances effort and assurance. Plan year-two rapid recertification and decide whether customers will push you to r2 within two years.
Large payer, provider or critical supplier: r2 with internal inheritance from shared services, an annual interim plan and a standing CAP programme. Consider Measured and Managed only where metrics already exist.
AI product vendors: add the AI security assessment to the tier you already hold rather than running a separate programme.

Where identity fits

Access control, authentication and logging requirements run through every tier, and they are where service accounts and API keys hide. Assessors sample user and privileged accounts, but non-human identities such as integration accounts, CI/CD credentials and cloud service principals sit in the same scope and are often missing from the inventory. Inventory them, assign owners and rotate secrets before fieldwork. See the Healthcare Identity Security Guide and the Service Account Security Guide.

Measuring the programme

Domain score headroom: lowest domain score against the 62 (r2) or 83 (e1, i1) threshold in readiness and validated results.
CAP progress: percentage of required CAPs started or completed, tracked against the 50% interim expectation.
Inheritance rate: share of requirement statements fully or partly inherited.
Evidence rework: number of evidence items returned by the assessor or HITRUST QA.
Calendar adherence: days between interim submission and the anniversary date, and whether a bridge was needed.

Common failure patterns

Choosing r2 by default: organisations take on the heaviest tier when customers would accept i1, and stall for a year.
Weak policy and procedure documents: controls work, but undated or unapproved documents drag r2 domain scores below 62.
Vague CAPs: "improve logging" is rejected; CAPs need a specific action, owner and date, and stalled CAPs threaten the interim.
Treating certification as HIPAA compliance: the certificate does not replace the risk analysis and safeguards the law requires. The Change Healthcare breach began with one Citrix login without MFA, a reminder that controls must hold across the whole estate, not just the scoped system.
Missing the interim window: the 90-day window passes unnoticed and certification is put at risk.
Stale inheritance: a provider's assessment expires or changes and inherited scores no longer hold.

Practitioner checklist

Confirm the required HITRUST tier and deadline from customer contracts before starting.
Document scope and the CSF version your assessment will use.
Download shared responsibility matrices and plan inheritance requests in MyCSF.
Complete a readiness assessment and approve missing policies and procedures before fieldwork.
Verify the external assessor's authorisation and independence, and book the HITRUST QA slot.
Write CAPs with specific actions, owners and dates, and review progress monthly.
Diarise the r2 interim window, recertification date and bridge eligibility conditions.
Inventory service accounts, API keys and other non-human identities in scope.
Map HITRUST results to HIPAA, SOC 2 and NIST CSF 2.0 so one control set serves every report.

HITRUST CSF Guide: e1, i1 and r2 Assessments and Certification