HITRUST i1 assessment: requirements and evidence

What the HITRUST i1 assessment asks for and how it differs from e1 and r2

If a customer or contract requires HITRUST and names the i1, the assessor will test whether a fixed set of 182 requirement statements is implemented, and a passing result supports a one-year certification. The i1 sits in the middle of the HITRUST portfolio. Every e1 requirement is also in the i1 baseline, and every i1 requirement is also in the r2 baseline. In CSF v11.9.0, the e1 baseline has 44 requirement statements, so the i1 adds leading-practice requirements on top of the entry-level set. Before you commit, confirm the current baseline counts and the version in effect for your assessment with your assessor or in MyCSF, because HITRUST updates baselines between versions.

The main design choice in an i1 is scope, not content. You can define which systems, facilities or departments fall inside the assessment boundary, but you cannot remove, reword or substitute requirement statements to fit your environment. That is the difference from the r2, where requirement statements are tailored to the organization's risk factors and the assessor scores policy, procedure and implementation maturity. For the i1, the question is narrower: is each required control in place and operating as described in the statement? Organizations with a patchwork of tools, or with controls that exist but are not evidenced consistently, often find this fixed set harder than they expected, because a control that is missing from one system in scope can still fail the requirement.

The i1 addresses the risk that a customer needs more assurance than a basic self-attestation but does not need the depth of an r2. Readiness work usually centers on mapping existing evidence to each statement, closing gaps in access reviews, logging, vulnerability management and third-party oversight, and confirming that the controls have run for long enough to be tested. HITRUST says most organizations complete i1 certification within 6 to 12 months, depending on readiness. Ask any consultant or assessor to show you a gap list against the 182 statements before you sign a scope, and ask which parts of the work you would own versus which the assessor will perform.

Which systems, teams and third parties fall inside an i1 scope

The organization sets the i1 boundary, but the 182 requirement statements stay fixed, so scope decisions change the systems, people and evidence an assessor samples rather than the control set itself. The cards below cover the choices that most often change effort, from the systems in the boundary to the reports an organization can reuse.

Defining the system or department boundary

The first decision is whether the i1 boundary covers a set of systems, a business line, a department or a whole company. Each choice determines which applications, identity stores, endpoints and staff fall under the 182 requirement statements. A narrow boundary is easier to evidence, but it must still match what customers and contracts describe as in scope. Confirm the boundary in writing with the assessor before readiness work begins, and document the data flows that cross it.

Cloud and hosting provider treatment

Decide whether the cloud platform, colocation facility or managed hosting provider sits inside the boundary or outside it. Infrastructure the organization configures, such as virtual machines, storage and identity policies, usually falls in scope. Provider-operated physical controls may be inherited instead. Ask the provider which of its own controls are covered by a report you can reference, and map each requirement to the party that operates it.

Shared services and internal platforms

Centralized services such as single sign-on, logging, backup, ticketing and endpoint management often touch many in-scope systems. Including them in the boundary means their configuration and access records become evidence for the assessment. Excluding them requires a clear justification and a control interface that assessors can test. List each shared service, its owner and whether its records will be sampled.

Third-party vendors with access to scope

Vendors that host data, run support tools, process transactions or hold administrative access to in-scope systems must be identified before scoping closes. Each one needs a documented relationship, a contract and an assessment position. A vendor's own HITRUST or SOC 2 report can support the work, but the organization still has to show how the vendor's controls connect to its own. Build a vendor list that matches the boundary.

Reusing inherited results from other reports

Earlier assessments, provider reports and the controls they cover can reduce the testing that falls on the current scope, but only where the scope, period and control wording match. A reused result must still be traceable to the in-scope systems. Confirm with the assessor which results can be inherited, which must be tested directly and how inheritance must be documented in the assessment record.

Teams, locations and fixed control set

People who administer, operate or support in-scope systems, along with the sites and business units where they work, define the population for many requirement statements. Adding a team or location after scoping can change which records need to be sampled. The control set itself does not change with scope, so the organization should expect the same 182 statements regardless of boundary. Record the teams, locations and roles included, and update the list when the organization changes.

How an HITRUST i1 assessor tests the 182 requirement statements

This table compares how an Authorized HITRUST External Assessor tests each part of the i1 assessment, from policy and implementation to sampling, scoring and quality review. Read it as a guide to what evidence to prepare and where the assessor will look hardest before the fieldwork window opens.

