HITRUST Maturity Levels: How to Automate Evidence Collection for r2 Assessments

HITRUST r2 assessments require evidence across 19 CSF control domains. Unlike a SOC 2 audit which looks at design and operating effectiveness, HITRUST evaluates your controls against five specific maturity levels. While some of this documentation can be pulled from infrastructure APIs, proving a control is actually "Implemented" still requires manual screenshots and workflow captures. Using automation for HITRUST evidence collection reduces the massive assessment preparation burden while ensuring your documentation is formatted exactly how your external assessor expects.

If you are preparing for a validated assessment, understanding what assessors want at each maturity level will dictate your entire testing strategy.

What Are the 5 HITRUST Maturity Levels?

HITRUST uses a maturity scoring model based on PRISMA. When an assessor evaluates a control, they don't just mark it "pass" or "fail." They score it across five distinct levels of maturity.

The five levels are:

Policy: What are your organization's rules?
Procedure: How do you execute those rules step-by-step?
Implemented: Are those rules actually configured and running in your systems?
Measured: Are you tracking metrics to ensure the control works over time?
Managed: Are you using those metrics to actively improve the control?

For a HITRUST r2 assessment, your goal is to score at least a 71 in every single control domain. If a domain drops below 71, you will be required to submit a Corrective Action Plan (CAP) to get certified.

What Evidence Do Assessors Require for Level 1 and Level 2?

Policy and Procedure are the foundational levels. Assessors review these first because they set the baseline for everything else.

For Level 1 (Policy), the evidence is simply the policy document itself. Assessors look for specific language. If the CSF requirement states that inactive sessions must time out after 15 minutes, your policy must explicitly state "Inactive sessions are terminated after 15 minutes." A vague statement about "session security" will lose points. You must also provide evidence that management approved the policy within the last year.

For Level 2 (Procedure), the evidence is the operational instruction manual. If the policy says sessions time out, the procedure must explain exactly how an administrator configures that timeout in AWS, Azure, or your custom application.

Assessors expect to see:

Step-by-step instructions
Who is responsible for the task (by role)
When the task occurs
Where the configuration lives

This documentation is static. Once you write it and get it approved, it sits in your evidence library until the next annual review.

How Do You Capture Evidence for Level 3 (Implemented)?

This is the heavy lift. The Implemented level is where you prove that the technical reality matches the written procedure.

If your procedure says you configure a 15-minute timeout in your identity provider, your Implemented evidence is a screenshot of that exact setting in Okta or Microsoft Entra ID.

Assessors are notoriously strict about Implemented evidence. Take control 01.b (User Registration). The assessor will ask for a list of all new hires in the last 90 days. They will select a sample. For each person in that sample, you must provide the Jira ticket requesting access, the manager's approval, and a screenshot of the system showing the account creation date matching the ticket.

For 09.aa (Audit Logging), you cannot just say CloudTrail is on. You must provide a screenshot of the CloudTrail configuration showing the specific regions covered, plus an export of the actual log data proving it captures the required event types.

This level requires visual proof. Assessors want to see the entire screen, the system clock, the URL bar, and the specific configuration setting uncropped.

Do You Actually Need Level 4 (Measured) and Level 5 (Managed) Evidence?

Honestly, most teams overthink this.

You do not need to score points in Measured and Managed to pass a HITRUST r2 assessment. Because the scoring formula heavily weights the first three levels, an organization that scores perfectly on Policy, Procedure, and Implemented will pass the domain easily.

Gathering evidence for Measured and Managed is incredibly difficult. You have to prove you are running regular statistical analyses on control failures and holding management review meetings to adjust resource allocations based on those metrics.

Unless you are a massive enterprise with a dedicated quantitative risk team, focus entirely on maxing out your scores for Levels 1, 2, and 3. Skip the rest.

Where Traditional HITRUST Assessment Automation Falls Short

Many teams buy a GRC platform expecting it to handle the entire HITRUST evidence collection process. They quickly hit a wall when it comes to the Implemented level.

Traditional automation relies on APIs. A GRC tool can connect to AWS and verify that an S3 bucket is encrypted. That covers basic infrastructure. But HITRUST evaluates your entire business, including application-level controls and custom internal tools.

APIs cannot capture the UI of your proprietary EHR integration. They cannot take a screenshot of your custom admin panel showing how role-based access is configured. They cannot document the visual workflow of a manager approving a change request in a non-integrated ticketing system.

When the API stops, the manual work begins. Your engineering team ends up spending weeks manually capturing hundreds of screenshots to satisfy the assessor's demand for visual Implemented evidence.

How Can I Automate HITRUST Maturity Level Evidence?

To automate evidence for the Implemented level, you need a system that captures visual proof the same way an auditor inspects it.

Instead of relying solely on infrastructure APIs, modern compliance teams deploy AI agents to handle the visual evidence collection. You define the test steps based on your Procedure documentation. The agent navigates through your applications, identity providers, and internal tools, capturing the necessary screenshots.

The agent validates that the settings match the requirement, checks the timestamps, and packages the results into a formatted PDF. When the assessor asks for proof of control 10.m (Control of Technical Vulnerabilities), you hand them a clean, standardized evidence pack showing the exact vulnerability scanner configurations and patch management workflows they requested.

This approach bridges the gap between written procedures and technical reality. What used to require a full week of an engineer's time pulling samples and taking screenshots now happens automatically in the background, formatted exactly how the assessor expects to see it.

Learn More About HITRUST r2 Certification Evidence Automation

For a complete breakdown of how to prepare your systems and reduce the engineering hours required for your assessment, see our guide on automating HITRUST r2 evidence collection, including how to map your technical controls directly to the CSF requirements.