HITRUST r2 assessment: requirements and evidence

What the HITRUST r2 risk-based assessment asks for

A customer or regulator that asks for HITRUST r2 wants evidence that your controls hold up against your own risk profile, not just a generic checklist. The r2 starts from the 182 requirement statements of the i1 baseline, then adds requirements through tailoring based on organizational, compliance and system risk factors. The result is a requirement set specific to your environment, and each requirement is scored on three things: how well it is documented in policy, how well the process is defined in procedure, and how fully it is implemented in practice. Those results are reported across the 19 assessment domains, from Information Protection Program through Data Protection & Privacy. Confirm with your assessor which risk factors and tailoring inputs they will use before you accept the requirement set.

The hard part is rarely the baseline. It is the tailoring decisions and the maturity scoring. Each added requirement is an obligation you will be tested on for the full assessment, so a broad tailoring choice made for convenience can enlarge the fieldwork and the evidence you must produce. On the scoring side, a domain must average at least 62 across all of its requirement statements to certify, which means a few weak implementations can be offset by strong ones in the same domain, but policy documents that exist without operating evidence will drag the average down. Ask your assessor to walk through the scoring model for a sample domain before fieldwork starts.

For each domain, list the requirement statements that tailoring added, identify the owner and the evidence source for each, and check whether the evidence shows the control operating over time rather than only at a point in time. Treat the policy, procedure and implementation scores as three separate readiness checks. A useful first step is to confirm your current CSF version and the specific requirement set with your external assessor, since an r2 does not have to use the newest CSF version at creation, and that choice affects which statements you prepare against.

Which systems, data and third parties the r2 scope covers

An r2 starts from the 182 i1 requirement statements, then tailoring adds requirements based on organizational, compliance and system risk factors. The decisions below set how much of the environment is assessed, which requirements apply, and how much evidence the assessor must review before fieldwork begins.

Systems and environments in scope

Every system that stores, processes or transmits the in-scope data, and every supporting component such as identity, logging, backup and administration tools, must be named in the scope statement. Systems left out of scope are not tested, but an assessor will check that the boundary is defensible. Confirm the boundary with your assessor before you build evidence, since a late change to the boundary forces re-collection across many requirements.

Data types that set the boundary

The categories of data the organization holds, such as regulated health, payment or personal data, determine which systems count as in scope and which risk factors apply during tailoring. A data flow map that shows where each category is created, stored and shared is usually the fastest way to agree the boundary. Expect more work when sensitive data reaches analytics platforms, support tools or backups that teams do not treat as core systems.

Privacy added through tailoring

Unlike the e1 and i1, an r2 can be tailored to include privacy requirements. Adding privacy extends the requirement set and introduces evidence for notices, consent, data subject handling and retention, which many teams have not yet documented in a form an assessor can test. Decide early whether privacy is in scope, because adding it after readiness work begins means new requirements, new owners and new samples.

CSF version chosen at creation

An r2 does not have to use the newest CSF version when it is created, which gives the organization room to time its assessment against contract dates and internal readiness. The chosen version fixes the requirement text the assessor tests, so teams should confirm which version their customers expect before starting. Check the current version in MyCSF and any version deadlines published by HITRUST before fixing the choice.

No carve-out for service providers

In an e1 or i1, service provider requirements can be carved out, which removes them from the assessed population. An r2 does not allow that carve-out, so a provider's hosting, backup, support and development functions that touch the in-scope environment must be covered directly or through an inheritance approach. Map each third party that operates part of the environment early, because each one changes the number of requirements the assessor must test.

Third-party evidence and inheritance

Where a cloud provider or vendor already holds a HITRUST or other report, the organization may be able to reuse that evidence, but only for the requirements that the provider's report actually covers. Build a shared responsibility matrix that shows which controls the organization owns and which it inherits, then confirm with the assessor how each inherited requirement will be tested. Ask your assessor which provider reports they will accept before you rely on them.

How an authorized external assessor tests the r2

This table walks through how an authorized external assessor tests an r2, from who may perform the work to the evidence requested and the findings that most often delay certification. Read it as a sequence: each row is a stage the organization should prepare for before fieldwork begins.