Testing element	What the assessor does	What to prepare
Policy and documentation	Reads the written policies and procedures behind each requirement statement and checks that they exist, are approved and match the stated scope.	Current, approved policies that name the in-scope systems and the owners of each control.
Implementation testing	Inspects configurations, tickets, logs and system settings to confirm the control operates as written, not only that it is documented.	Screenshots, configuration exports and system records that show the control working in the live environment.
Sampling	Selects samples of people, changes, access events or assets from the assessment period and tests each sample against the requirement.	Complete populations (user lists, change records, incident tickets) so the assessor can draw samples without gaps.
Fieldwork window	Completes validated assessment fieldwork within the 90-day window set in the HITRUST Assessment Handbook.	A readiness review before fieldwork so that the assessment window is not spent fixing known gaps.
Core requirement average per domain	Scores each assessment domain. The core requirement statements in each domain must average at least 83 for certification.	Internal pre-assessment scoring against the same core requirements to find domains that sit close to the threshold.
Quality assurance and report issuance	HITRUST performs central quality assurance on the submitted assessment before a report is issued. The assessor, not the organization or DeployOpen, issues the result.	Ask the assessor for its quality review timeline and the list of open items HITRUST may raise.
Common findings	Frequently found gaps include policies that do not match practice, missing evidence for periodic reviews, and access reviews without documented outcomes.	A pre-assessment check of recurring review records, exception handling and evidence retention for each domain.
Organization's own role	Owns the controls, supplies evidence and answers assessor questions. Implementation partners can prepare systems and evidence but cannot test or certify them.	A named internal owner for each domain and a single point of contact for assessor requests.

How to prepare for an i1 assessment, step by step

This sequence takes an organization from a defined i1 scope and confirmed CSF version to an evidence-backed readiness record, so the Authorized External Assessor can test a stable, documented control set.

Confirm scope and CSF version
Leadership and the compliance lead decide which systems, facilities, or departments fall inside the i1 boundary, and confirm the CSF version the assessment will use in MyCSF. The i1 control set is fixed, but the scope is yours to define, so this decision drives every later step. The output is a signed scope statement that lists in-scope systems, data flows, locations, and third parties, along with the CSF version recorded in the assessment record. The step is done when the scope statement names an owner and the version is confirmed against the current HITRUST release notes.
Map existing controls to the i1 baseline
Control owners inventory the policies, procedures, technical configurations, and records that already address each of the 182 requirement statements in the i1 baseline. Because the i1 baseline includes the e1 requirements, teams can start with the foundational items they may already run. The output is a control inventory that links each requirement statement to a named owner, the system it covers, and the artifact that shows it operates. The step is complete when every statement has at least one candidate control or an explicit gap marker.
Build the gap register
The compliance lead compares the inventory with the requirement statements and records every statement that is missing, partly implemented, or unsupported by evidence. Each gap is assigned a severity, an owner, and a target date set by the organization, not by the assessor. The output is a gap register that doubles as the working list for remediation. The step is done when each open item has a documented owner and a remediation approach, and the register has been reviewed by the people who run the affected systems.
Remediate gaps and document decisions
Engineering, IT operations, HR, and business owners close the gaps in the register by changing configurations, adding procedures, or completing training and access reviews. Where a requirement cannot apply to the organization, the decision needs a written rationale rather than silence. The output is updated policies, configuration baselines, and a decision log for any not-applicable or alternate approaches. The step is done when every register item is either closed with evidence or documented with an agreed rationale and an owner.
Assemble the evidence index
The team gathers the artifacts that show each control operated during the period the assessor will examine, such as access review records, change tickets, vulnerability scan reports, training completion logs, and incident records. Each artifact is named, dated, linked to its requirement statement, and stored in a location the assessor can reach. The output is an evidence index that lets anyone trace a requirement to its proof. The step is complete when a second person can find the evidence for a sample of statements without help from the control owner.
Run an internal dry run
Internal staff or an independent reviewer who did not build the controls walks through the requirement statements as an assessor would, asking for evidence, sampling records, and checking that the stated process matches what people actually do. The output is a readiness record listing each statement, its status, the evidence reviewed, and any findings that need correction. The step is done when the readiness record shows no unresolved findings and the owners have accepted the results.
Engage an Authorized External Assessor
The organization selects an Authorized HITRUST External Assessor organization, confirms its authorization and independence, and agrees on a written scope, deliverables, and fieldwork schedule. The assessor, not the implementation partner, performs the validated assessment, and HITRUST performs quality assurance before issuing any report or certificate. The output is a signed engagement letter and a readiness record the assessor can review before fieldwork begins. The step is done when the assessor has accepted the evidence index and the scope statement as the basis for testing.

