What a HITRUST assessment scope must include before fieldwork starts
When a customer or contract asks for HITRUST, the scope decides the cost and the timeline more than any other choice. The scope is the set of primary and secondary scope components, facilities and endpoints the assessor tests. HITRUST only certifies implemented systems under the entity's control, meaning installed and operating in production with all primary scope components for at least 90 days, so a system that went live last month cannot be placed in scope for fieldwork that starts now. Before anything else, list every platform, facility and endpoint population you intend to include, then check each one against that 90-day rule and against the question of whether you control the instance.
The organization owns the scope decision and the controls behind it. An implementation partner can prepare systems, configuration baselines and evidence, but only an authorized HITRUST External Assessor submits the validated assessment, and HITRUST performs quality assurance before any report issues. Ask your assessor early to confirm how it will treat each component, because the scope it accepts in the planning phase is the scope it will test. Most scoping problems surface when a team discovers a bastion host, a managed database or a remote workforce location that nobody listed.
The right scope differs by assessment type and by how much of the environment you run yourself. An e1 or i1 can carve out a third party whose responsibilities are documented, while an r2 accepts no third-party carve-outs, so the same vendor may sit outside an e1 and inside an r2. Confirm with your assessor and the HITRUST handbook which rules apply to your assessment type before you draw the boundary. Where you operate on a cloud provider, the provider certifies the services it offers while you certify the platform you run on them, so document that split from the start.
Which components are primary and which are secondary in a HITRUST scope
HITRUST splits a scope into primary components, which are the platforms assessed, and secondary components, which support them. Each category changes how much testing applies and what evidence the assessor will request, so classify every item in your inventory before you draw the boundary.
Primary components: the platforms assessed
Primary scope components are the platforms the assessment is built around, typically applications, operating systems, databases, networks and facilities. Every primary component must be implemented and operating in production under your control for at least 90 days before fieldwork can test it. The assessor will ask for an inventory that names each platform, its owner, its environment and its go-live date, so confirm with your assessor which items count as primary before you finalize the list.
Applications and databases
Applications and their databases are the components most often disputed in QA, because they hold the data and the access paths that the requirement statements test. Record each application and the database behind it as separate entries, with their hosting location and administrators. Expect the assessor to ask for access listings, change records and configuration evidence for each one.
Network infrastructure and network components
Network infrastructure is a secondary component, so it supports the primary platforms rather than defining the boundary by itself. Firewalls, routers, load balancers and segmentation devices that carry traffic to primary components still need to be documented. Ask your assessor how far the network inventory must extend and whether it is tested alongside the platforms it protects.
Endpoints and bastion access paths
Endpoints are secondary components, and only those that can reach a primary component directly without a bastion host, jump server or VDI are tested. Routing administrators through a bastion host therefore narrows the set of endpoints in testing, but the bastion itself and its logging become part of the evidence. Document every path into each primary component so you can show which endpoints were excluded and why.
Authentication platforms and data transmissions
Authentication platforms, such as identity providers and directory services, and data transmissions between systems are secondary components that control who gets in and how data moves. Both affect the access and encryption requirements tested on primary components. List each identity source, each integration and each external data feed so the assessor can trace how data and credentials reach the boundary.
Portable media, mobile devices and supporting tools
Portable media, mobile devices and supporting tools are secondary components that often hold copies of in-scope data or administrative access outside the data center. Decide whether each category is in scope, then record how it is managed, encrypted and disposed of. Confirm with your assessor which supporting tools, such as backup, logging and ticketing systems, must be listed as components.
How the 90-day implemented system rule sets your earliest fieldwork date
This sequence shows which primary scope components qualify as implemented systems, when each one's 90-day clock started, and the earliest date your assessor can begin fieldwork. Each step leaves a record that your assessor and HITRUST QA can check.
Freeze the list of primary scope components
Start with the draft scope and confirm which platforms are primary scope components: applications, operating systems, databases, networks and facilities that hold or process the data in question. Your compliance lead and the system owners sign off on the list, and the assessor reviews it before anything else is measured. Done means every component has a name, an owner and a unique identifier in one inventory, and nothing is added without a recorded scope change.
Confirm each component is under your control
For each primary scope component, check that your organization owns or controls the instance, whether it runs in your cloud account, your data center or a provider's service you operate on. Components whose instances sit outside your control, such as customer-installed mobile apps, cannot be certified by you. Record the control basis for each one, such as account ownership or a contract, so the assessor can accept the scope without challenge.
Verify production operation for each component
Confirm that each component is installed, configured and operating in production, not in a test, staging or pilot environment. Operations or the platform team should pull deployment records, configuration baselines and monitoring history that show the live state. Done means each component has a verified production status with a date you can point to, not an estimate from memory.
Record the production start date for each component
Find the date each primary scope component first reached full production with all of its primary scope parts in place. Take this from the change or release record, the deployment pipeline log or the cloud provisioning history, and keep the source with the date. Done means your inventory has one production start date per component, with the evidence reference beside it, and any component whose date is unclear is flagged for follow-up before you count days.
Count 90 days from the last component to go live
The rule requires each implemented system to have run in production for at least 90 days. Calculate that period for every primary scope component, then identify the latest date on which the final component reached the 90-day mark. A component added mid-project restarts its own clock from the date it entered production, so a late addition can move your earliest fieldwork date. Done means a dated table shows when each component qualifies.
Test whether fieldwork can overlap the period
Fieldwork can begin before every 90-day period has elapsed only if the testing itself happens after those periods end. Ask the assessor to confirm in writing which components and which testing activities can fall inside the window, since the assessor decides the testing window within the limits of the handbook. Done means the assessor has agreed, in writing, the earliest fieldwork date and which components are tested on that date.
Hold the change record and reconfirm before fieldwork
Before fieldwork starts, check the inventory again for any component added, reconfigured or moved since you counted. Keep the change tickets, the production start records and the assessor's written fieldwork date together in the assessment file. Done means nothing in the scope has changed without a recorded reason, and the compliance lead can show the dates that justify the start of fieldwork.
Which facilities the certification letter names and which places cannot count
The facilities in your HITRUST assessment scope are named in the certification letter, so every data center, office, hosted cage and service provider site that houses an in-scope component must appear there by name. A vague description such as "our cloud regions" or "headquarters and branches" invites QA questions later. Before you start, list each physical location that hosts a primary scope component, supporting infrastructure or the staff who administer it, and confirm with your assessor how each site will be described in the letter. Ask whether a colocation provider's suite will be named separately from the provider's campus, and whether a hosted cage counts as the organization's facility or the provider's.
In-scope facilities must be places that the organization or its service providers control. An employee's home, a coworking office or a hotel lobby does not qualify, even if a laptop used for administration is connected from there. A remote workforce is handled through the endpoint rules instead: the endpoints that can reach a primary scope component directly fall into scope, and the controls on those devices, such as encryption, screen locking and managed configuration, become the evidence. If remote staff reach systems only through a bastion host, jump server or VDI, the tested endpoint population narrows accordingly, so the design of that access path is a scoping decision, not just an architecture choice.
For each named site, keep a control record that states the address, the operator (the organization or a named provider), who holds physical access rights, which in-scope components sit there, and the contract or document that establishes control. Refresh the record whenever a site opens, closes, moves or changes operator, because a facility that changes hands can change the letter. Ask your assessor to review the draft facility list before fieldwork begins, since a site discovered late in the process can force a rescope of the systems and endpoints tied to it.
How carve-outs of third parties work in e1, i1 and r2
HITRUST does not accept carve-outs of third parties in an r2 assessment. Every third party that supports a primary or secondary scope component stays inside the assessment, and the requirements that depend on that party must be covered in another way. In practice, the organization either inherits results from a provider's own HITRUST assessment or SOC 2 report where the report can be relied on, or the organization tests the relevant controls directly as part of its own fieldwork. The choice is made per requirement, so the scope document should record which third-party functions are inherited and which are tested.
- No removal from scoring: A hosting, payroll or support provider cannot be excluded from the r2 score to simplify the work.
- Inheritance as the usual route: Results from a provider's validated assessment can be reused where the scope and dates match your own.
- Direct testing as the fallback: Where inheritance is not available, the assessor tests the controls in your environment.
- Documented responsibilities: A shared responsibility matrix should show which party owns each requirement.
Check early whether each critical provider holds a HITRUST certification or other report that covers the services you use, because gaps found late in fieldwork are costly to close.
In an e1 assessment, a third party can be carved out when its responsibilities are documented. A carved-out third party is removed from scoring entirely, so its performance does not affect the score. The organization must still show that the party exists in the scope and that its role is recorded. Requirements that the third party fully owns are not left unanswered. They are marked N/A with a rationale that explains the third party's ownership, and the rationale must hold up when QA reviews it.
- Documented responsibilities: Record the services the third party provides and the boundary between its duties and yours.
- Full removal from scoring: The carved-out party does not contribute to the score in either direction.
- N/A for fully owned requirements: Requirements the third party fully owns are marked N/A with a rationale.
- Partial ownership stays in scope: Requirements shared with the third party remain assessed on your side.
- Consistent boundary: The carve-out must match the systems and facilities named in the scope.
Before you carve out a party, confirm that its responsibilities really are fully owned by it, since an overbroad carve-out is a common reason QA rejects N/A decisions. See the topic on marking requirements N/A for the rationale rules.
The i1 follows the same carve-out principles as the e1. A third party can be carved out if its responsibilities are documented, it is removed from scoring entirely, and requirements it fully owns are marked N/A with a rationale. Because the i1 control set is fixed, the organization decides which systems or departments define the scope, but it cannot remove requirements that the carve-out does not cover. The carve-out therefore changes who is scored, not which requirement statements exist.
- Fixed control set: The i1 requirement statements stay the same, whatever the carve-out.
- Scope by systems or departments: The organization sets the boundary, and the carve-out sits inside it.
- Same documentation duty: Responsibilities must be written down before fieldwork begins.
- N/A limits apply: Only requirements that are fully owned by the third party can be marked N/A.
- Inheritance as an alternative: A provider's results may cover some requirements without a carve-out.
When you plan an i1, compare the carve-out with inheritance for each critical provider, because inheritance keeps the provider's controls visible in your results. The topic on inheritance and shared responsibility explains that choice in detail.
Scope the whole organization or define an i1 scope by system or department
This table compares scoping the whole organization or full platform set for an e1, i1 or r2 against defining an i1 scope by system or department. Read each row as a question the scope conversation must answer, and use the cost row to frame what to request in a quote from your assessor.
| Decision point | Whole organization or full platform set (e1, i1 or r2) | i1 scope by system or department |
|---|---|---|
| Who it fits | Organizations whose customers or contracts need the certification to cover the enterprise, or r2 holders that must show every in-scope platform, facility and endpoint | Organizations that need an i1 for a defined business unit, product line or set of systems, and can name a boundary their customers accept |
| What the assessor tests | Every primary scope component and the secondary components tied to it, including facilities named in the letter and endpoints that connect directly to primary components | The systems or departments defined in the scope, tested against the fixed i1 requirement statements that apply to them |
| Control set | Set by the assessment type (e1, i1 or r2), with r2 requirements tailored by factors | The i1 control set is fixed. Defining the scope changes what is assessed, not which requirement statements exist |
| Effect on the scope conversation | Scope discussions cover every platform, facility and endpoint class, and carve-out decisions affect the whole assessment | Scope discussions focus on the boundary: which systems or departments are in, which are out, and how shared services are treated |
| Effect on cost and effort | Effort grows with the number of in-scope platforms, facilities and endpoints. Ask the assessor how each added component changes the quote | Effort tracks the chosen boundary. A narrower boundary reduces evidence work, but shared services outside it still need documented responsibilities |
| Carve-outs | Third parties cannot be carved out of an r2. In an e1 or i1, a carve-out requires documented responsibilities and removal from scoring | A third party that serves the boundary can only be carved out in an e1 or i1 under the same documented-responsibility rule |
| What must be true for QA | Each in-scope system is implemented under the entity's control for at least 90 days, and every facility and endpoint class is accounted for | The boundary is written down, consistently applied across evidence, and every system or department in it meets the 90-day implemented rule |
| Main QA risk | Scope drift: a system, facility or endpoint is missing from the letter or scope documents, or a bastion host narrows endpoint testing unexpectedly | Boundary leakage: evidence from outside the defined systems or departments appears in the assessment, or shared services are not documented |
| Who decides | The organization decides, with its assessor's input on what the assessment must cover | The organization decides the boundary, with its assessor's input on whether the boundary is testable and defensible |
Which scope mistakes cause QA rejections and how to avoid each
Most HITRUST scope problems surface late, during QA, when a system, facility, endpoint or third party no longer fits the boundary the team documented. Each pitfall below shows what it costs in time or score and the control that keeps the scope defensible from the start.
System not running 90 days
HITRUST certifies only implemented systems that have been installed and operating in production with all primary scope components for at least 90 days. A system deployed or migrated shortly before fieldwork can push the fieldwork start date back, or leave it untestable at the window you planned. Keep an inventory that records each primary component's production go-live date, and check it against the planned fieldwork window before the scope is locked. Ask your assessor how overlap with fieldwork is treated if testing falls after the 90 days.
Facility missing from the letter
Facilities in scope are named in the certification letter, so a data center, office or hosting site that operates a primary component but is not listed creates a gap QA will find. Facilities that neither your organization nor its service providers control, such as employee homes or coworking space, cannot be included at all. Maintain a facility register that links each site to the components it hosts, the party that controls it, and the date it entered service. Review it before every assessment and whenever a site opens, moves or closes.
Bastion host hiding endpoints
Endpoint testing covers the server and user endpoints that can reach a primary scope component directly. Routing all administrator access through a bastion host, jump server or VDI reduces the endpoints tested, which looks efficient but leaves unlisted paths unexamined. Assessors will ask how each path to a primary component was established. Build an endpoint inventory from network flow records and directory data, not from the access design diagram alone, and confirm that no direct route bypasses the bastion before you narrow the endpoint population.
Third party carved out in an r2
In an r2 HITRUST accepts no carve-outs of third parties, so a provider you hoped to exclude must be included, or its responsibilities must be handled through inheritance from its own HITRUST or other assessment results. Carve-out logic that works in an e1 or i1 does not transfer. Decide the assessment type before drawing the boundary, list every service provider touching in-scope data or components, and document which path (inclusion, inheritance or exclusion where the assessment type allows it) applies to each.
Scope changes after fieldwork starts
A system added, retired or re-segmented once fieldwork begins forces the team to reconcile evidence collected against a boundary that no longer exists. That reconciliation can delay testing and undermine results already gathered. Freeze the scope through a signed scope document that names every system, facility, endpoint class and third party, and route any proposed change through a logged change request approved by the assessment owner. Keep the change log with dated entries so the assessor can see exactly what moved and when.
Cloud service treated as customer-operated
A cloud provider certifies the services it offers, while each customer certifies the platform it operates on that provider's infrastructure. Teams that list the provider's managed database or storage service as their own component, or that assume the provider's certification covers their configuration, will either double-count controls or leave customer-side responsibilities unaddressed. For each cloud service, record who operates the instance and its configuration, and map the split against the provider's documentation. Mark the customer-side controls clearly in the scope document so reviewers can see where your responsibility starts.
What cannot be certified and how to explain it to the assessor
HITRUST cannot certify an application whose instances sit outside your control. Mobile apps are the common example: the copy running on a customer's phone is not installed and operated by your organization, so it falls outside the scope an assessor can test. What you can scope is the back-end infrastructure that the app calls, including the APIs, application servers, databases and authentication services behind it. Decide early which of those components are primary scope and which are secondary, and write down why the client-side code is excluded. An assessor will ask about it in the first scoping discussion, and a clear answer at that stage costs far less than a scope change during fieldwork.
Cloud services split responsibility by who operates what. The provider certifies the services it offers, and each customer certifies the platform it builds and runs on those services, such as its virtual machines, containers, databases, configurations and identity settings. Before fieldwork, prepare a written responsibility split that lists each in-scope component, the party that operates it, and the HITRUST result, if any, that covers the layer below. Confirm the provider's current assessment letter and scope with the provider directly, because the boundary of its certification determines what you can inherit and what you must test yourself. Bring this document to your External Assessor early so disagreements surface before testing starts.
Do not tell customers, auditors or internal stakeholders that the certificate covers an item you have excluded. A certification letter names the scope that was assessed, and a relying party who reads the phrase "HITRUST certified" as a blanket statement about your whole service will be misled. Describe exclusions in the same terms the letter uses, and keep the written split with your assessment records. Any reliance on a provider's result, and how that result is reused in your own assessment, is covered separately under HITRUST inheritance and shared responsibility.
Questions buyers ask about HITRUST assessment scope
Who decides the scope of a HITRUST assessment?
The organization proposes the scope, and the External Assessor accepts it. Your team decides which platforms, facilities and endpoints belong to the system being assessed, because the organization owns its controls. The assessor then tests whether that scope is defensible against HITRUST's rules and records the accepted scope in the certification letter. Only the assessor issues the report and certification, and HITRUST performs central quality assurance before it is issued. An implementation partner can help you prepare the scope documentation and system inventory, but it does not approve the scope or sign off on it.
Does a mobile app have to be in HITRUST scope?
Usually not as the app itself. HITRUST only certifies systems under the entity's control, and an app installed on a customer's or employee's device runs outside that control. The back-end infrastructure that the app calls is in scope and can be certified. If your organization publishes and operates the app's back end, those services belong in scope. Confirm the boundary with your assessor early, because a mobile app that also depends on a third-party SDK or device-side storage raises questions about what the entity actually controls.
Can a remote or home office appear in the certification letter?
No. The facilities named in the certification letter must be places your organization or its service providers control. Employee homes and coworking offices fall outside that test, so they cannot be listed as in-scope facilities. Staff who work remotely can still be covered through the endpoint and access requirements, which apply to the devices and connections that reach primary scope components. Ask your assessor how remote endpoints will be tested before you finalize the facility list.
What happens if a new system is added during the assessment?
A system added mid-assessment must meet the same rule as any other: it has to be implemented, under your control, and running in production with all primary scope components for at least 90 days. A system that has not yet reached that point cannot be certified in the current cycle, so it is usually handled in a later assessment. Changes to scope can also affect the fieldwork window, which is at most 90 days, and may require the assessor to re-evaluate the boundary. Raise any planned system change with your assessor before fieldwork starts, not after evidence has been collected.
Can an implementation partner draw the HITRUST scope for us?
A partner can help you draft the scope, but the decision belongs to your organization and the acceptance belongs to the assessor. A useful partner will inventory your platforms, map data flows, identify facilities and bastion hosts, and document which components are primary and which are secondary. That work becomes the basis for the assessor's scoping discussion. The partner does not issue assessments, certifications or reports, and it should not present its draft as an approved scope. Ask any partner to show how its scope documents feed into the assessor's review.
How does scope drive the cost and effort of a HITRUST assessment?
Scope is usually the largest driver of effort because it sets how many components are tested and how much evidence is collected. The main drivers are the number of primary scope components, the number of facilities named in the letter, the count of server and user endpoints that connect directly to scope components, and the number of third parties whose responsibilities must be documented. Each added platform adds evidence collection, sampling and review work. A narrower scope usually costs less to prepare for, but it must still reflect what the organization actually operates. Ask any quote to itemize work by scope component, facility and endpoint group.
Can we define our own scope for an i1 assessment?
Yes, within limits. For an i1, your organization can define the scope by system or by department, but the control set itself is fixed. That means you choose which systems or departments are in the boundary, and the assessor then tests the same i1 requirements against that boundary. Scope choices still have to be defensible. Excluding a system that processes sensitive data to shorten the assessment is the kind of decision QA and assessors question. For an e1 or i1, third parties can be carved out only when their responsibilities are documented, and for an r2 no third-party carve-outs are accepted.
How DeployOpen maps systems, facilities and endpoints before a HITRUST assessment
DeployOpen works through the scope questions that decide what a HITRUST assessor can test: which systems are implemented and under your control, which facilities are named, and which endpoints can reach primary scope components. We prepare the systems, documentation and evidence for that scope, while your organization owns its controls and only an authorized External Assessor can perform the validated assessment.
How we scope
- We list primary and secondary scope components and confirm each is installed and operating in production under your control.
- We check which systems have run for the required 90-day period and flag any that will not qualify before fieldwork.
- We document facilities, endpoints, bastion hosts and carve-outs in the written scope agreed before work starts.
How we build
- We configure self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks to match the defined scope.
- We route administrative access through documented bastion hosts or jump servers where the design calls for it, and record the endpoints that remain in scope.
- We test scope boundaries, such as whether a direct path to a primary component exists, before the assessor arrives.
How we hand over
- We deliver a scope register that names each system, facility, endpoint and third party with its owner and rationale.
- We document data flows, network diagrams and access paths so an assessor can confirm the scope boundary without reconstructing it.
- We hand over the configuration records and evidence mapped to each in-scope component, so your team can maintain them after the engagement.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as retainers when scope changes after the first assessment.
- We help your team review scope changes against the rules for significant changes, and confirm with your assessor before any change takes effect.