Stage or test	What the assessor does	What the organization should prepare
Who can perform the assessment	Only Authorized HITRUST External Assessor organizations may perform the validated assessment submitted for certification.	Confirm the firm's authorized status on HITRUST's assessor directory before signing any scope or engagement letter.
Fieldwork window	The validated assessment fieldwork runs at most 90 days.	Have the r2 scope, system boundaries and tailoring decisions settled so fieldwork does not stall on open questions.
Tailored requirement review	Checks that the requirement statements added through tailoring match the documented organizational, compliance and system risk factors.	Keep a written rationale linking each risk factor to each added or excluded statement, with the same logic applied across the scope.
Evidence requests	Requests policies, procedures, configuration output, logs, tickets and records that show each requirement is implemented, sampled across the in-scope environment.	Organize evidence by requirement statement and by system, with dates and owners, so samples can be produced quickly.
Policy, procedure and implementation scoring	Scores each requirement on policy, procedure and implementation maturity rather than on the existence of a document alone.	Make sure written procedures describe what staff actually do, and that operating records match those procedures.
Domain average threshold	Each r2 assessment domain must average at least 62 across all its requirement statements to certify (HITRUST Assessment Handbook v1.1).	Review domain averages during readiness work so weak domains are corrected before the formal assessment, not after.
Common finding: weak implementation evidence	Rejects or lowers scores where evidence shows a control was designed but not operating consistently over the period tested.	Collect recurring operational evidence, such as access reviews and vulnerability scan follow-ups, across the full look-back period.
Common finding: inconsistent tailoring	Flags requirement statements added or removed without a clear link to risk factors, or applied differently across similar systems.	Document tailoring before fieldwork and confirm that inherited or shared controls are treated consistently with the rest of the scope.
Central quality assurance	HITRUST reviews the assessor's work centrally before it issues the report, which can require follow-up questions to the assessor and the organization.	Keep the assessment workpapers and evidence index ready so follow-up requests can be answered within the same working period.

How to prepare for an r2 assessment, step by step

This sequence moves an organization from a business decision to an assessor-ready package, with each step producing a document or register that the next step depends on.

Confirm the business case and assessment scope
Leadership, compliance and the system owners agree why the r2 is needed, which customers or regulators will rely on the result, and which business units, systems, data flows and locations fall inside the boundary. Ask the assessor and the requesting party to confirm that the r2 is the right level, since the e1 and i1 suit some requests better. The step closes with a signed scope statement that names in-scope systems, facilities, service providers and the CSF version the team intends to use. Because the r2 does not have to use the newest CSF version at creation, confirm the version choice in writing before any work begins.
Tailor requirement statements to risk factors
The r2 starts from the 182 i1 requirement statements and adds requirements through tailoring based on organizational, compliance and system risk factors. Compliance and security leads document the organization's size, data types, regulatory obligations, system criticality and third-party exposure, then work through the tailoring factors with the assessor or an authorized readiness partner. The output is a tailored requirement statement list with a short rationale for each addition, so an assessor can trace why each statement applies. Ask for this rationale in writing from any consultant you engage, because it becomes part of the assessment record.
Close gaps against the i1 baseline
Because every i1 requirement sits inside the r2 baseline, the first technical pass compares current controls against the i1 requirement statements and then against the tailored additions. Control owners rate each statement on policy, procedure and implementation maturity, and identify where a control is missing, undocumented or not operating consistently. Remediation owners then fix the gaps, and the team records each gap, its owner and its closure evidence in a gap register. The step is complete when the register shows no open gaps that would prevent a domain from averaging the scoring threshold, which is covered in the scoring guidance.
Build evidence and incubation history
Each requirement statement needs evidence that the control existed and operated over the period the assessor samples, so teams must collect logs, tickets, policy approvals, access reviews, training records and test results as the controls run, not only at assessment time. Organizations commonly start this collection early so the operating history is available when fieldwork begins. The output is an evidence index that maps each tailored requirement statement to its artifacts, owners and storage location. Confirm with the assessor which sampling rules and incubation expectations apply to your scope before you rely on any history.
Run an internal readiness review
An internal reviewer who did not build the controls walks through the tailored scope, the evidence index and the gap register, and scores each domain as the assessor would, using the r2 domain averaging rule as the reference point. The reviewer tests a sample of statements by asking the evidence owner to produce the artifact on demand. The output is a readiness report listing each domain's expected position, unresolved findings and the decisions still pending, such as N/A determinations or alternate controls. Leadership signs off only when the findings are closed or formally accepted.
Engage an authorized External Assessor
Only Authorized HITRUST External Assessor organizations can perform the validated assessment submitted for certification, and HITRUST performs central quality assurance before issuing the report. Choose the assessor after the readiness work is done, and check that the firm holds current authorization on HITRUST's Find an External Assessor page. Ask for a written scope of work, the fieldwork plan, the independence confirmation and the deliverables. Remember that the assessor issues the validated assessment results, while your team and any readiness partner prepare the systems and evidence. Your implementation partner can support the preparation, but it cannot sign or issue the report.