Which evidence passes an i1 assessment and how to keep it current

An i1 assessor tests whether each requirement statement is implemented and evidenced, not whether the paperwork exists. The evidence families below cover the records an assessor typically samples, and each one needs a routine that keeps it current between assessments, so the population is ready when fieldwork starts.

Written policies and approvals

Policies, standards and procedures must be approved, versioned and in force for the full period the assessor reviews. For i1, check that each policy names an owner, shows an approval date and a review cycle, and matches how systems actually behave. An assessor will compare the written procedure against a sampled system and flag gaps where the document describes controls nobody runs. Keep a single register of document versions and approvals so the current version is easy to prove.

Access and configuration records

Assessors commonly sample user access reviews, joiner, mover and leaver tickets, privileged account lists and baseline configuration settings. Export these from the identity provider and configuration management tools on a schedule rather than rebuilding them at audit time. Confirm that each sampled account has an approved request, and that periodic reviews record who signed off and which accounts were removed.

Change and vulnerability records

Change tickets, peer review or approval evidence, and vulnerability scan results with remediation dates show that changes and weaknesses are controlled over time. Assessors typically select a sample of changes and check that each was authorized, tested and traceable to the deployed version. Keep scan reports, exception approvals and patch records linked to the asset they describe, so a single sampled system can be traced from finding to fix.

Logging and incident records

Log sources, retention settings, alert samples and incident tickets show that security events are captured, reviewed and handled. For i1, confirm that logging covers the in-scope systems, that log integrity and access are protected, and that at least a sample of alerts has a documented triage outcome. Incident records should show detection, containment, root cause and lessons learned, and tabletop or drill records help show the process works before a real event.

Training and awareness records

Training completion records, role-based training materials and acknowledgment of policies show that personnel know their security responsibilities. Assessors often sample staff from different roles, including administrators and developers, and check whether their records match their access. Set a recurring process that pulls completion data from the learning platform and retires records for people who have left.

Third-party assurance and supplier records

Where a provider or cloud platform performs part of a control, the organization must hold current assurance, such as a SOC 2 report or HITRUST letter, and show how it reviewed it. Keep a register of suppliers in scope, their report periods, bridge letters and the complementary user entity controls the organization must operate. Confirm which controls are inherited and which remain the organization's own responsibility before the assessment begins. CISO Assistant (AGPL-3.0-only) ships more than 200 frameworks and can track evidence and automatic mappings between them. Confirm with its maintainers whether its mappings and assessment workflows fit HITRUST i1 work before relying on them.

What meeting the i1 requirement costs in money and effort

This table compares each cost component of an i1 certification by who is paid, whether the cost is one-time or recurring, what drives it, and what to request in a quote. Read it as a checklist for building a budget, since most of the effort sits in internal labor rather than license fees. The main takeaway is that open-source platforms can remove some license spend, but evidence upkeep and remediation labor still scale with scope.

Cost component	Who is paid and one-time or recurring	What drives it and what to request in a quote
MyCSF subscription	HITRUST, recurring while the assessment is active. Confirm current pricing directly with HITRUST.	Subscription tier and assessment count. Ask the vendor to itemize what the subscription covers for the i1 submission.
External assessor fees	Authorized HITRUST External Assessor organization, one-time per certification cycle, plus year-two rapid assessment if pursued.	Number of systems in scope, fieldwork window of at most 90 days, and sampling depth. Request a fixed fee tied to a written scope and sample list.
Internal engineering and compliance time	Your own staff, recurring through readiness and the assessment period.	Number of systems, control owners, and how much evidence already exists. Ask the implementation partner to estimate hours by domain before work starts.
Remediation of gaps	Your engineering teams or an implementation partner, one-time before assessment, recurring when controls drift.	Current maturity against the 182 i1 requirement statements. Request a gap list by assessment domain with owners and dates.
Evidence upkeep	Your staff, recurring for the full one-year certification period.	Evidence collection frequency, log retention, and access reviews. Ask how evidence is stored, dated and linked to each requirement statement.
External testing or readiness review	Independent testing firm or consultant, optional, one-time or periodic.	Scope of applications, networks and cloud accounts tested. Request a written statement of scope, deliverables and retesting terms.
Year-two rapid assessment	Authorized assessor, recurring in year two for eligible organizations.	Stable control environment and clean prior results. The lighter rapid sampling approach is available only if eligibility conditions in the handbook are met, so confirm eligibility first.
Open-source platform licenses	Software vendors, typically one-time setup and recurring support if purchased. Often zero license spend for self-hosted community editions.	Choice of platform, support contract and hosting. Self-hosting removes license spend, but deployment, hardening, backup and upgrade labor still applies and must be quoted separately.

