In HITRUST, illustrative procedures are not optional examples; they define exactly how assessors test your controls. Miss one evaluative element and your score can drop an entire tier.
How Assessors Think and Why it Matters
HITRUST scoring has two distinct layers that practitioners often conflate. Understanding the difference is the single most important step in evidence preparation.
Requirement statements are scored by evaluative elements. Your final score for any given control is determined by how many elements you satisfy (coverage) and, at the Implemented maturity level, how broadly those elements operate across your scoped population (implementation strength).
Scope note: The scoring examples in this post reflect i1 assessment logic, where only the Implemented maturity level is evaluated. In r2 assessments, element coverage at the Implemented level is one component of a five-level weighted maturity score; the same gap will carry a different weight depending on performance across the other four levels.
Illustrative procedures define the test plan. They outline exactly what assessors inspect and what evidence is sufficient, including where sample-based testing is required. Treating them as optional guidance is one of the most common and costly mistakes organizations make.
Key principle
Build your evidence package directly against the illustrative procedures. If the procedures say “select a sample,” assessors are expected to perform sample-based testing, and your population must come from an independent source.
Example
ISMP
Assessment Type: i1 | BUID: 0101.00a1 Organizational.123
Your Information Security Management Program (ISMP) must satisfy six evaluative elements. Sampling is not required for this control.
The six elements of an ISMP:
- It must be documented
- Approved by management
- Based on an accepted framework
- Covers all framework control objectives
- Has exclusions documented with rationale
- Is updated at least annually or upon significant change
Assessors Review Actions
- Obtain the ISMP and verify the framework basis (ISO, NIST, or equivalent)
- Confirm coverage of all control objectives, with exclusions and rationale recorded
- Inspect management approval via dated signatures or committee meeting minutes
- Verify annual or significant-change updates through version history or a change log
Evidence that passes
ISMP document — Current version, owner, and scope clearly identified
Approval record — E-signature page or committee minutes with date
Framework mapping — Table showing all control objectives considered
Exclusions register — Each exclusion listed with documented reason
Revision history — Demonstrates annual reviews and post-significant-change updates
Scoring nuance
With 6 elements, missing just one yields 5/6 = 83%, which scores as Mostly Compliant rather than Fully Compliant. Scoring bands are fixed by the rubric; effort does not compensate for a missing element.
Note: This example assumes Tier 4 implementation strength, meaning the control operates across the full in-scope population. Where implementation is uneven across systems or locations, the strength dimension of the rubric must also be evaluated before a final rating can be determined.
Example
Mobile code / Anti-malware
Assessment Type: i1 | BUID: 0226.09k1 Organizational.2
This control has two evaluative elements and requires sample-based testing, a critical distinction from the ISMP control above.
Element 1: The organization implements mobile-code protection, including anti-virus and anti-spyware.
Element 2: Protection is regularly updated, with definition files set to auto-download and push to clients.
Critical sampling rule
Never build the testing population from the AV or EDR console, it excludes unmanaged devices and biases results. Use an independent source such as your CMDB, asset inventory, or MDM system, and document your method, dates, and sample size.
Step-by-step testing guide
- Define the population. Include all in-scope endpoints: workstations, servers, VDI, and BYOD where supported. Document the source and date range.
- Select the sample. Use a random method; record your rationale and counts. Attach a testing lead sheet listing attributes to test.
- Test Element 1 — Implements. For each sampled endpoint, confirm the agent is installed and running with real-time protections that cover mobile code (status page, service status, real-time protection toggle).
- Test Element 2 — Regularly updates. Show definition and engine currency per sampled endpoint, plus evidence of auto-download/push (policy screenshot, console job logs, on-connect catch-up behavior).
- Handle BYOD and exceptions. Include BYOD in the sample where supported. For servers where host AV is not vendor-recommended, document your alternate detection in related controls (e.g., network-based detection).
- Archive working papers. Per device: agent status, last update, screenshots with date and timestamp. Include exception tickets for any out-of-date systems.
Evidence that Passes
E1 — Implemented: Console inventory or endpoint screenshots showing the agent installed, the service running, and mobile-code protections active (real-time, web, and script scanning where supported).
E2 — Regularly updates: Policy or config showing auto-download and push; per-endpoint definition version with timestamp; proof of update delivery (distribution job results or telemetry).
Scoring reality
With 2 elements, satisfying only one yields 1/2 = 50%, which results in Partially Compliant. Both elements are required for Fully Compliant, subject to implementation strength across the scoped population.
Common Pitfalls and Quick Fixes
Treating illustrative procedures as optional guidance
Fix: Align your evidence preparation directly to the procedures — they set assessor testing expectations.
Sampling from the tool being tested (e.g., pulling the AV population from the AV console)
Fix: Build the population from an independent source (CMDB, MDM, asset inventory) and document your method and dates.
Over-relying on inheritance to claim coverage
Fix: Partial inheritance is not full coverage, show your side of any shared responsibility clearly.
Submitting narrative summaries instead of element-mapped evidence
Fix: Map each artifact to a specific evaluative element. “We did a lot” does not raise a score. The rubric bands are determined by element coverage, not by effort.