Evidence that passes an r2 and how to keep it current

An r2 is only as strong as the evidence behind each requirement statement, and assessors test that evidence across the 19 assessment domains rather than taking statements at face value. The cards below cover the evidence categories assessors expect and the routine work that keeps them current between the validated assessment and the interim assessment.

Policies and procedures

Policies state what the organization intends, and procedures state who does what, when and with which record. For an r2, assessors check that each document is approved, versioned, communicated to the people who run the control and aligned with the scope and tailored requirement statements. Check that every procedure names an owner and a review date, and that no policy promises a control that no system actually performs. Stale documents are one of the most common reasons evidence is challenged.

Implementation records

Implementation records show that a control operated on real systems, such as change tickets, deployment approvals, patch reports, training completions and vulnerability remediation logs. Assessors usually sample these records across the assessment period, so a single well-kept example does not stand in for a year of operation. Confirm that each control has a repeatable record source and that the records are retained in a form the assessor can inspect.

Configuration exports

Configuration exports capture the settings of firewalls, identity providers, databases, logging pipelines and endpoint tools at a point in time, with a timestamp and the system name. They are strong evidence for technical requirement statements because they show the setting itself rather than a description of it. Schedule exports so the evidence for the interim assessment is generated by the same method as the original, and store them under change control so later edits are visible.

Access reviews

Access reviews show that accounts, privileged roles and service identities were checked against the people who should still hold them. For an r2, a review should record the reviewer, the population reviewed, the decisions made and the removals completed. Run the review on a fixed cadence that you can document, and keep the removal tickets linked to the review, since assessors often trace a removed account back to its approval.

Incident records

Incident records show how security events were detected, triaged, escalated, contained and closed, and what changed afterward. An assessor reads them to judge whether the incident process works in practice and whether lessons flowed back into policies and configurations. Keep a register that links each incident to its root cause and corrective action, and confirm which incidents must be disclosed to HITRUST under the r2 rules before the interim assessment.

Keeping evidence current

Between the validated assessment and the interim assessment, the goal is to avoid rebuilding evidence from memory. Assign an owner to each evidence item, set a recurring collection calendar and store each artifact with its date, scope and system name. Review the calendar against the interim window, which must be submitted within the 90 days before the one-year anniversary, so the second look starts from a maintained evidence set. Ask your assessor early which samples they expect to draw.

What meeting the r2 costs in money and effort

This table breaks the r2 into its cost components, showing who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to structure a request for quote so that each component is priced separately and compared on the same scope. No fees are stated here because the supplied facts do not give any.

Cost component	Who is paid	One-time or recurring	What drives it, and what to ask for
Authorized assessor fees	The Authorized HITRUST External Assessor organization that performs the validated assessment	Recurring at each validated assessment (initial, interim and recertification)	Scope of tailored requirement statements and system count. Ask for the fee split between fieldwork and report preparation, and whether the quote covers the interim assessment.
Tailoring and scoping effort	Internal team, plus any consultant or readiness support you engage	One-time at creation, revisited at each significant change	Number of organizational, compliance and system risk factors. Ask the assessor how tailoring decisions are documented and reviewed before fieldwork begins.
Readiness and gap remediation	Internal engineering, security teams and any implementation partner you hire	One-time for the first certification, then ongoing as controls change	Current maturity against policy, procedure and implementation expectations. Ask for a gap assessment that lists work by assessment domain so remediation can be sized.
Engineering remediation	Platform, infrastructure and application teams, or a partner working in your environment	One-time for initial gaps, recurring for control upkeep	Age of existing systems and how much logging, access control and configuration management must be built. Ask for work items tied to specific requirement statements.
Evidence upkeep	Internal control owners and compliance staff	Recurring across the two-year certification period	Number of systems and the frequency of control operation. Automated evidence collection lowers effort but must be confirmed against each control's needs.
Interim assessment work	Internal team for preparation, and the assessor for the validated interim assessment	Recurring once, due within the 90 days before the first anniversary of certification	Changes made during year one and the number of requirement statements that were in scope at certification. Ask for a plan covering evidence refresh before the interim window opens.
MyCSF subscription	HITRUST, for access to the platform used to manage the assessment	Recurring, confirm current terms with HITRUST	Number of users and assessment objects. Confirm the subscription tier and renewal terms directly with HITRUST before budgeting.
Training and internal assessor capability	Training providers and HITRUST-recognized programs	One-time per staff member, with periodic refresh	Number of staff who need CSF knowledge to run readiness and evidence work. Confirm which training programs are current before enrolling staff.
Quote and contingency	Not a payee, but a planning item	Planning reserve for the first cycle	Unknown findings during readiness. Ask each vendor to list assumptions and exclusions so that scope changes are priced before they happen.