Who owns the i1 controls, who prepares evidence and who issues the result

The organization owns its controls. Accountability for the i1 requirement statements, the policies behind them and the daily operation of the safeguards stays with staff who run the environment, and no outside party can take that over. The in-house team also decides the i1 scope, which can be defined by systems or departments, even though the control set itself is fixed.

Control ownership: Named owners for each requirement area who can explain how the control works and show it operating.
Policies and procedures: Written documents approved by management and kept current with how the environment actually runs.
Day-to-day operation: Access reviews, change approvals, patching, monitoring and backups performed on a schedule and recorded.
Scope decisions: Choosing which systems, departments and third parties fall inside the assessed boundary, and documenting why.
Management sign-off: Accepting residual risk and confirming the organization stands behind its own statements.

Before engaging anyone, confirm which of these owners already exist by name, because the assessor will ask each one to walk through their evidence.

Why i1 assessments stall and how to close each gap

Most i1 delays trace back to a small set of gaps that surface only when the assessor starts testing. Each card names one gap, the action that closes it and the evidence the assessor will ask to see, so teams can check readiness before fieldwork begins.

Unclear scope boundaries

The i1 scope is defined by the systems or departments you choose, but the control set itself is fixed. If the boundary is drawn loosely, assessors cannot tell which hosts, applications, identity sources and administrators fall inside it, and the same question returns in every sample. Write down the in-scope systems, data flows, people and third parties, and show the boundary diagram that matches the asset inventory. Ask your assessor to confirm the boundary before you start collecting evidence.

Policies that do not match practice

A policy that describes a control your teams do not run creates a finding even when the control exists elsewhere. Assessors compare written procedures with tickets, configurations and logs from the same period. Review each i1 requirement statement against the owning procedure, then correct either the document or the operating practice before the assessment window. Keep a dated change history so the assessor can see when the procedure was approved and when it took effect.

Evidence that cannot be sampled

Assessors test controls by sampling, which means they pick instances across the period and expect a record for each one. A control that is performed but not logged, such as access reviews kept in email threads or patch approvals made verbally, produces no sample to test. Define the population for each control, such as all joiners, all changes or all privileged accounts, and make sure every item in that population leaves a timestamped, attributable record that can be pulled on request.

Missing ownership for shared controls

Controls that depend on several teams, such as vulnerability management spanning platform, application and security groups, often have no single accountable owner. When the assessor asks who approves an exception, the answer changes depending on the person asked. Assign one named owner per control, document the supporting roles, and confirm each owner can produce the evidence without help from a colleague who has left the project.

Inherited results without a responsibility matrix

Relying on a cloud provider's or vendor's results for part of the control set is only defensible when the split of responsibility is written down. Without a shared responsibility matrix that states which requirement statements the provider covers, which remain yours and which carry a documented carve-out, assessors cannot accept the inherited result. Obtain the provider's current report, confirm its scope covers the services you use, and map each inherited requirement to the exact evidence you hold.

No dry run before fieldwork

Teams that go straight into the assessor's fieldwork window discover missing evidence while the clock is running. A dry run, in which an internal reviewer or readiness partner requests evidence for a sample of requirement statements, exposes gaps early enough to fix them. Run the sample against the full i1 baseline, record each failed request, and track the corrective action to closure. The fieldwork window is limited, so resolve these issues before the assessor arrives.

How much work, time and cost does an i1 certification take?

How long does an i1 certification take to complete?

HITRUST says most organizations complete i1 certification within 6 to 12 months, depending on how ready they are when they start. The span is mostly set by readiness: how many of the 182 requirement statements already have implemented controls and retained evidence, and how much work is needed to close the gaps. Organizations with mature, documented controls usually land near the short end. Organizations starting from informal practices should plan for the longer end and build in time for remediation before the validated assessment fieldwork begins. Ask your assessor and any readiness provider to show how they reached their schedule against your current control state.

What does an i1 certification cost, and what drives the price?

