HITRUST e1 to i1 or r2 upgrade: what carries forward

How do you move from HITRUST e1 to i1 or r2 without starting over?

When a customer or contract asks for a higher HITRUST level, the good news is that the portfolio is traversable: every e1 requirement sits in the i1, and every i1 requirement sits in the r2, so earlier work carries forward. The step up adds requirement statements rather than replacing them. In CSF v11.9.0 the e1 has 44 requirement statements and the i1 has 182. The r2 starts from those 182 i1 statements and adds more through tailoring based on organizational, compliance and system risk factors. The number you will be tested against therefore depends on which level you choose and how the r2 is tailored, so ask your assessor for the exact tailored requirement count before you plan the work.

The level itself should be chosen by the sensitivity of the data and the risk of the systems in scope, not by the certificate you already hold. HITRUST positions the e1 for startups and lower-risk organizations, the i1 for maturing programs that need moderate assurance, and the r2 for organizations handling highly sensitive data or high-risk systems. A customer's request is a reason to look at the level, but the decision should rest on your own risk assessment. Confirm with the requesting party which level they actually need, since some ask for an i1 when an r2 is what the contract truly means, and vice versa.

Clarify roles early. Your organization owns its controls and decides the scope. DeployOpen, if engaged, would prepare systems, configurations and evidence for the higher level under a written, fixed scope. Only an authorized HITRUST External Assessor can perform the validated assessment that supports certification, and HITRUST performs its own quality assurance before any report is issued. Neither DeployOpen nor your internal team can issue the certification. Before you sign an engagement, ask your assessor how much earlier e1 or i1 evidence they expect to inherit, and what gaps remain that the higher level will test.

What the step up costs and who is paid for each part

This table separates the cost of moving from an e1 or i1 to a higher assessment by who is paid for each part and whether it is one-time or recurring. Use it to build a request for quote that compares like with like, since the largest variables are the requirements added at the higher level and the systems in scope.

Cost component	Who is paid	One-time or recurring	What drives it up and what to request in a quote
Authorized External Assessor fees for the validated assessment	Authorized HITRUST External Assessor firm	One-time per validated assessment, repeated at each certification cycle	Added requirement statements, number of systems and locations in scope. Request fees for the target level, separately for scope assumptions.
HITRUST certification and quality assurance	HITRUST, after assessor submission	Per certification submission, renewed each cycle	Level chosen and the reports produced. Ask the assessor which HITRUST fees are passed through and which are billed by the firm.
Readiness and evidence preparation	Implementation partner or internal team	One-time for the step up, with upkeep afterward	Gap between your current i1 or e1 controls and the added requirements, plus evidence gaps in newly tailored areas. Ask for work broken down by requirement group.
Internal staff time	Your organization (salaried staff, no separate invoice)	Mostly one-time for the step up, recurring in each assessment year	Number of control owners, reviews of evidence and interviews during fieldwork. Ask the partner to name the owners it expects you to supply.
Tooling and MyCSF subscriptions	Software vendors and HITRUST for MyCSF access	Recurring subscription, often annual	Number of users and whether you need assessment workspace features at the higher level. Confirm current subscription terms with each vendor before budgeting.
Inheritance and provider evidence work	Your organization and any cloud or service providers	One-time setup, then periodic review	Number of providers whose results you reuse and the quality of their current assessments. Ask which inherited results remain valid at the higher level.

What makes the move to r2 longer or more expensive

Moving from an e1 or i1 to an r2 keeps the work you have already done, but the r2 starts from the i1 requirement set and grows from there. The drivers below decide how far it grows and how much of your earlier evidence you can actually reuse.

Added requirements from tailoring

The r2 begins with the 182 i1 requirement statements and adds more through tailoring based on organizational, compliance and system risk factors. Ask the assessor and your own risk team to agree the tailoring factors before you build evidence, because each added requirement is one more control you must show operating. Confirm the final count in writing once tailoring is settled, not after fieldwork starts.

Systems and locations in scope