Who owns, prepares and certifies each part of the r2

Your organization owns every control in the r2 scope, the risk decisions behind tailoring, and the evidence that the controls operate. No outside party can accept risk on your behalf or decide that a control is effective in your environment. The assessor tests what you present, and the certification describes your environment, so your staff must be able to explain and defend it during fieldwork.

Control ownership: Named owners for each requirement statement, with authority to change the control and accountability when it fails.
Tailoring decisions: Choosing which organizational, compliance and system risk factors apply, and documenting why requirement statements were added or excluded.
Policies and procedures: Approving the written policies that the assessment reads for policy maturity.
Evidence production: Keeping logs, tickets, reviews and configuration records that show the control operated over the assessment period.
Interview readiness: Making sure control owners can answer assessor questions consistently with the evidence.

Confirm with your leadership which individual signs off on the scope and on any risk-based exclusions before the assessor is engaged.

Where r2 programs usually fall short

Most r2 programs that struggle do not lack controls. They fail on the link between tailoring, domain scoring, evidence and time. The cards below cover the four gaps that most often surface before or during a validated assessment, each with a closing action you can take now.

Tailoring that does not match risk

The r2 starts from the 182 i1 requirement statements and adds requirements through tailoring based on organizational, compliance and system risk factors. The gap appears when the added requirements have no documented link to those factors, or when the factors on file describe a different organization than the one being assessed. Check that every added requirement traces to a named risk factor in your risk assessment. Ask your assessor to review the tailoring rationale before fieldwork starts, not after.

Domains averaging below the threshold

Each r2 assessment domain must average at least 62 across all its requirement statements to certify. A strong score in most domains can still fail certification when one domain has several weak statements that pull its average down. Review domain averages during readiness, not only the overall picture. Identify the lowest domain early, decide whether the fix is control maturity or evidence, and assign an owner with a date before the validated assessment begins.

Policy evidence without implementation

Many programs hold current, approved policies and procedures but cannot show that the controls operate. Assessors look for records that the procedure was followed: access reviews completed, changes approved, tickets closed, alerts investigated. Documents that describe intent without these records score lower on implementation maturity. Pair every policy with at least one operating record. Sample your own evidence the way an assessor would, and remove documents that describe controls you do not run.

Interim assessments treated as a formality

An r2 certification is valid for two years, and an interim assessment must be submitted within the 90 days before the one-year anniversary of the certification date. Teams that plan for it late often find that controls drifted, owners changed and evidence was never retained. Missing the window can put the certification at risk. Put the interim window on the calendar on the day of certification. Schedule an internal evidence review in the months before it opens, and confirm the submission date with your assessor.

Service provider scope left unresolved

Unlike the e1 and i1, the r2 does not allow service provider requirements to be carved out. Programs that rely on a cloud platform or outsourced vendor sometimes discover late that those requirements still need coverage, either through inheritance supported by evidence or through their own controls. Confirm early which requirements each provider covers and what evidence you can obtain. Ask providers for their current assessment reports and the scope those reports actually cover.

How long, costly and hard is an r2 for our team?

How long does an r2 assessment take from start to certification?

The validated assessment fieldwork window is at most 90 days for e1, i1 and r2, according to the HITRUST Assessment Handbook. That window covers only the assessor's testing, so the total calendar time is longer. Preparation work, including readiness review, scoping, tailoring the requirement statements to your risk factors and collecting evidence, usually comes before the assessment is submitted. The time that matters most is how long your controls have been operating before fieldwork starts, because assessors test evidence over a period, not a single snapshot. Ask any partner to show a written schedule that separates preparation, fieldwork and HITRUST quality assurance before work begins.

What does an r2 cost, and what drives the price up?

HITRUST does not publish a single price for an r2, and this page does not estimate one. The bill usually has several parts: the external assessor's fee for fieldwork and reporting, HITRUST's submission and certification fees, any MyCSF subscription your team uses, and the internal and external effort of preparing evidence. The largest drivers are the number of requirement statements added through tailoring, the number of systems and locations in scope, how many controls are inherited from cloud or vendor reports, and how mature your current evidence is. Ask each bidder to itemize these components in a quote and state which costs are one-time and which recur at the interim and recertification points.

How much work does an r2 need from our internal staff?