The cost has three main parts: the external assessor's fee for the validated assessment, the internal effort to prepare controls and evidence, and any tooling or readiness support you buy. HITRUST does not publish a single i1 price in the research supplied for this page, so the reader should ask for it directly. The biggest cost drivers are the scope (the number of systems, departments and locations in the i1 boundary), the number of controls that need remediation, and how much evidence must be gathered by hand. Scope is yours to define, but a narrower, well-documented boundary usually reduces both assessor time and internal effort. Ask each assessor for a written quote that separates fees for the assessment, any HITRUST submission charges, and any extra work for remediation retesting.

Can our own team complete an i1 assessment without an outside partner?

Your team can prepare the controls and evidence without a partner, but the validated assessment itself must be performed by an Authorized HITRUST External Assessor organization. Only those assessors can perform validated assessments submitted for certification, and HITRUST performs central quality assurance before issuing the report. Internal teams often handle policy writing, control ownership and evidence collection well, and many lack the time to do it alongside daily operations. Outside help is most often used for gap analysis, remediation planning, evidence organization and mock testing before the assessor arrives. Confirm with any consultant which tasks they perform and which remain your responsibility, and confirm that your assessor is on HITRUST's authorized list.

What does i1 require from engineering and compliance teams?

Engineering and compliance share the work, and the split should be agreed before preparation starts. Engineering teams typically own technical controls such as access management, logging, vulnerability management, backup and configuration baselines, and they must be able to produce screenshots, configuration exports, tickets and logs that show each control operating. Compliance teams typically own policies, risk documentation, training records, vendor reviews and the mapping between requirement statements and evidence. Expect ongoing time from both groups during the fieldwork window, which the assessor limits to at most 90 days for e1, i1 and r2. Name an owner for each requirement area so that sampling requests do not stall while people search for records.

Can we use i1 in year two without repeating a full assessment?

Yes, if you are eligible. An i1 certification is valid for one year, and in year two an eligible organization can perform a lighter i1 rapid assessment that uses a rapid sampling approach. The rapid assessment is smaller than the original validated assessment, but it still needs current evidence for the fixed set of requirement statements. Eligibility depends on HITRUST's rules, so confirm it with your assessor before planning year two. Keep evidence collection running throughout year one, because a rapid assessment depends on controls that are still operating and documented, not on a last-minute evidence sweep.

How do we choose an assessor for an i1 assessment?

Start by confirming that the firm is an Authorized HITRUST External Assessor organization, using HITRUST's Find an External Assessor directory. Then compare proposals on the same written scope, including the in-scope systems, the expected fieldwork window, what evidence you must provide, and how the firm handles findings that need remediation. Ask about independence: the assessor that performs the validated assessment should not design the controls it tests. Ask whether the same firm offers readiness work, and if so, how it keeps those roles separate. Request references from comparable i1 engagements that the firm is permitted to share, and check how quotes are structured before comparing totals.

Where can DeployOpen help with i1 preparation?

DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, and prepares systems and evidence for compliance assessments. For an i1 effort, that can include configuring logging, access controls and backup on the platforms in scope, and organizing the evidence each requirement area needs. DeployOpen does not perform or issue the HITRUST assessment, and it does not issue reports or certifications. Work is typically fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope.

How DeployOpen prepares systems and evidence for an i1 assessment

DeployOpen plans, implements and documents the self-hosted open-source platforms inside your own infrastructure that produce i1 evidence. Your organization owns its controls, and an Authorized HITRUST External Assessor performs the validated assessment and HITRUST issues the certification.

How we scope

Engagements are fixed-scope, with systems, deliverables and timelines agreed in writing before work starts.
We confirm which systems or departments fall inside the i1 scope, since the organization defines that boundary.
We map the 182 i1 requirement statements in CSF v11.9.0 to the platforms and owners that answer them.

How we build

We plan, implement and harden self-hosted open-source platforms in your cloud accounts, data centers or air-gapped networks.
We configure logging, access control, backup and change records so the evidence they generate is retained and attributable.
We run security testing against in-scope systems and document findings and remediation for the assessor to review.

How we hand over

We document each control's implementation, owner, configuration and evidence source for your assessor and internal teams.
We deliver runbooks for backup, upgrades and access reviews so your staff can keep the evidence current.
Your organization and its External Assessor decide what is submitted, since DeployOpen does not issue reports or certificates.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the assessment is complete.
Support helps keep evidence consistent across the one-year certification period and prepares the lighter year-two rapid assessment.
Ask for the written scope, deliverables and retainer terms in your quote before committing to any work.