Which HITRUST maturity levels does each assessment score?
The e1 and i1 score only the Implemented level, while the r2 scores Policy, Procedure and Implemented, with Measured and Managed optional. If a customer or contract has just started asking for HITRUST, the budget owner needs to know that the level a score depends on is set by the assessment type, not by the organization's preferences. Each e1 and i1 domain's core statements must average at least 83, and each r2 domain must average at least 62. Your organization owns its controls and decides how they are designed, documented and run. Only an independent HITRUST External Assessor scores them against the maturity model, and HITRUST performs quality assurance before any report is issued. Your readiness work should therefore be aimed at producing evidence the assessor can score, not at demonstrating controls that exist only in practice.
For an e1 or i1, the question is whether each requirement is implemented and can be shown to operate. A written policy or procedure does not raise the score on those assessments, so effort spent polishing documents for them has little scoring value. For an r2, the assessor also reads the documents: a current policy must state each requirement's elements as mandatory across all in-scope facilities and systems, and procedures must be detailed enough for a qualified person to carry out every element. Ask your consultant or assessor which evidence they will accept for each level before you commit staff time to a specific form of documentation.
Measured and Managed are optional in an r2, so decide whether to score them before fieldwork starts. Scoring them adds requirements: measures need defined frequencies, owners and thresholds, and the Managed level cannot exceed the coverage the measures already provide. Confirm with your assessor whether your r2 scope includes these levels, and check whether the evidence you already gather, such as monitoring reports and review records, can support them. The level that matters is the one your assessment type scores and the evidence your organization can actually produce and sustain.
What each maturity level asks for in plain terms
HITRUST scores each requirement statement against a maturity ladder, and every level assumes the one below it is already in place. The cards below describe what an assessor looks for at each rung and which assessments score that rung, so you can see where your evidence is likely to be strong or thin before fieldwork begins.
Policy
The assessor first checks for a current, documented policy that states the requirement's elements as mandatory. The policy must cover every in-scope facility and system, not just the headquarters or the flagship product. Check that the wording is directive (the organization must do this) rather than advisory, that it has an owner and approval date, and that it matches what your teams actually run. Scored in the r2 only.
Procedure
Procedures explain how people carry out each element of the policy. The test is whether a qualified person who did not write the procedure could perform the task correctly from the document alone. Look for named tools, steps, roles and handoffs, not general intent. A common gap is a policy that promises quarterly reviews with no procedure saying who runs them or where the output is stored. Scored in the r2 only.
Implemented
Implementation asks whether the control is operating in the environment, not just written down. The assessor samples systems and people and looks for configuration, tickets, logs or approvals that show the control ran during the assessment period. This is the only maturity level the e1 and i1 score, so it carries the full weight of those assessments. Scored in the e1, i1 and r2.
Measured
Measured asks whether the organization tracks how well a control performs. A measure needs a defined frequency, a named data source, a calculation method, a named reviewer and a review at least every 12 months. A metric also needs history over time and explicit thresholds or targets. Ask your team whether each measure would survive a question about who gathers the data and what happens when the number is bad. Optional in the r2.
Managed
Managed asks whether issues surfaced by measures go through a documented risk treatment process with management involvement, tracked remediation and a weighing of cost, risk and mission impact. The score cannot exceed the Measured coverage beneath it, so weak measures cap this level. Confirm that decisions are recorded, including decisions to accept risk, and that someone outside the operating team signs them off. Optional in the r2.
Which levels the e1, i1 and r2 score and what they require
This table compares the e1, i1 and r2 by the maturity levels they score, the domain average each needs to pass and the organizations each assessment usually fits. Read it as a starting point: the scoring rules set the bar, but your assessor applies the baseline in the CSF version you are assessed against.
| Dimension | e1 | i1 | r2 |
|---|---|---|---|
| Maturity levels scored | Implemented only | Implemented only | Policy, Procedure and Implemented, with Measured and Managed optional |
| What Implemented asks for | Controls operating in practice across the in-scope environment | Controls operating in practice across the in-scope environment | Controls operating in practice, supported by documented policy and procedure |
| Required domain average | Core statements average at least 83 per domain | Core statements average at least 83 per domain | Each domain averages at least 62 |
| Measured and Managed | Not scored | Not scored | Optional, scored only if the organization elects it |
| Typical fit | Organizations starting a HITRUST path with a baseline of practical controls | Organizations that need a stronger, still threat-adaptive baseline than e1 | Organizations that need a full, risk-based assessment for regulated or high-volume customer data |
| Confirm before you start | Current requirement count and baseline in your CSF version | Current requirement count and baseline in your CSF version | Current tailoring options and scoring thresholds in your CSF version |
What the Policy and Procedure levels ask for before anything is tested
The Policy and Procedure levels are the first two maturity levels HITRUST scores on an r2, and they are judged on paper before an assessor looks at any system. At the Policy level, the organization needs a current, documented policy that states each element of the requirement as mandatory and covers every in-scope facility and system. At the Procedure level, documented procedures must explain how to perform every element in enough detail that a qualified person could carry it out without asking the author. The organization writes, approves and owns these documents. An implementation partner can draft them and align the wording to the systems in scope, but the partner does not decide what the organization's policy says or sign it off.
The most common gap at the Policy level is a policy that exists but does not name the systems it covers. A document that says all systems must enforce multifactor authentication gives an assessor nothing to test against. Before drafting, list every in-scope facility, cloud account, application and administrative tool, then check that each policy names those assets or points to a maintained inventory that does. Confirm the approval date, the approver and the review cycle as well, since an assessor tests whether the document is current and approved.
The assessor's role at these levels is narrow. It tests whether the policies and procedures are current, approved and matched to how the environment actually runs, using interviews, configuration samples and tickets. A procedure that describes a process nobody follows scores poorly even when it is well written. Before fieldwork, walk one procedure per requirement against a real change or access event and record any step that differs from the document. Either update the document or change the practice, and keep a dated record of the change, because the assessor will ask which came first.
Should you score Measured and Managed in an r2?
When the team is still writing its policies and procedures, scoring Measured and Managed usually adds work before the foundation is stable. The r2 already scores Policy, Procedure and Implemented maturity, and those levels absorb most of the effort in a first assessment. Adding the optional levels means the organization must also show measures and metrics that run over time, and a risk treatment process that acts on what those measures find. Teams in this position often find that the core levels need enough time to settle before the monitoring layer has anything meaningful to show.
- Foundation first: Confirm that current, approved policies and procedures exist for each in-scope requirement before deciding on the optional levels.
- Measures need history: A metric must track results over time with explicit thresholds or targets, so a newly launched measure cannot show that history yet.
- Managed depends on Measured: The Managed score cannot exceed Measured coverage, so weak measures cap the value of any risk treatment work.
- Ownership and review: Each measure needs a named gatherer and reviewer, reviewed at least every 12 months, which new teams often have not assigned.
- Deferral is common: Leaving the optional levels out of the first r2 keeps the scope manageable, and the decision can be revisited at the interim assessment.
Before committing, ask your assessor and any customer contract whether Measured or Managed scoring is required, and confirm the effort with your assessor in writing.
Some customers ask for evidence of ongoing monitoring rather than a snapshot of controls on the assessment date. Scoring Measured and Managed can answer that request directly, because it shows that the organization collects data on control performance, reviews it and acts on issues. The added value depends on whether the customer's question is about monitoring design or about verifiable results. Read the contract language closely, since a request for monitoring evidence may be satisfied by reporting, operational dashboards or a shared responsibility arrangement without optional scoring.
- What scoring adds: Measured scoring tests whether defined measures, frequencies and reviewers exist and produce results, rather than only whether a procedure says monitoring happens.
- Extra evidence required: Expect measure definitions, recorded calculations, review records at least every 12 months, and metric trends with thresholds.
- Managed adds treatment: Managed scoring looks for documented risk treatment, management involvement, issue tracking and weighing of cost, risk and mission impact.
- Scope mismatch risk: Customers often ask about monitoring for systems that sit outside the r2 scope, which optional scoring will not cover.
- Ask for the exact requirement: Confirm whether the customer wants a scored Measured or Managed level, or simply evidence that monitoring exists.
Before scoring these levels for a customer, check the contract wording and confirm with the assessor and the customer what evidence will be accepted.
An organization that already runs metrics and a risk treatment process is in the strongest position to score the optional levels. The work shifts from building monitoring to proving that the existing program meets the level definitions. The main risk in a renewal is assuming that routine operational reporting equals a scored Measured level. Assessors test the specific elements of each measure, so a mature program can still leave gaps if its documentation does not match what it actually does.
- Gap check against definitions: Compare each existing measure with the required elements, including control, frequency, data, collector, calculation, recording and reviewer.
- Thresholds and trends: Confirm that metrics track results over time and that targets or thresholds are explicit and approved.
- Treatment records: Managed scoring needs issues tracked through a documented process with management involvement, so keep decision records and cost, risk and mission impact notes.
- Consistency across scope: Measures must cover the in-scope facilities and systems the assessment claims, not only the most mature environment.
- Interim planning: Consider how the r2 interim assessment will test the same measures, since a renewal should not leave them untested for two years.
Before deciding, run a pre-assessment review of existing measures with your assessor and make the scoring choice in writing alongside the contract requirements.
What makes a measure count at the Measured and Managed levels
A measure counts at the Measured level only when the record shows what it tests, and the record is the thing an assessor reads. For each measure, the organization should be able to state which control it tests, how often it runs, what data it gathers, who gathers that data, how the result is recorded and calculated, and who reviews it. HITRUST expects that review to happen at least every 12 months. A metric goes a step further: it needs to be tracked over time, and it needs explicit thresholds or targets so that a reader can tell whether a result is acceptable. A dashboard that shows a number with no target does not meet this test. Confirm the exact evidence expectations against the Assessment Handbook before you design the measure set, since the handbook is the controlling text.
The Managed level asks what happens after a measure finds a problem. An assessor looks for a documented risk treatment process in which management takes part, issues found by measures are logged and tracked to closure, and each treatment decision weighs cost, risk and mission impact. The organization must produce these records itself: the minutes of the risk review, the issue register entries, the decision to accept, mitigate or transfer, and the follow-up showing the fix. Tooling such as a SIEM, a vulnerability scanner or a ticketing system can collect the data and track the workflow, but it cannot make the judgment about which risk to accept. Managed coverage can never score higher than Measured coverage, so a team with strong treatment records but weak measures will gain nothing at the Managed level.
How to check each maturity level before the assessor arrives
This sequence lets an internal compliance lead test each requirement against the maturity level the assessor will score, so gaps surface while there is still time to fix them. The output is a set of evidence files and a documented decision on what is ready, what is not, and what remains open.
Inventory every policy and confirm its status
The compliance lead lists every policy that maps to an in-scope requirement statement, then checks each one for three things: it is current, it is documented, and it states the requirement's elements as mandatory. Owners of each policy confirm the review date and the approver, and the lead flags any policy that is a draft, lacks an owner, or uses advisory language such as should or may where the requirement calls for a firm rule. The output is a policy register with one row per requirement statement, the policy that covers it, its approval date, and a pass or fix status. The check is complete when every in-scope statement has a named, approved policy that the lead has read against the requirement's elements.
Confirm procedures work for a qualified person
For each policy, the lead checks that a documented procedure explains how to perform every element in enough detail that a qualified person who has not done the task before could carry it out. The lead asks a system owner or an engineer outside the compliance team to walk through one procedure and report where they had to guess. Gaps usually appear as steps that name a tool without the settings, or a review that names no reviewer or record. The output is a procedure register that links each procedure to its policy and records the walkthrough result. The check is complete when each procedure has been tested by someone who did not write it and the lead has closed or logged every point where they got stuck.
Collect implementation evidence for each in-scope system
The lead lists every in-scope facility and system, then gathers evidence that each requirement is actually operating on each one, not only in the policy. Typical evidence includes configuration exports, access lists, scan results, ticket records, change approvals and logs that show the control ran in the period. The lead matches evidence to system, so a control that holds on production but not on a backup environment or a branch site shows up as a gap. The output is an evidence index keyed by requirement statement and system, with the date and location of each item. The check is complete when every in-scope system has evidence for every applicable statement, or a documented reason it does not apply.
Decide which optional levels the assessment will score
Before building measures, the lead confirms with the assessor and the assessment scope whether Measured and Managed will be scored. HITRUST scores the Measured and Managed levels in an r2 only if the organization chooses to, and the e1 and i1 score only the Implemented level. This decision sets how much work follows in the next two steps. The output is a written scoping note that names the levels in scope for each requirement and the reason for the choice. The check is complete when the note is signed off by the accountable owner and the assessor has confirmed it in writing.
Build measures with owners, frequency and thresholds
Where Measured is scored, the lead defines a measure for each control that states what the control is, how often it runs, what data is measured, who gathers it, how the result is recorded and calculated, and who reviews it at least every 12 months. Metrics also need a history that shows change over time and an explicit threshold or target that someone can compare against. A measure without a named reviewer or threshold will not count, even if the team collects the data. The output is a measure catalog with a definition sheet for each measure and a first set of results. The check is complete when each measure has a named owner, a calculation method, a target, and at least one recorded review.
Record a risk treatment process for measured issues
Where Managed is scored, the lead confirms that issues found by measures move through a documented risk treatment process. The process needs management involvement, issue tracking from identification to closure, and a documented weighing of cost, risk and mission impact for each decision. The lead pulls a sample of real issues from the measure results and checks that each one has a ticket, an owner, a decision and a closure record. The output is a risk treatment register with the decision trail for each issue and the management approvals that support it. The check is complete when the lead can show, for each measured issue, how it was tracked and decided, and when no measured issue has been left without a recorded outcome.
Hand over a readiness file and confirm ownership
The lead assembles the policy register, procedure register, evidence index, scoping note, measure catalog and risk treatment register into a single readiness file and reviews it with each control owner. Each owner confirms in writing that the content describes what their team actually does. An implementation partner can run these steps, build the registers, and prepare the evidence, but the organization owns the result, the decisions and the statements it makes to the assessor. The output is a signed readiness file with an open-items list. The check is complete when every open item has an owner and the accountable executive has accepted the file.
Why maturity scores drop at assessment and how to prevent each
Most maturity shortfalls in a HITRUST assessment come from documentation and evidence that exist but do not meet the scoring bar. The cards below cover the five causes assessors see most often, each tied to the level it weakens and the check that catches it before fieldwork begins.
Policies that leave elements optional
A policy that describes intent but does not state each element of the requirement as mandatory fails the Policy level, even when the team follows it in practice. Assessors look for mandatory language and scope that covers every in-scope facility and system. Before fieldwork, map each requirement statement to a policy clause and confirm the clause uses required wording, is current, and names the systems it governs. This affects the Policy level.
Procedures that skip steps
A procedure scores at the Procedure level only when a qualified person could carry out every element from the document alone. Runbooks that name a task without its inputs, owners, commands or decision points leave gaps that assessors flag. Test each procedure by handing it to someone outside the team and asking whether they could complete it unaided. This affects the Procedure level.
Implementation evidence that covers part of scope
Evidence from one environment, one cluster or one quarter does not show that a control operates across all in-scope systems. Assessors sample across scope items, so a configuration screenshot from a single host can leave the rest uncovered. Build an evidence index that lists each in-scope system against each control and records where its proof lives. This affects the Implemented level.
Measures without thresholds or reviewers
A measure counts at the Measured level only when it records the control, frequency, data source, who gathers it, how it is calculated, and who reviews it at least every 12 months. Metrics also need trend history and explicit targets. A dashboard that is viewed but has no named reviewer, threshold or recorded review fails this test. Assign an owner and a target to each measure, and file the review record each cycle. This affects the Measured level.
Managed claims without a risk treatment record
The Managed level asks whether issues surfaced by measures move through a documented risk treatment process with management involvement, issue tracking, and weighing of cost, risk and mission impact. A claim without those records cannot score, and its score cannot exceed the Measured coverage beneath it. Keep a log that links each measure finding to a decision, an approver and a closure date. This affects the Managed level, which is optional in an r2.
Frequently asked questions about HITRUST maturity levels
Does the e1 score more than Implemented?
No. The e1 scores only the Implemented maturity level. The i1 also scores only Implemented, so neither assessment asks for documented policy or procedure credit in the scoring itself. The r2 is different: it scores Policy, Procedure and Implemented, and Measured and Managed are optional add-ons within the r2. Each requirement statement is rated on HITRUST's scoring rubric, and the assessor and HITRUST issue the final score and report. Confirm the scoring levels for your assessment type in the HITRUST Assessment Handbook before you plan the work, since the levels differ between e1, i1 and r2.
Does an r2 have to score Measured and Managed?
No. Scoring Measured and Managed in an r2 is optional under HITRUST's approach. The r2 always scores Policy, Procedure and Implemented, so a team that skips the optional levels still gets a validated r2 if it meets the required thresholds. Choosing to score the higher levels adds measurement and risk treatment work, and it should be a deliberate decision made with your assessor and leadership. Ask your assessor to confirm how optional levels are reflected in your scope before committing to them.
How much extra effort does the Measured level add?
The effort depends on how many measures you already run and how well they are documented. A measure counts at the Measured level only when it describes the control, its frequency, the data gathered, who gathers it, how it is recorded and calculated, and who reviews it at least every 12 months. Metrics also need to be tracked over time and tied to explicit thresholds or targets. Teams with existing dashboards often need to document ownership and calculation methods, while teams without them must build the collection process first. Ask your implementation partner to estimate effort per requirement in a written scope rather than relying on a general figure.
Can our own team do the maturity work without outside help?
Yes, many organizations prepare their policies, procedures and evidence in house, and HITRUST does not require an outside consultant. Outside help is usually most useful for gap analysis, reviewing whether procedures are detailed enough for a qualified person to follow, and designing measures that meet the Measured criteria. Remember that an independent External Assessor must perform the validated assessment, and that the organization owns its controls. An implementation partner can prepare systems and evidence, but only the assessor and HITRUST issue the score and report.
What does the work need from the compliance lead and system owners?
The compliance lead coordinates scope, owns the policy set and tracks each requirement statement to its evidence. System owners document how their platforms perform each control, keep configuration and access records current, and explain how their measures are gathered and reviewed. Ask each group to confirm which systems and facilities fall in scope, because a policy must cover all in-scope facilities and systems to earn Policy credit. Clear ownership written into the procedures makes the assessor's testing faster and reduces rework.
How long does preparation take in general terms?
Preparation time depends on how mature your existing policies and controls already are, how many systems are in scope, and whether measures exist yet. Teams with documented policies and running monitoring usually need less time than teams building procedures and metrics from scratch. The fieldwork window for the validated assessment is limited, so most of the time goes into readiness work beforehand. Ask your advisor for a timeline in the written scope that lists each stage, the owners and the evidence each stage will produce.
Does a policy alone earn Policy credit?
No. A current, documented policy earns Policy credit only when it states the requirement's elements as mandatory and covers all in-scope facilities and systems. Policy credit also depends on the policy being in effect and approved, not merely written. The policy must still be backed by procedures that explain how to perform every element in enough detail for a qualified person, and by implementation evidence at the Implemented level. A policy with no matching procedure or operating evidence will not carry the requirement.
Who makes the final scoring decision?
The independent External Assessor scores the requirement statements during the validated assessment, and HITRUST performs central quality assurance before it issues the report. The organization does not assign its own final score, and neither does the implementation partner. Your team can review the assessor's reasoning, provide additional evidence within the assessment process, and plan corrective actions where a gap appears. Only HITRUST issues the certification that follows a successful assessment.
How DeployOpen works on this
DeployOpen helps organizations build the systems, documented policies, procedures and measurable evidence that a HITRUST assessor reviews when scoring maturity. The organization owns its controls and scores, and only an Authorized HITRUST External Assessor can perform the validated assessment that a HITRUST report or certification requires.
How we scope
- Engagements are fixed-scope, with the requirement statements, facilities and systems in scope agreed in writing before work starts.
- We map each in-scope requirement to the policy, procedure, implementation, measure and risk treatment artifacts that the assessor will expect to see.
- Written scope names the owner of each artifact, so policy, procedure and measurement responsibilities are clear before any build begins.
How we build
- We help draft or revise policies so each mandatory element is stated and applies to every in-scope facility and system.
- We write procedures detailed enough for a qualified person to perform each element, then test them against the systems that run them.
- We configure self-hosted open-source platforms to produce logs, reports and metrics with defined frequency, owner and review cadence.
How we hand over
- We deliver a documented evidence set indexed by requirement statement, showing where each policy, procedure and measure is held.
- We document each measure's calculation, data source, thresholds and reviewer, so an assessor can trace the score without guesswork.
- We walk the client's team through the risk treatment process, issue tracking and management review that the Managed level examines.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers once the initial scope is delivered.
- We can help the client confirm readiness gaps before an assessor's fieldwork window opens, so remediation is not rushed.
- Assessor selection, scoring decisions and the final report remain with the client and the independent assessor, not with DeployOpen.
