Which HITRUST level do you need: e1, i1 or r2?
Most buyers reach this question because a customer questionnaire or contract clause names HITRUST without saying which level. 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 risk-based tailoring. e1 and i1 certifications last one year, while an r2 lasts two years with an interim assessment due in the 90 days before the first anniversary. Those three facts set the cost and effort range before any scoping starts.
The level the customer names in writing should decide the choice. Ask the customer's security or procurement team to confirm the exact certification type, the version they will accept, and whether they require the certification to be issued in their name or accept a shared report. Do not assume that an e1 satisfies a request for HITRUST because the customer may read the request as needing an i1 or r2. If the contract names no level, ask for the level in writing before you commit budget, because a level chosen by guess often has to be repeated later.
Scope, data sensitivity and carve-out tolerance can change the answer even when the customer names a level. An e1 and an i1 allow service provider requirements to be carved out, while an r2 allows no carve-outs, so a customer that relies on your cloud provider's controls may only accept a level that is not carved out. Data that is highly sensitive or flows through high-risk systems points toward the r2, which HITRUST positions for that profile. Because work on a lower level carries forward, starting with the e1 or i1 can be a planned step if the customer's requirement is still open. Confirm the path with the customer and your assessor before the scope is fixed.
How the three certifications differ side by side
This table compares the e1, i1 and r2 on requirement count, validity, scoring, carve-outs, version rules, privacy tailoring, NIST CSF eligibility and intended buyer. Read each row against the level your customer or contract names, then check the row for the next level up before committing. Because every e1 requirement sits in the i1 and every i1 requirement sits in the r2, work on a lower level carries forward.
| Attribute | e1 | i1 | r2 |
|---|---|---|---|
| Requirement statements (CSF v11.9.0) | 44 | 182 | Starts from the 182 i1 statements and adds more through risk-based tailoring |
| Validity | One year | One year | Two years, with an interim assessment due in the 90 days before the first anniversary |
| Maturity level scored | Implemented | Implemented | Policy, procedure and implementation |
| Domain average needed to certify | Core statements average at least 83 per domain | Core statements average at least 83 per domain | Each domain averages at least 62 |
| Service provider carve-outs | Allowed | Allowed | Not allowed |
| Must use newest CSF version at creation | Yes | Yes | No |
| Privacy tailoring | Not offered as a tailoring option | Not offered as a tailoring option | Can be tailored to include privacy |
| Eligible for HITRUST NIST CSF certification | No | No | Yes |
| Intended buyer profile | Startups and lower-risk organizations | Maturing programs needing moderate assurance | Organizations handling highly sensitive data or high-risk systems |
| Year 2 path | Lighter rapid assessment may apply | Lighter rapid assessment may apply | Interim assessment, with a 90-day bridge assessment if recertification runs late |
What each level actually tests and scores
The e1 and i1 score the Implemented maturity level, meaning the assessor checks whether each requirement is in place and operating, not how thoroughly it is documented. To certify, each of the 19 assessment domains must average at least 83 across its core statements. The r2 works differently. It scores policy, procedure and implementation maturity together, and each domain must average at least 62. A team that moves from an i1 to an r2 cannot assume its i1 score carries over unchanged, because the r2 asks whether the control is designed and written down as well as whether it runs. Before committing to a level, confirm with your assessor which maturity levels they will score and how each domain average is calculated for your scope.
The 19 scoring domains are the same family at every level, from Information Protection Program through Data Protection & Privacy. What changes is depth and tailoring. The e1 and i1 use a fixed set of requirement statements, so two organizations at the same level answer the same questions. The r2 starts from the i1 statements and adds more through risk-based tailoring, so the same domain can carry a different number of statements, and different weight, depending on the organization's risk factors and scope. In practice, a domain that looks lightly tested at the i1 can be much heavier at the r2. Ask your assessor to show you the statements that apply to each domain in your scope, and treat any domain where the r2 adds statements as one that needs earlier readiness work.
Because the e1 and i1 statements are contained within the r2, evidence built for a lower level is not wasted. Policies, configuration baselines, access reviews and logging records prepared for an e1 can be extended rather than rebuilt, but the r2 will expect those artifacts to show design and written procedure, not just operation. Use the HITRUST assessment handbook to check how maturity is scored at each level before you decide which domains need documentation upgrades. A useful first step is a domain-by-domain gap review against the level your customer requires, recording which domains would need policy work, which need evidence of operation, and which are already covered.
Which level fits which buyer situation
Each HITRUST level answers a different level of assurance a customer or regulator expects. The cards below map the common buyer situations to the level HITRUST positions for them, and they show why the choice matters for the work that follows. Confirm the required level in the contract wording before you start, because a customer may name a level, a version or a specific report type.
Startup or lower-risk vendor
HITRUST positions the e1 for startups and lower-risk organizations. It is the entry point when a customer asks for a HITRUST result but does not need deep assurance over sensitive data or high-risk systems. Check whether the customer accepts a one-year e1 validity period and whether it wants carve-outs for cloud providers, since e1 and i1 allow service provider requirements to be carved out. Work on an e1 carries forward into the i1 and r2.
Maturing program needing moderate assurance
HITRUST positions the i1 for maturing programs that need moderate assurance. It is the usual choice when a customer's third-party risk review asks for more depth than the e1 provides but does not require the r2. Each i1 domain must average at least the scoring threshold on its core statements, so confirm the customer accepts an i1 scored at the Implemented maturity level. Expect the i1 to be valid for one year, with a rapid assessment option in year two.
Highly sensitive data or high-risk systems
HITRUST positions the r2 for organizations handling highly sensitive data or operating high-risk systems. The r2 scores policy, procedure and implementation maturity, allows no carve-outs, and can be tailored to include privacy. Its certification lasts two years with an interim assessment due in the 90 days before the first anniversary. Ask the customer whether it expects a full r2 or accepts an i1, because the r2 costs more effort than any lower level.
Customer requires a HITRUST NIST CSF certification
Only the r2 can produce a HITRUST NIST CSF certification, so a contract that names this outcome leaves no lower-level option. Confirm the exact wording, including whether the customer wants the NIST CSF 2.0 add-on or a certification that stands on its own. Plan the r2 timeline early, since the r2 needs a validated assessment by an authorized External Assessor and HITRUST quality assurance before a certificate is issued.
Contract names a level you have not reached
Some contracts require a level above the one a vendor currently holds. The portfolio is traversable, so every e1 requirement sits in the i1 and every i1 requirement sits in the r2, and earlier work carries forward. Ask whether the customer accepts a planned move up, or whether it needs the higher certification in place before signing. Map the gap between levels before committing to a date in the contract.
How long each level takes and what sets the pace
The sequence below shows where calendar time goes for each HITRUST level, so you can plan the path from e1 to i1 to r2 against the date a customer or contract needs.
Confirm the level and the deadline
Start by confirming which HITRUST level your customer or contract names, and the date it must be in hand. Ask the requesting party whether an e1, i1 or r2 is required, and whether a validated report or a bridge letter will satisfy them. This step is done when the level and deadline are written down and agreed with the customer, because every later estimate depends on them.
Measure readiness against the requirement count
Your team, or an outside readiness partner, compares current controls with the 44 e1 requirement statements or the 182 i1 statements in CSF v11.9.0. HITRUST cites an average of about 30 days for e1 certification and 6 to 12 months for most i1 certifications, depending on readiness, so the size of the gap is the main driver of time. The step closes with a gap list by domain and an honest view of which level the current program can support.
Remediate gaps and let controls run
Close the gaps you found and let the new or changed controls operate long enough to produce evidence. The system and control incubation rules in HITRUST's assessment handbook set minimum periods that the controls must run before assessors can test them, so this is often the longest part of the calendar. Confirm the current incubation requirements for your level with HITRUST and your External Assessor before you commit to a date.
Schedule the assessor and a QA reservation
Engage an Authorized HITRUST External Assessor and book the work through MyCSF. HITRUST performs central quality assurance before it issues a report, and the reservation for that review adds scheduling time that sits outside the assessor's fieldwork. Ask the assessor and HITRUST for current service levels for quality assurance and report review, since these can change and should not be assumed from older guidance.
Complete fieldwork within the 90-day window
The External Assessor tests the controls and collects evidence during a validated assessment fieldwork window of at most 90 days for e1, i1 and r2 alike. Your team answers evidence requests, supplies samples and explains any alternate controls or N/A decisions. The step is done when the assessor finishes testing and submits the assessment for HITRUST review.
Pass HITRUST quality assurance and review the draft
HITRUST reviews the submitted assessment centrally before issuing anything. You then review the draft report with the assessor, check that the scores and descriptions are accurate, and raise any factual errors. Certification follows only after this review is complete, so the draft stage can add weeks to the calendar if findings need rework.
Plan the path to the next level and renewal
Once certified, note the validity period: e1 and i1 certifications last one year, and r2 certifications last two years with an interim assessment due in the 90 days before the first anniversary. Because every e1 requirement is in the i1 and every i1 requirement is in the r2, earlier work carries forward into the next level. Calendar the renewal or upgrade date now, and confirm the r2 timing with your External Assessor, since tailoring and the interim cycle set the pace of that path.
What happens in year two for e1, i1 and r2 holders
An e1 certification is valid for one year, so the holder must recertify before it lapses. Because the e1 is the smallest of the three requirement sets, the recertification path is the simplest. HITRUST describes a lighter rapid assessment for holders who qualify in year two, which reduces the work compared with repeating the full validated assessment. Whether an organization qualifies depends on the conditions HITRUST sets for the rapid option, so the holder should confirm eligibility before planning.
- Annual cycle: The e1 certification runs for one year, and the recertification date sets the planning window.
- Rapid assessment option: Eligible holders may recertify through the lighter rapid assessment instead of a full e1 validated assessment.
- Carried-forward work: Because every e1 requirement sits in the i1 and r2 baselines, evidence built for the e1 supports later moves up the portfolio.
- Changed environment: Significant changes to systems or scope may take the holder out of the rapid path, so review scope changes before filing.
- External assessor role: Only an Authorized HITRUST External Assessor performs the validated work, and HITRUST performs quality assurance before issuing the report.
Before year two starts, confirm with the External Assessor whether your environment still qualifies for the rapid assessment and which evidence the assessor will sample.
An i1 certification is also valid for one year. Year two follows the same logic as the e1: the holder may qualify for a lighter rapid assessment rather than a full repeat of the i1 validated assessment. The i1 carries more requirement statements than the e1, so the rapid path matters more for cost and effort, but eligibility still depends on the holder's controls, changes and scope during the year.
- Annual cycle: The i1 certification runs for one year, and the renewal date should drive the evidence calendar.
- Rapid assessment option: Eligible holders may recertify through the lighter rapid assessment rather than repeating the full i1 validated assessment.
- Maturity expectations: The i1 scores the Implemented maturity level, so controls must remain operating, not only documented, through the year.
- Version rules: Confirm whether a newer CSF version affects the recertification, since the i1 must use the newest version at creation.
- Upgrade path: An i1 holder moving to the r2 keeps its i1 work, since every i1 requirement sits in the r2 baseline.
Ask the External Assessor to confirm the rapid assessment criteria in writing and to list the evidence that must be ready before the renewal window opens.
An r2 certification is valid for two years, but the second year is not idle. HITRUST requires an interim assessment due in the 90 days before the first anniversary of the certification. The interim assessment checks the environment against the r2 baseline and tailoring before the certification reaches its full term. If recertification runs late, a 90-day bridge assessment can extend coverage while the full work finishes.
- Interim assessment: Due in the 90 days before the first anniversary, so schedule the External Assessor early enough to finish inside that window.
- Bridge assessment: A 90-day bridge assessment is available if recertification runs past the expiry date, which is a contingency and not a plan.
- Full recertification: The r2 renews at the end of the two-year term through the full validated process.
- Tailoring changes: Significant changes to scope, systems or tailoring can require review before the interim assessment.
- Evidence continuity: Keep the evidence trail from the original r2 fieldwork so the interim work reuses it rather than rebuilding it.
Confirm the interim and bridge dates with your External Assessor against your certification date, and agree who prepares the evidence and by when.
Regardless of level, an organization can add AI security certification and Insights Reports to its HITRUST work. These sit alongside the core certification rather than replacing it, so they create their own year-two obligations. Plan them with the same calendar as the base certification, because an add-on that is not renewed alongside the core assessment can leave a gap in what a customer sees.
- AI security certification: Available at e1, i1 and r2, and it adds scope for AI systems that the organization must maintain.
- Insights Reports: Available at all three levels, and they summarize results for relying parties in a different format from the certification letter.
- Shared evidence: AI and reporting work often draws on the same logs, access records and change tickets as the core domains, so one evidence system can serve both.
- Separate scoping: Add-ons may need their own scope definitions, so confirm boundaries with the External Assessor before work starts.
- Cost drivers: Each add-on adds assessor effort, so request a quote that separates the core and add-on components.
Ask for a written list of which add-ons your customer requires, and confirm with HITRUST's current assessment pages how each is renewed.
How work on a lower level carries into the next
Work done for a lower HITRUST level carries forward because the portfolio is nested: every e1 requirement sits inside the i1, and every i1 requirement sits inside the r2 baseline. An organization that has built and evidenced controls for an e1 has already covered part of the i1, and the i1 work already covers part of the r2. The r2 then adds requirements through risk-based tailoring rather than replacing what came before. In practice, the move up is mostly a question of which additional statements apply, how much evidence must be produced for controls you have not yet tested at the higher level, and whether earlier results can be reused without rework.
Two rules decide how much of a move up you can reuse. First, carve-outs: e1 and i1 assessments allow service provider requirements to be carved out, but the r2 allows no carve-outs, so a cloud or SaaS provider you excluded at the lower level may have to be brought into scope at the r2. Second, CSF version: e1 and i1 assessments must use the newest CSF version at creation, while the r2 does not. If your e1 or i1 was created on an older version, check whether the r2 you plan to start would be created on a newer one, since that changes which statements you are testing against. Map your current carve-outs and version against the r2 scope before you commit to a date.
Confirm every carry-forward detail with your External Assessor before fieldwork, including which evidence from the e1 or i1 they will accept for the r2, how any carved-out providers will be assessed, and whether the newest CSF version changes any statements you already evidenced. Ask for this in writing as part of scoping, because the answers determine how much of the prior work you can reuse and how much new evidence you must produce.
What makes moving between levels more or less expensive
The gap between an e1, an i1 and an r2 is mostly a matter of how much evidence you must produce and how many systems it covers. The cards below cover the levers a buyer can shape before committing, and each one shows where effort grows as the level rises.
Scope and number of systems
Every system, environment and business process inside the assessment scope must produce evidence for each requirement that applies to it. A narrow boundary around one production application costs far less to evidence than a boundary covering several products, data stores and admin networks. Before moving up, list the systems that actually store or process the customer's data and check whether a smaller boundary still meets the contract.
Cloud and vendor inheritance
Controls that a cloud provider or vendor operates can be inherited instead of re-evidenced, and e1 and i1 assessments allow service provider requirements to be carved out. The r2 allows no carve-outs, so the same provider reliance that lowers effort at one level may not carry over to the next. Ask which requirements sit with each provider, whether that provider's own HITRUST or SOC 2 report covers them, and how the shared responsibility matrix will be documented.
Evidence maturity
Assessors test whether controls are in place and operating, which means policies, procedures and records must already exist and show consistent use over time. Organizations that rely on informal practice or ad hoc tickets often spend the most effort on rebuilding evidence. Check whether logs, access reviews and change records are retained in a consistent format today, since that determines how much work the next level adds.
Data sensitivity and the r2 trigger
Organizations that handle highly sensitive data or run high-risk systems are the ones HITRUST positions for the r2, because its scoring covers policy, procedure and implementation maturity and can be tailored to add privacy. A lower-sensitivity product may reach its customer's requirement with an i1, which costs less to prepare. Confirm with the customer whether the contract names a specific level or only asks for moderate assurance before choosing the path.
Internal headcount for evidence collection
Someone inside the organization must gather screenshots, exports, tickets and sign-offs for every requirement in scope, and keep them current during fieldwork. A small team with no dedicated owner tends to pay external help to fill the gap, while a team that already runs control reviews can absorb a higher level more cheaply. Estimate the staff hours your team can commit each week before asking for a quote, and ask the provider which evidence tasks it will perform versus which your staff must perform.
Who owns the controls, who prepares evidence and who certifies
The organization that holds the certification owns its controls, its scope and every risk decision that goes with them. No outside party can accept a risk on the organization's behalf or decide which systems sit inside the assessment boundary. Before any validated assessment starts, the organization decides which e1, i1 or r2 level its customer or contract requires, and it answers for whether each requirement statement is implemented, tailored or marked not applicable.
- Scope decisions: The organization defines which business units, products, environments and data flows fall inside the assessment, and which service providers are carved out or inherited.
- Control ownership: Named internal owners run each control day to day, from access reviews to change management, and they keep the operating records that show it works.
- Risk acceptance: Where a requirement cannot be met as written, leadership signs the acceptance or alternate control decision, and the assessor evaluates that decision rather than making it.
- Staff and budget: The organization funds the assessor, the platform subscription, the readiness work and the internal time needed to answer evidence requests.
- Ongoing operation: Controls must keep working between assessments, because the evidence assessors sample comes from the period under review.
Before committing, confirm with your team which owner signs each control statement and who approves each scope and tailoring decision in writing.
An implementation partner such as DeployOpen works on the organization's side of the table. It helps plan, build and document the systems, configurations and control evidence that a validated assessment will examine, so the organization arrives at fieldwork with systems that are ready and records that are complete. The partner does not score the organization, does not decide what is in scope, and does not issue any HITRUST report or certificate.
- Readiness preparation: The partner can gap-check the organization's current controls against the requirement statements for the chosen level and prioritize remediation.
- Systems and configuration: Work may include hardening, logging, access control, backup and patching on self-hosted platforms inside the organization's own cloud accounts, data centers or air-gapped networks.
- Evidence preparation: The partner can set up the records assessors sample, such as access review exports, change tickets, vulnerability scan reports and training logs, and document where each one lives.
- Documentation: Policies, procedures and system descriptions are written or updated so they match how the systems actually run.
- Limits of the role: The partner cannot perform the validated assessment, cannot be the External Assessor, and cannot promise a result.
Before engaging a partner, ask for a written scope that names the deliverables and confirm that the partner's staff will not also act as the assessor for the same work.
Only an Authorized HITRUST External Assessor organization may perform the validated assessment that supports a certification. The assessor tests the controls, samples evidence within a fieldwork window of at most 90 days, scores the results and submits them. HITRUST then performs central quality assurance before it issues the report and certification. Neither the assessor nor a partner can override HITRUST's quality review.
- Validated fieldwork: The External Assessor tests each requirement statement in scope against the evidence the organization provides and records its findings.
- Scoring: Results are scored against the maturity model for the level, with e1 and i1 measured at the Implemented level and r2 measured on policy, procedure and implementation.
- Independence: HITRUST imposes staffing and independence rules, so the assessor firm should not have designed the controls it tests.
- HITRUST quality assurance: HITRUST reviews the submission centrally before issuing anything, and it is HITRUST that issues the certification.
- Ongoing cycle: e1 and i1 certifications last one year, and r2 certifications last two years with an interim assessment due in the 90 days before the first anniversary.
Before signing, check the firm against HITRUST's Find an External Assessor directory and confirm in writing who will perform the fieldwork and who will sign the submission.
Questions buyers ask before choosing a HITRUST level
Is an e1 or i1 enough if a customer asks for an r2?
No. A lower level does not satisfy a contract that names the r2, because the r2 is a separate validated assessment with its own tailoring and scoring. Ask the customer to state in writing which certification, CSF version and scope they accept before you choose a level. Some customers accept an i1 for moderate assurance, but that is their decision to confirm, not an assumption to make. The practical planning question is the path between levels: every e1 requirement sits in the i1 baseline and every i1 requirement sits in the r2 baseline, so work on a lower level carries forward. An i1 can therefore serve as a stepping stone to an r2 without starting the control work again.
Does e1 work count toward an i1 certification?
Yes, in the baseline sense: every e1 requirement is part of the i1, so the e1 work carries forward. The i1 adds requirements on top of the e1, with 44 e1 and 182 i1 requirement statements in CSF v11.9.0, so the carried-forward work covers only part of the i1. Both levels score the Implemented maturity level, but the i1 requires each domain's core statements to average at least 83. Keep e1 evidence in a form the assessor can reuse, such as dated configuration exports, access review records and change tickets tied to specific requirement statements. Ask your External Assessor which e1 results they will accept as they stand and which they will retest, since that depends on how the assessment is scoped in MyCSF.
Does an r2 take more effort than an i1?
Yes, in most cases, because the r2 starts from the 182 i1 requirement statements and adds more through risk-based tailoring. It also changes several rules that drive work. The r2 allows no carve-outs, so cloud providers, vendors and other service providers must be covered by your own evidence or by inheritance you can document. It does not need the newest CSF version, but it can be tailored to include privacy. Scoring uses policy, procedure and implementation maturity, and each domain's average must reach at least 62. Effort rises with the number of systems in scope, the number of tailored requirements and how much evidence the assessor samples during fieldwork, which is capped at 90 days. Ask for the tailoring list and the carve-out treatment in writing before you estimate effort.
Can we do HITRUST readiness work in-house?
Yes. The organization owns its controls, so gap analysis, policy writing, control implementation and evidence collection can be done by your own team. The restriction applies to the validated assessment itself: only Authorized HITRUST External Assessor organizations may perform the assessments submitted for certification, and HITRUST performs central quality assurance before it issues reports. Confirm what your readiness work covers, which MyCSF licensing your team needs and whether you will require an internal assessor for ongoing testing. Your staff know how systems actually run, and the assessor will ask them to explain it, so keep them involved from the start. An outside partner can take on technical work such as hardening, logging, backup and documentation, but your organization remains the control owner.
How far ahead should we plan for year two of HITRUST?
Plan from the certification date, since validity is counted from it. e1 and i1 certifications are valid for one year, and r2 certifications for two years, with an r2 interim assessment due in the 90 days before the first anniversary. e1 and i1 holders may qualify for a lighter rapid assessment in year two, so confirm the eligibility conditions for your level in the HITRUST Assessment Handbook before you plan the work. r2 holders complete the interim assessment as the checkpoint, and a 90-day bridge assessment is available if recertification runs late. Book the assessor and the QA reservation early enough that fieldwork, capped at 90 days, finishes before the deadline. Keep evidence collection running through the year, because significant changes to systems or controls can raise questions at renewal.
What does an outside implementation partner change in a HITRUST project?
It changes who carries the preparation work, while the certifying roles stay the same. An implementation partner can prepare systems, harden platforms, document controls, build evidence packages and support readiness under a written, fixed scope. It cannot issue the report or the certificate. Your External Assessor must also be independent of the work it tests, so confirm the independence rules with HITRUST before assigning roles. Ask any partner to state in writing which items it delivers, which remain with your team and how evidence will reach the assessor. Cost follows that scope, so the quote should list the deliverables, the environments in scope and any post-assessment support. DeployOpen, for example, plans and implements self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, and prepares evidence for assessments without issuing reports.
What DeployOpen prepares before a level is assessed
Before any HITRUST level is assessed, the most useful preparation is a written scope that says which systems, data flows and self-hosted open-source platforms sit inside the assessed environment, and which belong to a cloud provider, vendor or other party whose results are carved out or inherited. DeployOpen plans and documents that scope with the client inside the client's own cloud accounts, data centers or air-gapped networks. The scope decides which requirement statements apply to which components, so it must be settled before evidence is gathered. For the e1, i1 and r2 the scope is the same starting point, but the carve-out rules differ: the e1 and i1 allow service provider requirements to be carved out, while the r2 allows no carve-outs. The client should confirm that rule with its assessor before scoping, because it changes how much work lands on the platforms DeployOpen hardens.
Once the scope is fixed, DeployOpen hardens and documents the self-hosted platforms so that the configuration behind each control can be shown to an assessor. That typically covers access settings, logging, backup and restore records, patch and change history, and the runbooks that show who does what. Each control is mapped to an owner inside the organization, because the organization owns its controls and must be able to explain and operate them. DeployOpen prepares controls and evidence ahead of the External Assessor's fieldwork, which is limited to a validated assessment window of at most 90 days for e1, i1 and r2. Preparation is not an audit: DeployOpen does not issue reports, attestations or certifications, and it does not score the organization's maturity. Only an Authorized HITRUST External Assessor performs the validated assessment, and HITRUST performs central quality assurance before issuing a report.
Ask any readiness provider for a written statement of what it will deliver before work starts, including the scope document, the control-to-evidence list, the platform configuration records and the list of gaps that remain for the organization to close. Confirm with the assessor which evidence it will sample and how long systems must have operated before testing, since those rules set the effort. DeployOpen works under fixed-scope agreements where scope and deliverables are agreed in writing before work begins, and ongoing support or retesting is available separately. The practical decision for the buyer is whether the readiness work should cover the e1 baseline first, with the i1 and r2 additions planned afterward, because every e1 requirement is in the i1 and every i1 requirement is in the r2.
How DeployOpen scopes and prepares HITRUST evidence
DeployOpen plans and prepares the systems, controls and evidence behind a HITRUST e1, i1 or r2 assessment, inside your own infrastructure. We do not issue reports or certifications; an Authorized HITRUST External Assessor performs the validated assessment and HITRUST issues the result.
How we scope
- We agree the written scope for the chosen level, covering which systems, environments and locations are in the assessment boundary.
- We map which requirement statements apply to your self-hosted platforms and which sit with cloud providers or other vendors.
- We confirm with your assessor and your customers which level, version and carve-out decisions the written scope will rely on.
How we build
- We implement and harden the self-hosted open-source platforms that carry the controls your chosen level requires.
- We configure logging, access control, change management and backup so that evidence is produced as a normal output of operations.
- We test the controls in your environment and record gaps so you can close them before the external assessor's fieldwork starts.
How we hand over
- We document each control, its owner, its configuration and the evidence location so your assessor can trace it without guesswork.
- We deliver the evidence package in the structure your external assessor and internal teams agree during scoping.
- We train your staff to operate, maintain and produce evidence for the platforms after the engagement closes.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, which helps keep evidence current between assessment cycles.
- Support can cover planning for the next assessment year, including the interim or rapid assessment steps that apply to your level.
- Confirm with your assessor and HITRUST which timelines, fieldwork windows and version requirements apply to your engagement before you commit.
