Should a startup start HITRUST with the e1?
The e1 is HITRUST's entry validated assessment for startups and lower-risk organizations. In CSF v11.9.0 it has 44 requirement statements, and a certification lasts one year, so the e1 is usually the right first step when a customer asks for HITRUST but has not specified a level. Whether it is the right step for your company depends on three things: the level the customer or contract actually names, how sensitive the data you handle is, and whether a cloud provider or other third party can be carved out of scope. HITRUST positions the i1 for maturing programs that need moderate assurance and the r2 for organizations handling highly sensitive data or high-risk systems, so a customer asking for an r2 should not be answered with an e1 without a conversation first.
Ask the customer in writing which certification level and which scope they will accept, and whether a validated report or a letter of certification is required. Then check the data you process against that expectation. Carve-outs also matter at this stage. HITRUST does not allow a third party to be carved out of an r2, but in an e1 or i1 a third party can be removed from scoring if its responsibilities are documented and requirements it fully owns are marked N/A with a rationale. A startup that runs entirely on a major cloud platform should confirm early how the provider's responsibilities will be handled, because that choice shapes the size of the assessment.
The organization owns its controls and the evidence behind them. DeployOpen can prepare systems, configurations and evidence where it is engaged under a written, fixed scope, but DeployOpen does not perform the assessment or issue any certification. Only an authorized External Assessor performs the validated assessment, and HITRUST performs quality assurance and issues the certification. If you already hold SOC 2 work, HITRUST publishes guidance on applying it toward an e1, so ask an External Assessor which of your existing evidence it will accept. Confirm current requirements, fees and validity directly with HITRUST and your assessor before committing budget, using the HITRUST e1 assessment page as the starting point.
What drives the cost and effort of a startup e1
An e1 is priced and timed by what sits inside the assessment boundary, who has to produce evidence and how much of that evidence already exists. The cards below cover the levers a startup controls most directly, and each one shows where to ask for a clearer scope before any money is committed.
Systems and cloud accounts in scope
Every production system, cloud account, data store and admin workstation that handles customer data can pull controls into the assessment. Map the data flows first, then draw the boundary around the smallest set of systems that genuinely touch that data. A single shared cloud account holding everything makes every control applicable to everything, so splitting production from internal tooling early reduces the sample sets an assessor must test. Ask your external assessor to confirm the boundary in writing before fieldwork begins.
Headcount that touches the controls
Access reviews, onboarding, offboarding, security training and change approvals all rely on people. The more staff who hold production access or handle customer data, the more population an assessor samples and the more records you must produce. Keep the number of standing administrators low, use role groups rather than individual grants, and document who approves what. Confirm with your assessor how they will sample personnel records before you agree on a scope.
Carving out or inheriting the cloud provider
A major cloud provider can be carved out of an e1 if its responsibilities are documented and removed from scoring, or it can be inherited if the provider has its own HITRUST result you can rely on. Carve-outs leave you owning the requirements the provider does not cover, so the paperwork and scoring effort move around rather than disappear. Confirm which path your assessor accepts and whether the provider's current report covers the services you actually use.
Evidence maturity from existing SOC 2 or ISO work
If you already run a SOC 2 examination or an ISO 27001 management system, many e1 requirements can draw on evidence you already collect, such as access reviews, vulnerability scan records and incident logs. HITRUST publishes guidance on applying SOC 2 work toward an e1, so ask whether your prior reports and control owners map cleanly. Gaps usually appear in evidence that was collected once for an audit and never repeated, so check that the evidence is current and attributable to a named owner.
Assessor and HITRUST fees
An e1 involves fees paid to an Authorized HITRUST External Assessor for fieldwork and to HITRUST for the platform and certification. Only the External Assessor issues the validated results, so the assessor's quote is the main variable. Ask for a fixed-scope proposal that lists fieldwork days, report review and any readiness work separately, and confirm which HITRUST charges apply to your tier. Consolidating work into one firm and one fieldwork window usually keeps coordination effort down.
How long an e1 takes and what HITRUST cites
HITRUST cites an average of about 30 days for e1 certification, but treat that figure as HITRUST's own estimate for the e1 path, not a schedule your organization can commit to. The number describes a typical run, and where a given company lands depends on how ready its controls already are, how tightly the scope is drawn, and whether it has a dated history of evidence to show an assessor. A startup with a small cloud footprint, a single product and clean access and logging records will sit near the lower end. A company that has never written down its policies, or that must still collect proof that controls operated over time, should expect the work to take longer before fieldwork even begins.
Plan around two separate windows. The first is the system and control incubation period, which HITRUST expects to be in place before an assessment so that controls have operated long enough to be tested. Treat it as a planning consideration: if a control was only switched on last month, the evidence will not yet show it working over time. The second is fieldwork, the period in which the External Assessor validates your evidence, and the rule is that it runs for at most 90 days for e1, i1 and r2 alike. Fieldwork is the window you control least, because it depends on how quickly your team answers requests and how many gaps the assessor finds.
Before you sign with an External Assessor, ask for a written schedule that shows the readiness review, the incubation date you need to meet, the fieldwork start and end, and the point at which HITRUST quality assurance and the draft report review will fall. Confirm which dates depend on your team and which depend on the assessor or HITRUST. Ask the assessor how many similar startup e1 assessments it has completed and what it typically finds first, since those answers shape your real timeline more than any published average.
The phases from scoping to a certified e1
The e1 path runs in a fixed order: scope the assessment, prepare the controls, collect evidence through an incubation period, have an authorized External Assessor test it, pass HITRUST quality assurance and receive the certification. Each phase produces a named output that the next one depends on.
Scope the e1 assessment in MyCSF
The organization defines what the assessment covers: the systems, applications, facilities and data that process or store the information in scope, and which third parties are involved. The scope is recorded in MyCSF, HITRUST's assessment platform, and the organization owns this decision because it determines which requirements apply. The step is complete when the scope is documented, reviewed internally and agreed with the External Assessor you plan to use. Ask any consultant or implementation partner to confirm in writing which parts of the scope they will touch.
Prepare controls with an internal owner
A named internal owner, supported by an implementation partner if you use one, works through the 44 e1 requirement statements in v11.9.0 and closes the gaps between current practice and what each statement asks for. The owner assigns each requirement to a person, records policies and procedures, and marks any requirement that the organization fully owns as a third-party or N/A item only with a documented rationale. The output is a readiness-ready control set that the owner can walk an assessor through. Confirm with your partner who writes evidence, who approves it and who holds the MyCSF account.
Run the incubation period and collect evidence
Controls must operate for a period before the assessor tests them, so the organization runs them and keeps dated records of each operation. Evidence includes policy approvals, access reviews, vulnerability scan results, change tickets, training completions, backup restore tests and incident logs, with the reviewer and date on each item. The step is complete when each requirement has evidence that covers the assessment period and the owner has checked it against the requirement text. Ask your assessor to confirm the incubation rules that apply to your controls before you set the start date.
Complete fieldwork with an External Assessor
An HITRUST Authorized External Assessor, not HITRUST and not the implementation partner, tests the controls against the evidence. The assessor samples records, interviews staff, observes controls and scores each requirement. Fieldwork is limited to a window of at most 90 days under the Assessment Handbook. The output is the assessor's completed validated assessment, with findings and any corrective actions recorded in MyCSF. Your team answers requests, supplies missing evidence and keeps a log of each exchange so that the assessor's findings can be traced.
Pass HITRUST quality assurance
After the assessor submits the assessment, HITRUST performs central quality assurance before any report is issued. The reviewers check that scoring follows HITRUST's rules and that the evidence supports each result. HITRUST may return questions or request clarification, which the assessor and your team resolve in MyCSF. The step is complete when HITRUST accepts the assessment for report issuance. Confirm with the assessor how the QA queue is scheduled and what service levels apply to your engagement.
Review the draft report
Before the final report is issued, the organization reviews the draft report produced from the validated assessment. The review checks that the scope statement, the systems described, the third-party treatment and the scores match what was agreed in the scoping step. Factual errors go back to the assessor through the agreed process. The output is a signed-off draft that your leadership accepts as accurate. Keep a record of each correction so that the final report and your evidence library stay consistent.
Receive the e1 certification and plan renewal
When the report is final, HITRUST issues the e1 certification, which is valid for one year and must be renewed annually. The organization shares the report and letter with customers and relying parties under its own distribution rules. The step closes with a renewal plan: a calendar date, an owner, and a list of controls that will need fresh evidence. Because e1 work carries forward to the i1 and r2, the evidence library built here is also the starting point if a customer later asks for a higher level.
Carving out a cloud provider in an e1 versus an r2
In an e1 or i1, an organization can carve out a third party, such as a cloud provider, if that party's responsibilities are documented. Carving out removes the provider from scoring entirely. Requirements that the provider fully owns are then marked N/A, and each N/A needs a written rationale that the External Assessor can test. The organization still owns the outcome for anything it keeps in scope, so the carve-out narrows the work without transferring accountability.
- Documented responsibilities: Record which controls the provider operates and which controls the organization operates, in writing, before fieldwork.
- Full scoring removal: The provider is excluded from scoring, so its controls do not count toward or against the result.
- N/A with rationale: Requirements the provider fully owns are marked N/A, and each entry explains why the provider owns it.
- Assessor review: The External Assessor tests whether the documented boundary matches what the provider actually does.
- Shared controls stay in scope: Any requirement split between both parties remains scored on the organization's side.
Confirm the carve-out approach with your External Assessor early, since the boundary you document becomes the basis for every N/A in the assessment.
HITRUST accepts no carve-outs of third parties in an r2. A cloud provider that hosts or processes in-scope data or systems stays inside the assessed environment, and its relevant controls are evaluated as part of the organization's assessment. The r2 is built for higher-risk environments, so the approach is not a matter of choosing a lighter option. Plan for the provider's controls to be examined alongside your own, using inheritance where the provider's results support it.
- No third-party carve-out: The cloud provider cannot be removed from scoring in an r2.
- Inheritance is still possible: Relevant results from the provider's own assessments may be reused as inherited controls, subject to HITRUST rules.
- Scope is set earlier: Because the provider stays in scope, the boundary and system descriptions must be complete before fieldwork.
- Evidence covers the provider's share: Expect the assessor to request evidence for the provider's responsibilities, not only your own.
- Cost and effort rise with scope: A larger scope generally means more evidence and more testing, which should appear in the quote.
Before committing to an r2, confirm with your assessor which provider results you can inherit and what evidence you must still gather yourself.
Whichever level you pursue, the cloud provider's responsibilities must be written down clearly. Start with the provider's shared responsibility matrix, which describes what the provider secures and what the customer secures. Read it against the requirements in your chosen level, and note any gap where neither party's documentation covers a control. That mapping becomes the record your assessor reviews when deciding whether a carve-out or inheritance holds.
- Obtain the current matrix: Request the provider's most recent shared responsibility documentation and confirm which service models it covers.
- Map to requirements: Tie each provider responsibility to the specific requirement it addresses in your assessment level.
- Identify uncovered controls: Flag any requirement that neither the matrix nor your own controls clearly address.
- Keep provider evidence current: Store the provider's relevant audit reports and their dates, and note when they expire.
- Record ownership changes: Update the documentation whenever you change services, regions or configurations.
Before deciding, review the matrix with your assessor and confirm in writing which responsibilities you will carve out, inherit or retain.
Startup HITRUST questions answered
Can SOC 2 work be applied toward a HITRUST e1 assessment?
Yes, in part. HITRUST publishes resources on applying SOC 2 work toward an e1 assessment, including an eBook on moving from SOC 2 to HITRUST e1. Controls you already tested for a SOC 2 report can map to e1 requirement statements, but a mapping does not transfer the result. Each requirement still has to be evidenced for the e1 assessment, and an External Assessor must validate it. Ask your assessor how they will treat existing SOC 2 testing, what period the evidence must cover, and which requirements still need their own evidence. The HITRUST e1 page is the natural starting point for the official resources.
Can a startup complete an e1 without outside help?
A startup can prepare internally, but the validated assessment itself must be performed by an Authorized HITRUST External Assessor organization. HITRUST does not allow the company to score its own assessment for certification. Readiness work, scoping in MyCSF and evidence gathering can be done in-house by a team that knows the CSF well, and many founders do part of it themselves. Whether that is practical depends on your team's time and familiarity with the requirement statements. Ask any firm you consider to confirm whether it is an External Assessor or a Readiness Licensee, since only the former can perform the validated work.
What does the e1 work need from founders and engineers?
The e1 is a requirement-by-requirement check, so the work is mostly documentation and proof that controls operate. Expect the following to need an owner:
- Written policies and procedures for access, incident response, risk management and vendor management
- Configuration evidence from cloud accounts, identity providers, endpoints and logging tools
- Records of operating controls over time, such as access reviews, patch activity and training completion
- Sign-off from leadership on scope, risk decisions and any requirements marked not applicable with a rationale
Founders usually own policy and risk decisions, while engineers produce the technical evidence. Because the assessor samples evidence over a defined period, controls should be running well before fieldwork starts.
How often does an e1 certification need renewal?
An e1 certification is valid for one year and must be renewed annually. Renewal means a new validated assessment against the CSF version in force at that time, so the evidence for the year ahead has to be current when the assessor reviews it. Plan the renewal date from the day the certification is issued, and keep control evidence flowing throughout the year rather than collecting it in the final weeks. Ask your assessor how they will handle changes in CSF version between cycles. CSF v11.9.0 is the current version, available in MyCSF from September 24, 2026, and it changed the e1 baseline.
Can an e1 be upgraded to an i1 later?
Yes. The e1, i1 and r2 form a traversable portfolio: every e1 requirement is included in the i1 baseline, and every i1 requirement is in the r2 baseline. Work done for the e1 therefore carries forward, and you do not start from zero when moving up. In CSF v11.9.0 the e1 has 44 requirement statements and the i1 has 182, so the step up is a substantial expansion of evidence and maturity work, not a relabeling. Plan for the additional requirements and for the time your controls need to operate before the i1 fieldwork begins.
Does an e1 satisfy every customer that asks for HITRUST?
No. Customers and contracts specify which assessment level they require, and an e1 does not satisfy a request for an i1 or r2. HITRUST positions the e1 for startups and lower-risk organizations, the i1 for maturing programs needing moderate assurance, and the r2 for organizations handling highly sensitive data or high-risk systems. Before committing, ask the customer which certification level, scope and validity period their third-party risk program accepts. Read the contract language carefully, because some customers accept a HITRUST e1 while others request a higher level or an accompanying report.
How DeployOpen works on this
DeployOpen prepares the systems, controls and evidence a startup needs before an external assessor tests them for an e1. We work inside your own cloud accounts or data centers, and we do not issue reports or certifications, which only an authorized External Assessor and HITRUST can do.
How we scope
- We agree a written scope covering the e1 requirement statements, the systems in boundary and the cloud services you run
- Engagements are fixed-scope, so deliverables and timelines are confirmed in writing before any work starts
- We confirm which third parties may be carved out, and which responsibilities must be documented and marked N/A with a rationale
How we build
- We deploy and harden the open-source platforms that produce evidence for access, logging, backups and change control
- We configure the controls to run continuously, so evidence exists before the assessor's fieldwork window opens
- We test the controls against the e1 requirements and record gaps for you to remediate before assessment
How we hand over
- You receive system documentation, control descriptions and an evidence map linking each requirement to its source
- Runbooks explain how your team collects, retains and presents evidence to the External Assessor during fieldwork
- The e1 work is structured so that the same controls carry forward to an i1 or r2 without being rebuilt
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- Retainers can cover annual recertification preparation, including updates when the CSF version changes
- Your external assessor and HITRUST remain responsible for the assessment, quality assurance and certification decision
