The first time a team sees an r2 scorecard, the surprise is usually the same. A control they run well, every day, scored lower than they expected. The control was fine. The written procedure behind it was thin, or nobody was measuring it.
That is the r2's maturity model working as designed. It does not ask only whether a requirement is met. It asks how deeply the requirement is embedded in the way you operate, and it scores that depth across five levels.
This article explains what each level asks for, how scores are formed, and where effort moves the result. For how the r2 compares with the e1 and i1, see our comparison of the three assessments.
The five maturity levels
Every requirement statement in an r2 is evaluated at five levels. They build on each other, from intent to operation to continuous improvement.
Policy. A written, approved policy states the requirement's intent: what must happen and who is accountable.
Procedure. A documented procedure describes how the requirement is carried out: the steps, the roles, the frequency and the systems involved.
Implemented. The requirement is actually in place and operating across the in-scope environment, and there is evidence of it.
Measured. You measure the control's performance, with metrics or independent checks that would show whether it is working.
Managed. Management reviews those measurements and acts on them, correcting the control when the measurements show a problem.
The first three levels are about whether the requirement is defined and done. The last two are about whether you would notice, and respond, if it stopped being done.
How a level is scored
Your assessor scores each level of each requirement statement using HITRUST's published scoring rubric. The rubric places each level on a scale that runs from non-compliant through somewhat, partially and mostly compliant to fully compliant.
For the policy, procedure and implemented levels, the rubric asks two questions:
Strength. How completely does the policy, procedure or implementation address the elements of the requirement statement? A policy that covers three of the four things the requirement names is not fully compliant.
Coverage. How much of the in-scope environment does it apply to? A procedure that describes only one of your two cloud environments falls short on coverage, however well written it is.
The measured and managed levels are evaluated on whether measurement exists, what kind it is, and whether management acts on what it shows. The rubric distinguishes between kinds of measurement, so ask your assessor how they will apply it to your controls before fieldwork rather than during it.
How level scores become a result
The five level scores combine into a score for the requirement statement. The levels are weighted, so they do not contribute equally. Requirement statement scores then roll up into scores for each assessment domain, such as access control or incident management.
Certification depends on those domain scores meeting the minimum HITRUST sets. One weak requirement statement rarely sinks a domain on its own. A pattern of weak documentation across a domain can.
Low scores below HITRUST's thresholds can also require corrective action plans, which you then work through during the certification period.
What each level looks like in evidence
The levels are easier to reason about with one requirement in mind. Take a hypothetical requirement that vulnerability scans run on a defined schedule and findings are remediated within defined timeframes.
Policy
The vulnerability management policy states that in-scope systems are scanned, that findings are remediated within timeframes based on severity, and who owns the program. It is approved and dated. It names the elements the requirement names, not only the topic.
Procedure
A procedure says which scanner runs, against which asset groups, how often, who triages findings, where they are tracked and what the remediation timeframes are per severity. Someone new could follow it.
Implemented
Scan reports exist for each scheduled run across every in-scope asset group. Findings appear in a tracker with dates, and the tracker shows remediation within the stated timeframes, or documented exceptions. The assessor samples these records much as any auditor would. Our article on how auditors sample controls explains why gaps in a recurring record are hard to explain away.
Measured
Someone tracks metrics such as scan coverage against the asset inventory and the share of findings closed within the timeframe. The metric is defined, recorded on a schedule and kept.
Managed
When the metrics slip, there is a record of someone noticing and acting: a ticket, a meeting note or a revised procedure. Managed evidence is evidence of a decision, not of a dashboard.
Where the effort pays off
Maturity scoring tempts teams to chase every level for every requirement. That is rarely the right use of time.
Get policy and procedure right everywhere. These levels are the most within your control. They need writing, review and approval, not new systems. A procedure that names the frequency, roles and systems for each requirement is often the cheapest improvement available on an r2 scorecard.
Close coverage gaps in implementation. Implemented scores fall most often because a control runs on some systems and not others. A second cloud account, a legacy database or contractor laptops are the usual culprits. Your preparation work should include checking each control against the full scope.
Measure the controls that already produce data. Vulnerability management, access reviews, patching, backup success and training completion all generate records that can become metrics. Start there. Inventing metrics for controls that produce no data creates work with little to show for it.
Treat managed as a habit, not a document. You cannot backfill managed evidence. It comes from a regular review where someone looks at the metrics and records what they decided. A short monthly or quarterly review, minuted, gives you that record going forward.
Using a readiness assessment to plan the work
An r2 readiness assessment lets you score yourself against the same rubric before an assessor does. Its most useful output is not the overall number. It is the pattern of where points are lost.
Sort your readiness results by level rather than by domain. If most of the shortfall sits at policy and procedure, the fix is a documentation project with clear owners and a deadline. If it sits at implemented, you have control gaps, and those need time to build and to accumulate operating history before fieldwork. If it sits at measured and managed, decide deliberately which controls are worth instrumenting before the assessment and which can wait for the next cycle.
Be strict with yourself on coverage. The most common readiness error is scoring a control as fully implemented because it works on the main production environment, without checking the rest of the scope.
Common scoring mistakes
One policy document for everything. A single high-level security policy rarely addresses the specific elements of each requirement statement. It scores on topic and falls short on strength.
Procedures that restate the policy. If the procedure does not say how, by whom and how often, it is a second policy, and it scores like one.
Measurement without retention. A dashboard that shows today's number is not evidence of measurement over time. Keep the readings.
Claiming managed without a trail. "We discuss it in standups" is not a record. If the decision is not written down, the assessor cannot test it.
The HITRUST framework page has a summary of the r2 alongside the other assessment types if you need to brief colleagues.
How TrustLynce helps
Policy management keeps policies and procedures versioned, with approval and acceptance tracking. Continuous monitoring checks controls on a schedule and routes failures to their owners, which gives you measured readings over time and a record of who responded.