If you're a health tech startup and a customer has asked for HITRUST, the e1 is often the place to start. It's HITRUST's foundational assessment: smaller in scope than the i1 or r2, focused on the security basics every company handling health data should have.
This guide explains what the e1 is, who it suits, what it doesn't cover, why many buyers accept it, and the gaps startups most often need to close.
What the HITRUST e1 is
The e1 is an assessment against 44 foundational security controls. Once your controls are validated by a HITRUST Authorized External Assessor and pass HITRUST's quality assurance, HITRUST issues an e1 certification that is valid for one year.
Here's how it sits next to the other two assessment types:
| e1 | i1 | r2 | |
|---|---|---|---|
| Controls | 44 foundational security controls | 182 control requirements | Tailored, risk-based control requirements |
| Certification valid for | 1 year | 1 year | 2 years, with an interim assessment |
| Best for | Startups and companies with a limited risk profile or less complexity | Organizations with a robust security program that want to show leading practices | Organizations that must show compliance with sources such as HIPAA or NIST CSF, or need control tailoring based on risk factors |
Who the e1 suits
HITRUST describes the e1 as being for startups and companies with a limited risk profile or less complexity. In practice, that usually means:
- An early-stage health tech company selling to clinics, small practices or other startups.
- A company that handles little PHI, or handles it in a narrow, well-defined way.
- A team without years of formal, audited security controls behind it.
- A company whose customer wants to see a recognized HITRUST result, and is willing to accept the e1 as a first step.
If you already run a mature program with SOC 2 or ISO 27001, an i1 may be a better fit. Our HITRUST assessment chooser can help you decide.
What the e1 doesn't cover
Be clear with yourself, and with your customer, about the e1's limits. It's a foundational assessment. It isn't designed to show HIPAA compliance, and it doesn't include the risk-based tailoring of the r2.
If a customer tells you they need to see HIPAA or NIST CSF coverage specifically, they're describing the r2. Ask before you commit, because an e1 that the customer won't accept doesn't help your deal.
Why many buyers accept the e1 as a first step
Many healthcare customers accept an e1 to start. For a buyer, it's an independently validated, HITRUST-issued result that shows a vendor has the basics in place. For you, it's a smaller project than an i1 or r2, so you can show progress sooner.
The key word is "accept". Always confirm with your customer that an e1 meets their requirement, or that they'll accept it now with a plan to move to an i1 or r2 later.
How e1 work carries into an i1 or r2
Nothing you build for an e1 is wasted. Work on an e1 can be built on toward an i1 or r2, and work toward an i1 can be applied to an r2. The 44 foundational controls are the base the larger assessments build on.
That makes the e1 a sensible first stage for a growing company. As you move from small practices to larger hospitals, health systems or payers, you extend the same control set rather than starting again.
Common gaps startups hit
These are the gaps we see most often when startups prepare for an e1. None of them are unusual, and all of them are fixable.
| Gap | What it usually looks like | What fixes it |
|---|---|---|
| Written policies | Good practices, but nothing written down or approved | A short, approved policy set that matches what you actually do |
| Access reviews | Access granted quickly, rarely reviewed or removed | A scheduled review of who has access to what, with records |
| Logging | Logs exist but aren't centralized or reviewed | Central logging for key systems and a record of reviews |
| Vendor management | No list of vendors that touch PHI | A vendor inventory, contracts and a simple review process |
| Incident response testing | A plan exists but has never been tested | A tabletop exercise, with notes and follow-up actions |
The common thread is evidence. Many startups do the right things but can't show it. The e1 asks you to prove your controls work, so build the habit of keeping records from day one.
Use cloud inheritance to reduce the work
If you host on a certified cloud provider such as AWS, Azure or Google Cloud, HITRUST's Shared Responsibility and Inheritance Program lets you inherit controls your provider already has in place. HITRUST states organizations can inherit 70% to 85% of requirements from participating cloud service providers.
Inheritance doesn't cover everything. You still own your access management, application security and policies. But it can remove a large share of the infrastructure and physical security work. Read our guide to HITRUST inheritance on AWS, Azure and Google Cloud for the details.
Questions to ask your customer before you commit
A five-minute conversation with your customer can save you weeks. Ask:
- Will you accept a HITRUST e1, or do you need an i1 or r2?
- If you accept an e1 now, will you expect an i1 or r2 at renewal?
- When do you need the certification in place?
If the answer is "e1 is fine", you have a clear, focused project. If it's "we need an r2", you know before you've spent anything.
How CyberWave GRC helps startups with the e1
At CyberWave GRC, we keep e1 projects lean. We run scoping, the gap assessment, remediation guidance, policies and evidence, MyCSF setup and inheritance mapping. The validated assessment is performed by Huduku AI, an independent HITRUST Authorized External Assessor we work with, and HITRUST performs quality assurance and issues the certification. We never certify our own work.
Our team includes HITRUST CCSFP and CHQP certified practitioners. Recent work includes a HITRUST e1 alongside SOC 2 for a US health tech company, so we're used to building one control set that serves both. See our HITRUST consulting page to learn more.