Every additional application, environment, data store and facility that touches the assessed scope adds sampling and testing effort. Moving from a narrow e1 scope to an r2 covering several platforms usually multiplies the evidence an assessor must review. Inventory systems and sites early, and remove retired components from scope so they do not add testing.

Third-party and provider inheritance

Inheritance reuses maturity scores from another active HITRUST e1, i1 or r2 validated assessment, whether your own or a provider's. A cloud or SaaS provider with a current validated assessment can carry a large share of requirements, but only if its scope matches your use of the service. Check the provider's scope statement and carve-outs before you plan around it, since gaps there fall back on your team.

Evidence maturity from the lower level

Work done for an e1 or i1 carries forward through the traversable portfolio, but the evidence behind it may have been thin. Requirements you passed with light proof will need stronger records, such as consistent logs, dated approvals and repeatable test results, once the r2 samples them more deeply. Review earlier evidence against r2 expectations during readiness rather than during fieldwork.

Inheriting your own earlier results

Your own e1 or i1 maturity scores can be inherited into a later assessment across CSF versions, which can shorten testing on unchanged requirements. The reuse only holds while the earlier assessment is active and its scope still matches your environment. Map each prior requirement to current systems and document any change that breaks the match.

CSF version change in flight

A new CSF version can change requirement wording, baselines and mappings while your r2 is in progress. Confirm which version your assessment will use and how the deadlines apply, since e1 and i1 creation and submission deadlines differ from r2 version flexibility. Track version notices from HITRUST during preparation so the requirement set you build against does not shift late.

How the upgrade runs from gap analysis to certificate

The sequence turns work already done at e1 or i1 into a validated higher-level assessment, with each phase closing on a named output that the next phase depends on. Because the portfolio is traversable, the early mapping step decides how much new work the organization actually faces.

Confirm the target level and scope
Leadership, compliance and the system owners agree whether the organization needs an i1 or an r2, based on the data handled, the systems in scope and what customers or contracts require. The team then fixes the in-scope systems, facilities and business units in writing. The output is a signed scope statement naming the target assessment and the CSF version it will be assessed against. Ask your assessor and the HITRUST documentation which version is current when you start, because version rules affect later deadlines.
Map existing e1 or i1 evidence to the higher baseline
Compare each requirement statement in your current assessment against the higher baseline. Every e1 requirement sits in the i1, and every i1 requirement sits in the r2, so existing work carries forward. For an r2, the 182 i1 statements form the starting point, and tailoring based on organizational, compliance and system risk factors adds more. The output is a gap register that lists each requirement as carried forward, needing new evidence or newly added. Confirm with your assessor how tailoring will apply before you sign off the register.
Close gaps and run the incubation period
Control owners build or fix the controls on the gap register, then collect evidence that shows each control operating over time, not only on the day it was configured. Where a gap cannot be closed in time, the team documents the risk and the planned treatment. The output is an evidence package for every in-scope requirement, reviewed internally against the assessor's expectations. Incubation periods and sampling rules should be confirmed against the Assessment Handbook before the fieldwork window is booked.
Select an authorized External Assessor
Only an Authorized HITRUST External Assessor organization may perform a validated assessment submitted for certification. Ask candidates to confirm their authorization on HITRUST's assessor list, how they handle independence, and what preparation work they can and cannot do for you. Your internal team owns the controls, and an implementation partner can prepare systems and evidence, but the assessor tests and reports. The output is a signed engagement letter that fixes scope, the fieldwork dates and the deliverables.
Complete validated fieldwork in the window
The assessor tests the in-scope requirements against your evidence during the validated assessment fieldwork window, which must be at most 90 days for e1, i1 and r2. Your team answers requests, provides access to systems and walks the assessor through the evidence. Any findings are recorded for the scoring and corrective action process. The output is the assessor's completed assessment submission with scores for each of the 19 assessment domains, ready for HITRUST review.
Pass HITRUST quality assurance
After the assessor submits, HITRUST performs central quality assurance on the assessment before any report is issued. Reviewers may ask the assessor or your team for clarification or additional support on specific requirements. Responses should come from the people who own the evidence, with dated and traceable artifacts. The output is HITRUST's acceptance of the submission, which is the point at which the certification decision can be issued.
Receive the report and certificate
Once quality assurance is complete, HITRUST issues the validated assessment report and the certification at the new level. The certification period then follows the level's rules: one year for e1 and i1, and two years for r2, with an r2 interim assessment due in the 90 days before the first anniversary. The output is the certificate and report, which the organization can use with customers and regulators. Calendar the interim or renewal date on the day the certificate is issued.