Internal staff own the controls, so they carry most of the work that an outside party cannot do for you. Expect demand from security, IT operations, engineering, HR and the teams that own your policies and vendor contracts. The work includes naming control owners, confirming which requirement statements apply, producing policies and procedures, pulling evidence on request and walking assessors through how systems run. Because the r2 is scored on policy, procedure and implementation maturity, staff must be able to show that controls are documented and used, not only designed. Ask a partner to name the roles and weekly hours it expects from your team before you sign.

Can our team complete an r2 alone without an outside partner?

Your team can prepare for and run an r2 without a consultant, but it cannot certify itself. Only Authorized HITRUST External Assessor organizations may perform the validated assessments submitted for certification, and HITRUST performs central quality assurance before issuing reports. Some organizations use internal staff for readiness work and bring in a partner for specific gaps, such as building technical evidence or running security testing. DeployOpen prepares systems, controls and evidence and does not issue reports or certifications. Whichever route you choose, confirm the assessor's authorization directly with HITRUST before you commit budget.

What is the difference between an r2 and the NIST CSF 2.0 add-on?

The r2 is a full validated assessment with a two-year certification. The NIST CSF 2.0 add-on does not involve a separate assessment. It maps the results of an r2 to the NIST Cybersecurity Framework 2.0 and produces a HITRUST NIST CSF 2.0 certification report. Only the r2 can result in a HITRUST-issued NIST Cybersecurity Framework certification, so if a customer asks for NIST CSF 2.0 evidence and you lack an r2, the add-on is not an option. Plan the r2 first, then add the mapping if your customers need it. Confirm current add-on terms with HITRUST, since fees and report format are set by them.

What happens if we miss the r2 interim assessment deadline?

An r2 interim assessment must be submitted within the 90 days before the one-year anniversary of the certification date. Missing that window puts your certification status at risk. A bridge assessment can extend a form of r2 certification status for an additional 90 days after the recertification date has passed, but it is a limited stopgap, not a substitute for timely work. Treat the interim as a planned project with its own budget and owners, starting roughly at the beginning of the submission window. Ask your assessor which evidence will be sampled at interim so your team can keep it current throughout the year.

Which parts of an r2 can we outsource, and which must stay in house?

You can outsource readiness reviews, evidence collection support, technical hardening, documentation drafting and security testing. You cannot outsource ownership of the controls, the decision on which requirement statements apply to your environment, or the attestation that your staff are responsible for those controls. The independent assessor performs the validated assessment, and HITRUST issues the outcome. Be wary of any proposal that suggests the partner will certify you or guarantee a result. Ask for a written split of responsibilities in the scope document so each party knows who produces each piece of evidence.

How do we keep the r2 effort from growing after certification?

Most of the recurring effort comes from keeping evidence current, not from repeating the whole assessment. Between the interim and the recertification, your team must maintain control operation, handle access reviews, change records, vulnerability management and incident handling as normal business. Costs that recur include the interim assessment, the recertification assessment and any ongoing support or testing retainers. Reduce that load by assigning evidence owners early, automating collection where your tools allow it, and inheriting results from providers that already hold relevant reports. Ask any partner which evidence can be produced on a schedule and which must be gathered on demand.

How DeployOpen prepares your r2 evidence

DeployOpen's part of an r2 effort starts with a written scope that names the systems, environments and platforms in play, the tailored requirement statements your organization has chosen, and the deliverables each side owns before any work begins. We implement and harden the self-hosted open-source platforms that carry those requirements inside your own cloud accounts, data centers or air-gapped networks, then configure logging, access, backup and change records so the resulting evidence reflects how the systems actually run. Your organization still decides its policies, risk acceptances and N/A calls, and your team signs off on each control's operation.

On the evidence side, we prepare the artifacts an external assessor will sample, such as configuration baselines, access review exports, patch and vulnerability records, backup restore tests and incident tickets, organized so each one can be traced to the requirement it supports. Ask any partner to confirm which evidence it will produce, who owns the collection cadence after handover, and how exceptions are recorded. For this work, the fieldwork window and the assessor's quality review are separate from our work, and only an Authorized HITRUST External Assessor can perform the validated assessment.

DeployOpen does not issue HITRUST reports or certifications. That decision rests with the independent assessor and HITRUST's central quality assurance. Ongoing support, upgrades and continuous testing are available as a retainer, which is useful when the r2 interim assessment falls due in the 90 days before the first anniversary and when the platforms change between assessments. Ask for the retainer scope in writing, including which platform changes trigger review and which evidence is refreshed, so the work between certification cycles is as deliberate as the work leading to them.

HITRUST r2 Risk-based assessment