HITRUST sampling requirements and populations: what your team must prepare before fieldwork
When a customer or contract requires a HITRUST validated assessment, your team needs to know how the External Assessor will draw samples, because the populations you hand over decide whether the evidence can prove anything. Assessors sample time-based and item-based populations under fixed rules: a sampling period of at least 90 days for time-based populations such as backups, change tickets or joiners and leavers, populations that can actually reveal errors, and sample sizes at or above HITRUST's minimums. Your organization builds and maintains those populations, so the preparation is yours to do before fieldwork starts.
The specifics change with the number of tools, control owners and whether a control is automated or manual. A patch population pulled from one scanner may be straightforward, while a population combined across several tools must follow one process and one control owner or it will not be accepted as a single population. Automated controls follow a different path: the assessor expects configuration evidence plus a test of one showing the system enforces the rule, such as a user being blocked from setting a non-compliant password. Ask your assessor early which populations they will draw from and whether any of your planned sources can be checked independently.
Roles matter here. Your organization owns its controls and the records that prove them. DeployOpen, as an implementation partner, can prepare systems, configure logging and export populations in a form that suits assessment, but it does not perform the validated assessment or issue reports. Only an authorized HITRUST External Assessor performs the validated assessment, and HITRUST performs quality assurance before issuing a report. Confirm with your assessor which populations they will request, the sampling period they expect and whether any item-based list must be generated within the 30 days before fieldwork, then assign an owner to each population.
How assessors test automated controls with a test of one
For a control that a system enforces on its own, such as a password complexity rule or an automatic session timeout, the assessor does not need a sample of many occurrences. The test has two parts: evidence of how the system is configured, and a test of one showing the system actually enforces that configuration. For example, an assessor might ask a test account to set a password that breaks the rule and confirm the system refuses it. The configuration evidence proves the rule exists and is applied to the right scope, while the test of one proves it works in practice.
- Configuration exports: Capture the policy as the system stores it, such as a directory password policy export or an identity provider setting, with the date and the system name visible.
- Scope of the setting: Show which accounts, groups or environments the rule applies to, so the assessor can see that the enforced scope matches the scope of the requirement.
- A reproducible test case: Write down the exact steps, the test account used, the input attempted and the expected result, so anyone can repeat the test on the same day.
- Dated screenshots or logs: Record the blocked attempt with a timestamp that falls within fieldwork, and keep the log entry that shows the refusal.
- Named control owner: Identify the person who manages the configuration and can explain changes, since the assessor may ask who approves them.
Before fieldwork, confirm the configuration did not change in a way that invalidates your evidence, and ask your assessor which exports they will accept as is.
Controls performed by people or on a schedule, such as access reviews, change approvals, vendor reviews or backup restores, cannot be proven by a single demonstration. The assessor selects a sample of occurrences from the population of times the control ran during the sampling period and checks each one against the control's requirements. The result depends on whether the population is complete and whether the sampled items actually show the control operating. Sample sizes and periods are set by HITRUST's minimum sample rules, and the assessor may take more samples under its own method but not fewer.
- Complete populations: Export every occurrence in the sampling period, such as all change tickets or all joiner records, and show how the export was generated.
- Evidence per occurrence: For each item, keep the approval, the reviewer's sign-off and the artifact the reviewer examined, all dated.
- Consistent process and owner: If one control spans several tools, confirm the same process and control owner apply to each, so the population is treated as one control.
- Records for periods without activity: If a control did not run, keep records that explain why, such as HR or change logs, because the assessor will look beyond inquiry before scoring it as implemented.
- Prepared walkthrough: Be ready to show the control operating from start to finish, including who triggers it and where the record is stored.
Before fieldwork, ask your assessor how they will select samples from your population and whether they need the full export or a sampling frame.
Many requirements combine both types. A recurring review might depend on an automated report that a system produces, or an automated alert might need a human to act on it. In those cases the assessor tests the automated part through configuration and a test of one, and tests the human part through sampled occurrences. Treating the whole requirement as one type is a common source of gaps, because the evidence for each half is different.
- Split the requirement: Separate the automated element, such as an alert rule, from the recurring element, such as the review of alerts, and list the evidence for each.
- Trace the link: Show how an alert or report feeds into the recurring review, with the same identifiers appearing in both records.
- Keep the report generation logic: Document the query or setting that produced the report, since the assessor may test whether the report is complete.
- Avoid mixed populations: Do not combine a configuration export with a list of human actions in one sample, because they cannot reveal the same errors.
- Cross-check dates: Confirm that both the automated test and the sampled occurrences fall within the fieldwork period and the sampling period.
Before fieldwork, map each requirement to its automated and manual parts so you know which exports and which samples you need to prepare.
Why a population that cannot reveal errors fails testing
HITRUST assessors do not only check the samples they receive, they check where those samples came from. The rules below describe the population defects that most often cause a control to fail testing, and what to change before fieldwork starts.
Coverage samples must come from elsewhere
A sample meant to prove anti-virus coverage cannot be drawn from the anti-virus console itself, because the console only lists the devices it already knows about. A device that never reported in would be invisible. To fix this, build the population from an independent source such as the asset inventory, directory or endpoint management records, then confirm each sampled device against the protection tool. Ask the assessor which source they will accept before you draw the sample.
One process and one owner
When a single control spans several tools, the populations can be combined only if every tool runs the same process and has the same control owner. Two ticketing systems managed by different teams with different approval steps should be tested as two populations. Combining them hides the gaps in whichever process is weaker. Document the owner, the procedure and the tools in the control description before you extract any data.
Draw from the full population
A sample taken from a subset, such as only the production servers or only the most recent month of changes, cannot show what the control did across the whole environment. Assessors will ask how the population was defined and whether any items were excluded. Keep the extraction query, its run date and its filters, and make sure exclusions are justified in writing, for example by a documented scope decision.
Complete and traceable records
A population must include every item that could have failed the control, and each item must trace back to a source record. Gaps often come from exports that drop deleted accounts, terminated staff or cancelled changes. Reconcile the population count against a second system of record, such as the HR roster or the change system, and keep the reconciliation as evidence. Ask whether the assessor expects a system-generated report with a timestamp.
No pre-selection or early sharing
Item-based populations may be generated up to 30 days before fieldwork, but samples drawn from them may not be shared with the entity before fieldwork begins. Choosing items in advance so that they look compliant defeats the purpose of sampling. Let the assessor select the samples from the population you provide, and agree in writing when the population file will be released.
Evidence within fieldwork dates
Evidence must fall within the period under test and within the fieldwork window, and time-based populations must cover at least 90 days. A backup log from outside the sampling period, or a change ticket dated after fieldwork closed, cannot support the result. Check the date range of every extract against the sampling period before you submit it, and keep the export parameters so the dates can be verified.
Zero-occurrence controls and minimum sample sizes
A control that did not run in the year before fieldwork cannot be closed on the assessed party's word alone. If a control produced no occurrences, the assessor must corroborate that non-occurrence with more than inquiry before awarding the full Implemented score. Interviewing the control owner and recording the answer is not enough. The assessor needs an independent record, such as a change log showing no changes went through a process, or an HR system extract showing no joiners, movers or leavers in the period. Start by listing every control in scope that is event-driven, such as change approvals, access reviews triggered by role changes, or incident-related reviews. For each one, identify which system holds a record that would prove the event did or did not happen, and confirm that the record can be exported with dates and is retained for the full look-back period.
Sample sizes are the second point to settle early. External Assessors may draw more samples than HITRUST's minimums, but they may not draw fewer, and they must document the probability sampling method they use. Ask each candidate assessor for its written sampling methodology before you sign, and check how it handles populations of different sizes and how it treats an exception found in a sample. Confirm the current minimum sample sizes directly in the version of the HITRUST Assessment Handbook in force for your assessment, because the minimums are not something to rely on from memory or from an older project. Also ask whether the assessor's sampling depth changes if your control population is small, since a small population can make a large sample a larger share of your evidence burden than the assessor's standard approach implies.
How sampling fits into the validated assessment timeline
The sequence shows how populations are defined, generated, evidenced and sampled before the assessor tests them, so that each sample can be traced back to a fixed period and a documented source. Each step ends with an output that the organization or the External Assessor hands to the next party.
Define each population and its sampling period
The control owner and the assessment lead agree which populations each requirement uses, such as a list of assets, a set of change tickets, joiners and leavers, or backup jobs. For each time-based population, the period must cover at least 90 days and may not start more than one year before fieldwork begins. The output is a population register that names the source system, the control owner and the period for every population, and the register is reviewed before any data is pulled.
Generate item-based lists inside the 30-day window
Item-based populations, such as asset inventories or employee lists, may be generated up to 30 days before fieldwork starts. The organization exports each list from the system of record, records the export date and the query used, and keeps the native file unchanged. The output is a dated, signed-off population file. Samples drawn from it must not be shared with the organization before fieldwork starts, so the assessor should control the selection step.
Confirm each population can reveal errors
Before collection begins, the team checks that each population could show a control failure. A coverage sample cannot be drawn from the tool that measures coverage, and populations combined across several tools must follow the same process and have the same control owner. Where a population fails this check, the team changes the source or adds a second source. The output is a short population rationale for each requirement that the assessor can review.
Collect time-based evidence across the full period
The organization gathers evidence for the whole sampling period, such as backup logs, change records or HR events, and keeps the native exports with timestamps. For automated controls, it also collects the system configuration and prepares a test of one that shows the system enforces the rule, such as a blocked non-compliant password. Where a control did not run in the year before fieldwork, the assessor will look for corroboration beyond inquiry, such as a change log or HR system record. The output is a complete evidence set indexed by population and date.
Select samples and test them during fieldwork
The External Assessor selects samples using its own probability method, which may exceed HITRUST's minimum sample sizes but may not fall below them, and documents that method. The assessor then tests each sample against the requirement and conducts walkthroughs of the control environment. Fieldwork runs for at most 90 days. The output is a set of workpapers showing the selection method, the samples, the tests performed and the result for each requirement.
Resolve exceptions and reperform internal testing
Where the organization or its internal assessors tested samples first, the External Assessor must reperform at least 20% of those samples and must still lead or take part in walkthroughs. Exceptions identified during testing go back to the control owner for explanation or remediation evidence, and the assessor records each one. The output is a reconciled exception log that shows which samples were rechecked and how each open exception was resolved or carried into scoring.
Submit the assessment for HITRUST quality assurance
The External Assessor prepares the validated assessment report and submits it for HITRUST central quality assurance before any certification is issued. HITRUST reviews the sampling documentation and evidence against its rules, and may return questions to the assessor. The organization should confirm with its assessor which sampling records HITRUST will expect to see. The output is a QA-cleared validated assessment report, or a documented list of QA follow-up items that the assessor and organization must answer.
When internal sample testing counts and what the assessor must reperform
An External Assessor can lean on sample testing that the organization's internal assessor has already performed, but that reliance has limits. The cards below cover how much the assessor must redo, what must still happen in person, and what the organization should keep so the reperformance goes smoothly.
The 20% reperformance floor
When an External Assessor relies on internal assessor sample testing, it must reperform at least 20% of those samples itself. The assessor chooses which samples to redo, so the organization should not assume it will be the ones it already checked. Every internal sample should be treated as one the assessor could pull for independent retesting.
Walkthroughs stay with the assessor
Reliance on internal testing does not remove the External Assessor's role in the control environment. The assessor must still lead or take part in walkthroughs of the controls. Organizations should schedule these walkthroughs with control owners early and confirm who from the assessor's team will attend.
Keep a complete sample log
An internal sample log should record the population used, the date it was generated, the selection method, each sample picked, and the result of each test. Without this record, reperformance becomes a slow reconstruction. Ask the assessor early which log format it expects, so internal testing produces what it can use.
Document how samples were selected
Reperformance depends on the assessor understanding why a sample was chosen. The organization should write down the selection method and the probability approach used, and confirm the population can reveal errors. A sample drawn from the tool that generates the data is a common reason an assessor will reject the test.
Keep evidence ready for redoing
The assessor will need to pull the same evidence the internal tester used, so systems and records must still be retrievable in their original form. Logs, tickets and approvals should be kept with their original timestamps and access controls. Missing or altered source records force the assessor to mark the sample as unsupported.
Confirm reliance terms before testing
Whether the assessor will rely on internal sample testing, and under what conditions, should be agreed before fieldwork begins. Internal testers should not be treated as independent evaluators of their own controls. Confirm the reliance approach in writing with the External Assessor so the internal work is scoped to what it can support.
HITRUST sampling questions buyers and compliance leads ask
How many samples will a HITRUST assessor take?
HITRUST sets minimum sample sizes, and the External Assessor firm chooses the actual number, which may be higher but may not be lower than HITRUST's minimums. The assessor documents the probability sampling method it uses, so the number depends on the control, the population size and the firm's own methodology. Because HITRUST can update these figures between versions, confirm the current minimums in the HITRUST Assessment Handbook and ask your assessor to state its sampling approach in writing before fieldwork starts. Expect the assessor to draw samples from populations you provide, so the population list is the first thing to get right.
Can our internal team run the sampling ourselves?
Yes, your internal team can perform sample testing as part of its own preparation, and the External Assessor may rely on that work. Reliance has limits, though. The External Assessor must reperform at least 20% of the samples and must still lead or take part in the walkthroughs of the control environment. Internal testing therefore reduces assessor effort and surfaces gaps early, but it does not replace the assessor's independent testing. Ask your assessor early which internal test records it will accept and in what format.
What drives the effort of sample testing?
Effort rises with the number of tools, control owners and time-based populations in scope. Each tool that produces a population may need its own extraction, validation and evidence trail, and populations combined across tools must follow the same process and control owner. Time-based populations such as backups, change tickets or joiners and leavers must cover at least 90 days, which means more records to pull and check. Consolidating systems, standardizing ticketing and keeping logs exportable all reduce the work. Ask any partner to quote by population count, tool count and control owner, not by a single flat figure.
Who owns the sampling populations during a HITRUST assessment?
The organization owns its populations and is accountable for their completeness and accuracy. Item-based populations, such as asset or employee lists, may be generated up to 30 days before fieldwork, but samples drawn from them may not be shared with the entity before fieldwork starts. That rule means the assessor selects samples, and your team must not see the selection in advance. Your team owns the source systems, the extraction method and the proof that the population is complete. An implementation partner can help prepare these exports, but the population and its integrity remain your responsibility.
What can an implementation partner prepare for sampling?
A partner can prepare the populations, the evidence and the test records that the assessor will examine. In practice this includes configuring logging and ticketing so records are complete, building repeatable extraction queries, documenting how each population is generated, and organizing test records by control and maturity level. An implementation partner does not issue the HITRUST report, does not select the samples on the assessor's behalf, and does not certify anything. Only an Authorized HITRUST External Assessor organization performs the validated assessment, and HITRUST performs central quality assurance before issuing reports.
What causes a sample to be rejected in HITRUST testing?
The most common cause is a population that cannot reveal errors. For example, an anti-virus coverage sample cannot come from the anti-virus console itself, because a console-generated list will not show the endpoints it missed. Other rejections involve time-based samples that fall outside the sampling period, populations assembled from tools that follow different processes, and evidence that is dated outside fieldwork. For automated controls, a configuration screenshot alone is not enough, so the test should include a test of one showing the system enforces the setting. Review each population against the question it is meant to answer before the assessor sees it.
Does a control that did not run last year still get sampled?
If a control did not run in the year before fieldwork, the assessor cannot award the full Implemented score on inquiry alone. The assessor must corroborate the non-occurrence with more than an interview, such as reviewing the change log or the HR system. Plan for this in advance by keeping system records that show when a control ran or did not need to run. Where a control is new or was fixed recently, the incubation rules also apply, so confirm with your assessor how the timing interacts with your fieldwork window.
How DeployOpen prepares populations and evidence for your assessor
DeployOpen prepares the systems, controls and evidence that HITRUST sampling depends on, inside your own infrastructure. We build populations that can reveal errors and documentation your External Assessor can test, while your organization keeps ownership of its controls and the assessor issues any report.
How we scope
- Engagements are fixed-scope, with populations, deliverables and timelines agreed in writing before work starts.
- We map each in-scope control to its population type, whether time-based or item-based, and its sampling period.
- We confirm with your assessor which tools, owners and processes feed each population before any data is pulled.
How we build
- We configure populations from the systems of record so that anti-virus, access and change data come from sources independent of the control being tested.
- We set up automated controls so configuration evidence and a test of one, such as a blocked non-compliant password, can be shown.
- We prepare populations that draw on one process and one control owner, so combined sources stay consistent across tools.
How we hand over
- We document how each population was generated, its date range, its source system and the steps taken to produce it.
- We deliver evidence packages mapped to each requirement and sampling period, ready for your assessor to select from.
- We record any control that did not run in the prior year so the supporting corroboration is available to the assessor.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial work is complete.
- Retainer support can refresh populations and evidence ahead of fieldwork so sampling periods stay within the required windows.
- Ask your assessor to confirm sampling methodology and minimum sample sizes before we finalize populations.