Which level to step up to: e1, i1 or r2

The e1 suits startups and lower-risk organizations that need a credible, validated answer to a customer security questionnaire without a deep assurance program. It is the smallest validated assessment, with 44 requirement statements in CSF v11.9.0, and it is certified for one year. Staying at e1 is a sound decision when your data and systems do not warrant more assurance, and the work you do now should not be discarded.

What carries forward: Every e1 requirement sits inside the i1, so controls you have already implemented and evidenced remain valid if you later step up.
What is added: Nothing new is required to stay at e1, but annual recertification is still a full validated assessment each year.
When it fits: Early-stage companies, organizations with limited sensitive data, and vendors whose customers accept a one-year e1 result.
What to watch: A customer contract or regulator that names i1 or r2 will override the e1 choice.

Check whether any contract, customer questionnaire or regulator in your market names a specific HITRUST level before you commit to staying at e1.

What must be in place before the step-up assessment

A move from e1 to i1, or from i1 to r2, builds on work you have already done, but the added requirements and the new scope must be proven before an assessor starts fieldwork. The six checks below show what to verify, who owns each one, and how to confirm it.

Current gap view against the target baseline

Compare your current results with every requirement statement in the target level, not only the ones you already certified. The e1 has 44 requirement statements in v11.9.0 and the i1 has 182, so the gap view for an i1 step-up will show many statements that were never in scope before. Ask your readiness provider or internal assessor to produce this view in writing and to flag which gaps are policy gaps and which are technical gaps.

Evidence for the added requirements

Every requirement added by the higher level needs evidence that shows the control operated over the period the assessor will sample, not only that a policy exists. Confirm that each new requirement has a named artifact, an owner and a record of operation. Requirements that appear only in a plan or a draft procedure are the most common reason a step-up stalls.

Documented scope and system inventory

Your scope statement must match the systems, facilities and business units you will put forward for the higher assessment, and the inventory must show every in-scope asset with its owner, location and data classification. For an r2, check whether the added system or risk factors from tailoring change the boundary. An inventory that lags behind the scope will generate follow-up questions during fieldwork.

Inheritance decisions for provider results

Decide which requirements you will inherit from cloud providers, vendors or your own active e1 or i1 results, and which you will test directly. Inheritance reuses maturity scores from another active validated assessment, so confirm that each source assessment is active and covers the CSF version you are using. Record the decision in a shared responsibility matrix, because an assessor will check that inherited requirements match what the provider actually certified.

Named internal owner

Name one person who owns the assessment, decides scope questions and answers the assessor's requests within an agreed turnaround. This person should hold authority over the control owners across IT, security, HR and operations, since most step-up delays come from requests that wait on several teams. Confirm the owner's time is protected for the fieldwork window, which the handbook caps at 90 days.

CSF version confirmed in MyCSF

Open MyCSF and confirm which CSF version your assessment object uses before you finish the gap view, since requirement text and counts differ between versions. Current guidance identifies v11.9.0 as the current version, and the e1 and i1 baselines changed in that release. Check the creation and submission deadlines for your chosen version with HITRUST or your assessor so your gap view is built on the right baseline.

Who owns the controls, who prepares evidence and who certifies

Your organization owns every control in scope, the choice of assessment level, the scope boundary and the final decision on what evidence is submitted. No outside party can accept a risk on your behalf or decide that a requirement does not apply. Your team also carries the institutional knowledge that an assessor will test, such as how access reviews really happen and who approves exceptions.

