To scope a HITRUST assessment, choose the assessment type first (e1, i1 or r2), then define the in scope systems, the sensitive data they handle, the facilities and the organisational units, and note which controls you inherit from certified cloud providers. A tight but honest boundary is the biggest lever on cost and difficulty.
Which assessment sets the bar?
HITRUST describes three assessments built on the HITRUST CSF. The e1 has 43 foundational controls, is valid for one year and suits startups and limited risk profiles. The i1 has 182 control requirements, is valid for one year and suits organisations with established programs. The r2 is the most comprehensive, valid for two years, and fits regulatory needs such as HIPAA or NIST CSF with risk based tailoring. Work from an earlier assessment can count toward a later one, and you can inherit existing controls from certified cloud providers. The page does not describe scoping rules in detail, so your assessor and the HITRUST documentation are the authority for scoping specifics.
What goes into the scope?
- The assessed entity. Which legal entity and business unit, and which products or services.
- Systems. Applications, databases, servers, networks and supporting services that store, process or transmit the sensitive data in question. Include the identity provider, build and deployment tools and admin paths.
- Data. What sensitive data you handle, such as health information, and where it flows. A data flow diagram is the center of scoping.
- Facilities. Offices and data centers in scope, or reliance on a provider.
- People. Teams with access to the systems and data.
- Third parties. Providers of in scope services, with the assurance each can supply.
- Inherited controls. Which controls a certified cloud provider covers, which you still own, and which are shared.
- Exclusions. Systems left out and why, with how they are isolated.
How do you keep scope small without cheating?
Isolate. If only one product handles the sensitive data, put it in its own cloud account, network segment and identity group, so the boundary is real. Drawing a line on a diagram that traffic and admins cross freely will not hold up with an assessor. Keep the number of facilities and platforms low where you can. Then use inheritance for the cloud layer, while documenting what you configure on top of it.
How do you choose between e1, i1 and r2?
Ask what your buyer requires. If the customer asks for any HITRUST assessment, start where the contract allows. A startup with limited risk may begin with e1 and grow. If the buyer or regulation points to the broader set, plan for r2 and treat earlier assessments as stepping stones, since HITRUST says work carries forward.
What mistakes are common?
- Scoping by application and forgetting the shared services beneath it.
- Declaring data out of scope while logs, backups or analytics hold it.
- Assuming inheritance covers your own configuration.
- Picking an assessment that does not satisfy the buyer.
- Letting scope creep after the assessment starts.
How do you test the boundary before the assessor does?
Trace sensitive data from where it enters to where it is deleted, and write down every system and person that touches it on the way, including logs, backups, support exports and analytics copies. Then ask engineering whether anything in that list sits outside your declared boundary. Each hit is either a scope extension or an isolation task, and finding it early is far cheaper than finding it mid assessment.
What to do
- Confirm what your customers or regulators accept.
- Draw the data flow for sensitive data end to end.
- List systems, facilities, people and third parties.
- Isolate the in scope environment technically.
- Record inherited and shared controls with the provider's evidence.
- Review the scope with your assessor before work starts.
Quick check
Can a HITRUST assessment inherit controls from a cloud provider?
HITRUST says organisations can inherit existing controls from certified cloud service providers, though you still own your own configuration.
How long is an r2 valid?
HITRUST describes the r2 as valid for two years, while e1 and i1 are valid for one year.
How Safeguard helps automate this
Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires. After scoping, evidence is collected from connected systems and code instead of by screenshot, and monitoring runs between assessments. The software side of your boundary, meaning which services and dependencies touch sensitive data, comes from scans, SBOMs and reachability on your real repositories. Safeguard's agent can open tested fix pull requests for vulnerable dependencies. It is off by default, every category starts on Manual, and you choose which categories run automatically and the approval level. HITRUST validation is done by an external assessor. Safeguard helps you prepare and keep evidence ready.
Open the framework mapping demo
Sources
- HITRUST assessments and certifications, fetched 18 October 2026
Last reviewed: 18 October 2026.