Level and scope decisions: Deciding whether the r2 is needed, and how far tailoring extends beyond the 182 i1 statements, is a business and risk decision that you make and document.
Control ownership: Each control needs a named owner who can explain it, operate it and produce evidence without help.
Evidence approval: Someone accountable for the environment must confirm that screenshots, logs and tickets reflect how systems run today.
Inheritance and shared responsibility: Your team decides which results from cloud providers or earlier assessments you rely on, and checks that they still apply.
Corrective action ownership: Gaps found during preparation need funded remediation and owners, which only your leadership can assign.

Before engaging anyone, confirm the named control owners and who signs off scope and evidence internally.

Why step-up projects stall and how to avoid it

Moving from an e1 or i1 to a higher HITRUST assessment rarely fails on effort alone. Most stalls trace back to a handful of planning mistakes made before fieldwork starts. The cards below cover each mistake and the check that prevents it.

Assuming e1 evidence satisfies i1

The traversable portfolio means every e1 requirement sits inside the i1, so earlier work carries forward. It does not mean earlier evidence automatically satisfies the i1 wording, scope or sampling. Map each of the 182 i1 requirement statements against the evidence you hold, and flag any statement where the e1 evidence covers only part of the requirement.

Underestimating r2 tailoring

The r2 starts from the i1 statements and adds requirements through tailoring based on organizational, compliance and system risk factors. Teams that plan only for the i1 baseline are often surprised by the extra statements that come from risk factors. Ask your assessor early which factors apply to your organization and systems, and size the added work from that list rather than from the i1 count.

Starting fieldwork before incubation

Controls need time to operate before an assessor can test them with credible evidence. Starting fieldwork on controls that were only recently put in place invites exceptions and rework. Set a readiness checkpoint where each control has run long enough to produce the records the assessor will sample, and confirm that window with your External Assessor before booking the validated assessment.

Mixing CSF versions without checking inheritance

Inheritance can reuse maturity scores across CSF versions, but only from an active e1, i1 or r2 validated assessment, and readiness or incomplete assessments can only be inherited into readiness work. Before you reuse results from an earlier assessment in a higher-level submission, confirm the source assessment is active and that its scores qualify for the target level. Record the version used for each inherited score.

Unclear scope for providers

If your platform runs on a cloud provider or a managed vendor, the boundary between your controls and theirs decides which requirements you can inherit and which you must evidence yourself. Unclear boundaries produce duplicate testing or gaps nobody owns. Write down the system boundary, the shared responsibility split and the source of evidence for each shared requirement before the assessor sees the scope.

Choosing a level before reading the contract

Teams sometimes pick i1 or r2 because a peer did, or because a sales deck mentions it, before anyone reads what the customer contract requires. The contract text names the assessment level, the scope and the deadline. Read the clause with your legal and account teams, confirm the exact assessment and version it asks for, and only then scope the step-up project.

Questions buyers ask before stepping up from e1 or i1

Does an e1 certificate count toward an i1 assessment?

Yes, the work carries forward. The portfolio is traversable: every e1 requirement is in the i1 baseline, so controls you have already implemented and evidenced at the e1 level are the starting point for an i1. You still need to assess the requirements that the i1 adds, and you need to confirm that the evidence for the shared requirements still meets the i1 expectations. The e1 has 44 requirement statements in CSF v11.9.0 and the i1 has 182, so the gap is the difference between those two sets, not a restart. Ask your assessor to map your existing evidence against the i1 statements before you commit to a timeline.

How many requirements does an r2 add beyond the 182 i1 statements?

The exact number depends on your tailoring, so no fixed count applies to every organization. The r2 starts from the 182 i1 requirement statements in CSF v11.9.0 and adds requirements through tailoring based on organizational, compliance and system risk factors. Your organization size, the regulations you must meet, the sensitivity of the data and the criticality of the systems in scope all push the count up or down. Ask your assessor to walk through the tailoring factors for your environment and to show the resulting requirement list before you finalize scope.

How much effort does stepping up from e1 or i1 take our team?

Effort depends mainly on how much of the new requirement set your current controls already cover and how well those controls are evidenced. Teams that already run formal policies, access reviews, change management and logging usually need less work than teams that must build those processes for the first time. The main internal tasks are gap analysis against the added requirements, documenting procedures, collecting evidence for a sampled period and tracking corrective actions. Ask any consultant to estimate effort from a written gap assessment of your current environment, not from a generic duration.

Can we step up to i1 or r2 without outside help?

Your organization can prepare internally, but only an Authorized HITRUST External Assessor organization can perform the validated assessment submitted for certification. HITRUST also performs central quality assurance before issuing the report. An implementation partner such as DeployOpen can prepare systems, controls and evidence, but it does not issue reports or certificates. Many teams use outside help for the gap analysis, control build-out and evidence organization, then hire an external assessor for fieldwork. Confirm the division of responsibilities in writing before work starts.

How long does validated fieldwork take at most?

The assessor's validated assessment fieldwork window is at most 90 days for e1, i1 and r2, according to the HITRUST Assessment Handbook v1.1. That limit covers only the assessor's fieldwork, not the preparation that comes before it. Preparation time depends on how far your controls are from the requirement set, how many systems are in scope and how much evidence must be gathered and sampled. Ask your assessor to confirm the fieldwork plan and your readiness milestones so the fieldwork window is not spent on missing evidence.

What happens to our old e1 or i1 certificate when we step up?

The existing certificate remains valid until its own expiry date, and the new assessment produces a separate certification at the higher level. A certificate for an e1 or i1 lasts one year and an r2 lasts two years, with an r2 interim assessment due in the 90 days before the first anniversary. Plan the timing so you do not leave a gap in certified status while the new assessment is pending. Confirm with your assessor how the new report will reference the earlier results and whether any results can be inherited.

Can results from our earlier assessment be reused in the step-up?

Often, yes, within limits. Inheritance reuses maturity scores from another active HITRUST e1, i1 or r2 validated assessment, whether it is your own (internal) or a provider's (external), and it works across CSF versions. Readiness or incomplete assessments can only be inherited into readiness assessments, so they cannot support a validated step up. Confirm with your assessor which earlier results qualify, how the carried scores apply to the higher level and what evidence the assessor still needs to see for the added requirements.

How DeployOpen prepares your systems and evidence for the step up

DeployOpen starts the step up with a written scope that names the current assessment, the target level and the systems inside the boundary. Because every e1 requirement sits in the i1 and every i1 requirement sits in the r2 baseline, the first task is to map the controls you already operate to the requirement statements of the target level, then mark which ones have evidence that would survive a sample test and which ones were never operated. For an i1 moving to r2, the gap list also has to account for the tailoring factors your organization and systems bring, since those decide which additional requirements apply. The output is a gap register that your team can review before any hardening work begins.

Once the gaps are agreed, DeployOpen implements and hardens the systems that the new requirements touch, such as logging, access reviews, change records and backup restore tests, inside your own cloud accounts or data centers. Each change is documented with the owner, the requirement it supports and the date it became operational, because an External Assessor samples evidence over the fieldwork window and will look for controls that ran over time, not controls configured the week before testing. Where a control depends on a provider, the responsibility split is written down so that any inherited results are clearly labeled. Confirm with your assessor which inheritance rules apply to your upgrade before relying on earlier results.

DeployOpen does not issue HITRUST reports or certificates. Only an Authorized HITRUST External Assessor can perform the validated assessment, and HITRUST performs its own quality review before any report is issued. DeployOpen's role is to prepare the systems, controls and evidence so the assessor's fieldwork is efficient. Engagements are fixed-scope: the scope, deliverables and timelines are agreed in writing before work starts, and a written quote follows from that agreed scope. Ask for the quote to separate implementation, evidence packaging and any support you want during assessor fieldwork, and ask your assessor to confirm the scope they will test before you commit.

Moving from HITRUST e1 to i1 or r2