How many HITRUST requirement statements must you meet to certify?
In CSF v11.9.0, the e1 has 44 requirement statements and the i1 has 182. The r2 starts from the 182 i1 statements and adds more through risk-based tailoring, so its total depends on your scoping answers in MyCSF. If a customer or contract names an e1, i1 or r2, the number you must meet is the number for that level in the version your assessment uses, so confirm the version with your assessor before you plan control work. The organization owns its controls. An implementation partner can prepare systems, configuration and evidence, but only an authorized External Assessor performs the validated assessment, and HITRUST performs quality assurance and issues the report and certification.
The r2 total is set for each organization. Your entity answers a risk-based scoping questionnaire in MyCSF covering general, organizational, geographic and technical factors, plus any optional compliance factors. Those answers generate your tailored requirement statements. Any factor answered No needs a written rationale, so a scoping decision made without one can add work at fieldwork. Ask your assessor to walk through the generated statement list before you begin evidence collection, and confirm in MyCSF that the list matches the systems, facilities and third parties in scope. Treat the r2 count as a planning figure until that review is complete.
How the e1, i1 and r2 requirement sets differ in size and scope
The e1, i1 and r2 are built as a traversable portfolio, so each level sits on the one below it. Choose the level a customer or contract actually asks for, and expect the work from a smaller assessment to carry forward into the next.
e1 requirement set
The e1 is the smallest HITRUST validated assessment, with 44 requirement statements in CSF v11.9.0. It is scored at the Implemented maturity level only, so the question is whether each in-scope control is operating, not whether a written policy exists. Confirm the current statement list in MyCSF before scoping, since the baseline changed in v11.9.0.
i1 requirement set
The i1 has 182 requirement statements in CSF v11.9.0 and includes every e1 statement. Like the e1, it scores Implemented maturity, so evidence must show controls operating across the in-scope environment. It fits organizations whose customers want a stronger signal than the e1 without the full tailoring work of an r2.
r2 tailored requirement set
The r2 starts from the 182 i1 statements and adds more through a risk-based scoping questionnaire in MyCSF. Each answer of No needs a written rationale, so the final count depends on the organization's factors. It scores policy, procedure and implementation maturity and fits organizations with a broad risk profile, such as large vendors serving several regulated sectors.
Carry-forward from e1 to r2
Every e1 statement appears in the i1, and every i1 statement appears in the r2 baseline, so policies, procedures and evidence built for one level are not discarded when moving up. The practical check is to map existing evidence against the larger set before buying a higher assessment, and to confirm with the assessor which statements need new work.
Interim assessment for r2
An r2 certification lasts two years, and an interim assessment is due in the 90 days before the first anniversary. This means the r2 is not a single event but a planned cycle that needs evidence kept current across both years. Ask your assessor to confirm the interim scope and the dates in your own certification letter.
How r2 tailoring turns the baseline into your requirement set
An r2 does not assess a fixed list of requirement statements. Its starting point is the i1 baseline, which contains 182 statements in CSF v11.9.0, and the r2 adds more through risk-based tailoring. The mechanism is a scoping questionnaire completed in MyCSF. It asks about general, organizational, geographic and technical factors of the organization, plus optional compliance factors that bring in additional requirements where a regulation or contract applies. The answers generate the tailored requirement statements your assessment will test. Because the output depends on what you declare, the scoping work is a decision the organization makes before any fieldwork starts, and it shapes every later effort estimate.
The rule to plan around is that any factor answered No requires a written rationale. A No is not a shortcut. It has to explain, in terms an assessor can test, why the factor does not apply to your environment. Gaps in these rationales are a common reason scoping is reopened late. Assign one owner to the questionnaire, have the security, infrastructure and compliance leads review each factor against current architecture, and keep the rationales with the evidence they cite. The organization, not the External Assessor, decides scope. The assessor can challenge answers and will test whether the declared scope matches the systems and facilities actually in use, but scope is the organization's call and its accountability.
Before you plan remediation or budget for evidence collection, confirm the exact tailoring output with HITRUST through MyCSF and with your External Assessor. Ask which statements a given set of answers generates for your assessment type, how the optional compliance factors change the count, and how inherited controls from cloud providers or other vendors affect what you must evidence yourself. Record the confirmed requirement set as a baseline document so later changes to the questionnaire, such as a new facility or a new regulatory factor, can be traced to a specific requirement change.
What the 19 assessment domains do in a HITRUST report
HITRUST groups its requirement statements into 19 assessment domains, from 01 Information Protection Program to 19 Data Protection & Privacy. Each domain is scored on its own, so the domain view is where a certification is won or lost and where a reader of the report should look first.
The 19 domains, numbered 01 to 19
Every HITRUST validated assessment reports results across the same 19 domains, numbered 01 Information Protection Program through 19 Data Protection & Privacy. The numbering stays fixed across e1, i1 and r2 reports, so a reader can compare the same domain between two certifications. Check the domain list in the report you receive against the version the assessor scoped, because a mismatch usually signals a scoping problem to resolve before fieldwork starts.
Domains group requirements from across the CSF
A domain is a grouping, not a separate control set. Requirement statements from many CSF control categories can sit under one domain, and a single statement is scored under the domain it belongs to. Before you plan evidence, map which of your in-scope systems and processes feed each domain, because one weak process can lower the score of a domain that otherwise looks healthy.
Each domain must reach its own average
Passing is not a single overall score. Each domain's core requirement statements must average at or above the threshold for the assessment level, so a strong result in most domains does not offset a weak one. The e1 and i1 need a domain average of at least 83 on implementation, and the r2 needs at least 62 across policy, procedure and implementation maturity. Ask your assessor early which domains sit closest to the line.
Read the report domain by domain
Customers and risk teams usually read a HITRUST report from the domain scores down, not from the cover page. A domain-level read shows where the maturity evidence is thin, which domains depend on inherited results from a cloud provider or vendor, and where any N/A decisions were made. Treat a domain with a low average as the place to ask for the underlying evidence, the scope and the corrective action plan before relying on the certification.
How HITRUST scores each requirement across maturity levels
The maturity sequence turns a requirement statement from a written intention into evidence that operates, and each level builds on the one before it. The level an assessor scores depends on whether the assessment is an e1, i1 or r2.
Confirm the requirement statement applies
Before any maturity level is scored, the assessor confirms which requirement statements are in scope for the assessment. For an e1 or i1 this is the fixed baseline. For an r2 it is the set generated by the risk-based scoping questionnaire in MyCSF. Any statement marked N/A must carry a written rationale covering every system, facility and third party in scope. A third party performing the work is not a valid reason, except under a documented e1 or i1 carve-out, and an activity that simply does not occur is never a valid reason. The step is complete when every statement is either in scope or justified as N/A.
Establish a current, mandatory policy
The first maturity level, Policy, asks whether the organization has written a current, documented policy that states the requirement's elements as mandatory. The policy must cover all in-scope facilities and systems, not only the headquarters or the flagship product. Owners of the control, usually the security or IT leadership, approve the document and keep it current. The assessor checks the policy text against each element of the requirement and checks that its scope matches the systems in the assessment boundary. A policy that uses soft language such as recommended or should, or that omits a facility, does not reach this level.
Document procedures for each element
The Procedure level asks whether documented procedures explain how to perform every element of the requirement. The test is whether a qualified person could carry out the work from the document alone, without asking the author. Procedures are typically written by the operational team that runs the control, such as system administrators or the service desk, and reviewed by the control owner. The assessor reads each procedure against the policy elements it implements and looks for gaps, such as an element that the policy requires but no procedure describes. The step closes when every element has a procedure a qualified person can follow.
Show the control is implemented
Implemented is the level scored in every assessment. It asks whether the policy and procedures are in operation across the in-scope environment. The assessor looks for system configurations, tickets, logs, access records, training records or other artifacts that show the control working on the systems in scope, with dates that fall within the assessment period. For the e1 and i1, this is the highest level scored. Each domain's core statements must average at least 83 at this level to support certification. The organization prepares the evidence, and the external assessor tests it through sampling and inspection.
Measure the control where the r2 scores it
Measured applies only to the r2. It asks whether the organization defines metrics for the control, collects them and uses the results to judge whether the control performs as intended. Typical evidence includes defined measures, recorded results and the review of those results by management. HITRUST treats scoring this level in an r2 as optional, so the organization and its assessor should confirm at scoping whether it will be scored. Because the e1 and i1 do not score this level, a team preparing only for those certifications can skip this step without affecting their result.
Manage the control through continuous improvement
Managed is the highest level in the sequence and also applies only to the r2, where scoring it is optional. It asks whether the organization acts on measurement results over time, adjusting the control, its procedures and its resourcing when the metrics show drift or failure. Evidence usually includes records of corrective actions, control changes made in response to measured results and management review minutes. Confirm with the assessor at scoping whether this level is scored for the r2 before building evidence for it. The step closes when the assessor can trace a measured result to a recorded improvement.
Compare domain averages against the pass threshold
Once each statement has its maturity scores, the assessor rolls them up by assessment domain. For the e1 and i1, each domain's core statements must average at least 83 on the Implemented level. For the r2, each domain must average at least 62 across the policy, procedure and implementation levels. Any domain below its threshold is a gap that must be addressed before certification. Readiness work should therefore compute these averages from internal scoring well before fieldwork, so that weak domains are found while there is still time to correct them. Ask the assessor to confirm the exact scoring method and scoring thresholds in writing.
Which maturity levels each certification scores and the domain average it needs
This table compares how e1, i1 and r2 score requirement statements, which maturity levels each one assesses and the average each domain must reach. Read the averages as per-domain thresholds, not one overall score, so a strong result in one domain cannot offset a weak result in another.
| Certification | Maturity levels assessed | Domain average needed to pass |
|---|---|---|
| e1 (44 requirement statements) | Implemented only | Core statements in each domain must average at least 83 |
| i1 (182 requirement statements) | Implemented only | Core statements in each domain must average at least 83 |
| r2 (182 i1 statements plus tailored additions) | Policy, Procedure and Implemented, with Measured and Managed optional | Each domain must average at least 62 |
| Scoring unit | Each requirement statement is scored on the maturity levels its certification assesses | Averages are calculated per domain, so each of the 19 domains must pass on its own |
| Documented policy (Policy level) | Must state the requirement's elements as mandatory and cover all in-scope facilities and systems | Counts toward the r2 domain average |
| Documented procedure (Procedure level) | Must explain how to perform every element in enough detail for a qualified person | Counts toward the r2 domain average |
| N/A statements | Need a rationale covering every in-scope system, facility and third party | Confirm with your External Assessor how N/A items are treated in each domain |
Why domain averages, not overall scores, decide whether you certify
Each domain must clear its own threshold, so a strong result in one domain does not offset a weak one. For the e1 and i1, the Implemented maturity level is scored, and each domain's core requirement statements need to average at least 83. For the r2, policy, procedure and implementation maturity are scored, and each domain needs to average at least 62. Because the averages are applied domain by domain, an overall score that looks healthy can still hide a domain that fails. The 19 assessment domains, from 01 Information Protection Program to 19 Data Protection & Privacy, are the units that decide the outcome, not the total across the whole CSF.
This changes how you prepare. Readiness work tends to concentrate effort on the domains with the most visible gaps, but a single weak domain can hold back the entire certification, because the assessor cannot issue a passing result until that domain's average clears its threshold. Ask your External Assessor early how core statements are weighted within each domain, since a few high-weight statements can move a domain average more than many lower-weight ones. Then plan remediation against the lowest domain first, not the highest overall score. Treat any domain sitting near its threshold as a schedule risk, and assign an owner to it before fieldwork begins.
Before you set internal targets, confirm the current thresholds and scoring rules in the HITRUST Assessment Handbook, and check them again whenever the CSF version changes. Ask your External Assessor to confirm in writing which thresholds apply to your assessment type and how they will be reported domain by domain. Thresholds and weighting can change between releases, so a plan built on last year's numbers can fail a domain that the team believed was safe.
When a requirement can be marked N/A and what rationale proves it
A requirement can be N/A when it applies to a system, facility or third party that sits outside the scope of the assessment, and the rationale must show that no in-scope asset is affected. The assessor will test the claim against your scoping decisions, so the rationale has to name the systems, facilities and third parties you excluded and explain why the requirement does not reach any of them. A statement that the requirement is 'not relevant to our environment' will not survive review.
- Name every excluded asset: list each system, facility and third party in scope and show that none of them is covered by the requirement.
- Tie the rationale to scope documentation: reference the scope boundary and asset inventory so the assessor can trace the claim.
- Check for drift: if a new system joins the environment during the assessment window, the N/A decision must be revisited.
- Cover every location: a requirement that applies to one data center but not another cannot be N/A for the whole organization.
Confirm the wording of this rationale and the level of asset detail expected with your External Assessor before fieldwork begins.
When a vendor or cloud provider carries out a requirement for you, that fact alone does not make the requirement N/A. You still own the control, and the assessor will look for evidence that your organization oversees the provider's performance. The only route to excluding a third party's activity from your assessment is a documented carve-out, and under HITRUST's rules that option applies only to e1 and i1 assessments.
- Carve-outs are the only exception: a documented e1 or i1 carve-out may remove a third party's scope, but an r2 does not allow the same reasoning as a basis for N/A.
- Inheritance is not N/A: where you rely on a provider's certified results, the requirement is handled through inheritance, not by marking it N/A.
- Keep oversight evidence: collect contracts, service reports and review records that show your own monitoring of the third party.
- Document the carve-out in writing: record the third party, the requirements affected and the approval trail before the assessment starts.
Confirm with your External Assessor whether a carve-out applies to your assessment level and how it must be documented.
An activity simply not happening in your environment is never a valid reason for N/A. If the requirement describes a control that should exist, the absence of the activity is itself a gap that needs a policy, procedure and working control, or a documented exclusion that the framework itself allows. Assessors treat 'we never do this' as an admission that the control is missing, not as a justification for skipping it.
- Separate absence from applicability: ask whether the requirement applies to your environment at all, not whether the activity happened last year.
- Build the control anyway: where the activity could occur, such as a remote access request or a data disposal event, the policy and procedure must still exist.
- Avoid vague language: phrases like 'no need' or 'not applicable to our business' need a specific, scope-based explanation.
- Revisit when the business changes: a new product, region or data type can make a previously non-occurring activity relevant.
Confirm with your External Assessor how the assessor will test that the activity is genuinely outside scope before you record any N/A.
Why organizations fall below the domain averages and how to prevent it
Most HITRUST domain shortfalls trace back to a small set of recurring gaps in documentation, procedure detail, evidence coverage and scoping rationale. Each card below names one gap, what to check early and who owns the fix, so the organization can close it before fieldwork starts.
Policies drafted but not applied
A policy that is written but never approved, or approved but not applied to every in-scope system and facility, scores poorly at the Policy level. HITRUST expects a current, documented policy that states each requirement's elements as mandatory and covers all in-scope facilities and systems. Check early that each policy has an approval record, a current review date and a scope statement that names the systems it governs. The organization owns policy approval and scope decisions, while an implementation partner can help map policies to requirement statements.
Procedures that state goals only
A procedure that describes the outcome but omits the steps leaves a qualified person unable to repeat the work, which fails the Procedure maturity level. HITRUST looks for documented procedures that explain how to perform every element in enough detail for someone with the right skills. Check whether each procedure names the tool, the role, the frequency and the output record. The organization owns the operational steps, and an implementation partner can draft procedure templates for the team to validate against real practice.
Implementation evidence covering part of the environment
Controls that work on the production cluster but not in the staging, backup or administrative environments produce partial evidence, and partial evidence lowers the Implemented score for the domain. Check early that each control has a coverage list naming every system, facility and third party in scope, and that samples can be drawn from all of them. The organization owns the control configuration across the environment, and an implementation partner can build collection scripts and dashboards that show coverage.
Unsupported r2 scoping answers
In an r2, each factor answered No in the risk-based scoping questionnaire needs a written rationale, and N/A requirements need a rationale covering every system, facility and third party in scope. A third party performing the work or an activity simply not occurring is not a valid reason. Check every No and N/A answer against the scope statement before the assessor sees it. The organization owns the scoping decisions and their rationale, while an implementation partner can review the questionnaire answers for consistency with the system inventory.
Questions buyers ask about HITRUST requirements and maturity
Which HITRUST certification has the fewest requirement statements?
The e1 has the fewest, with 44 requirement statements in CSF v11.9.0. The i1 has 182, and the r2 starts from those 182 i1 statements and adds more through risk-based tailoring. Every e1 requirement sits inside the i1 baseline, and every i1 requirement sits inside the r2 baseline, so work on the e1 carries forward. The count sets how much evidence you must gather and how many statements each domain must answer. A smaller count does not mean a lighter assessment in every respect. The e1 scores only the Implemented maturity level, so each statement still needs a working control with evidence behind it. Compare the levels on HITRUST's assessments page, then confirm the statement count for the CSF version in use on your assessment date, because HITRUST publishes new versions.
Can you know the total r2 requirement count before scoping?
No. The r2 total is set by the scoping questionnaire, so you cannot know the final number until you complete it in MyCSF. The floor is the 182 i1 statements in v11.9.0, and risk-based factors add more on top. The questionnaire covers general, organizational, geographic and technical factors, plus optional compliance factors. Each answer changes which requirements apply, and any factor answered No needs a written rationale. Two organizations of similar size can end with different totals because their systems, locations and regulatory obligations differ. Before you commit budget, ask the assessor or a readiness provider to walk through a draft tailoring against your actual environment. Treat any total quoted before the questionnaire is complete as an estimate that still needs checking.
Can our own team prepare HITRUST evidence in-house?
Yes, your team can prepare most of the evidence in-house. Only an Authorized HITRUST External Assessor can perform the validated assessment submitted for certification, and HITRUST performs quality assurance before it issues reports. Your organization owns its controls. The internal work is documenting policies and procedures at the levels HITRUST scores, operating controls long enough to produce records, and organizing evidence by requirement. Gaps usually appear in procedures that are too thin to repeat and in proof that a control operated across every in-scope system and facility. An implementation partner such as DeployOpen can prepare systems, controls and evidence on self-hosted open-source platforms in your own infrastructure, but it does not issue reports or certificates. Decide early which parts your staff can carry, and ask any outside party to state its deliverables in writing.
How much effort does the r2 scoping questionnaire take, and who answers it?
The organization answers the questionnaire in MyCSF, not the assessor. The effort depends on how many factors apply and how much proof each answer needs. You respond to general, organizational, geographic and technical factors, plus any optional compliance factors you choose. A security or compliance lead usually owns the document, with infrastructure, application and legal staff supplying the facts behind their answers. Any No answer needs a written rationale, which takes longer than a simple selection because the assessor must be able to test it. Plan for review cycles, since answers drive requirement selection. Changing a factor later can change the requirement set and the evidence it needs. No duration is fixed here, so ask the assessor for an estimate based on your environment, and confirm who in your organization will hold MyCSF access.
Why does one weak domain put the whole HITRUST certification at risk?
Each domain must meet its threshold on its own. The e1 and i1 need each domain's core statements to average at least 83 at the Implemented level. The r2 needs each domain to average at least 62 across policy, procedure and implementation maturity. A strong result in other domains does not offset a weak one, because the average is applied to each domain separately. Weak domains often come from thin procedures, controls that exist mainly on paper, or evidence that covers only some systems. Score each domain during readiness work before fieldwork begins, and remediate the lowest domains first. An overall score that looks healthy can still hide a domain that will fail.
What maturity levels does HITRUST score for each certification?
The e1 and i1 score only the Implemented level. The r2 scores Policy, Procedure and Implemented, and scoring Measured and Managed is optional, so confirm with your assessor whether it applies to you. At the Policy level, a current, documented policy must state the requirement's elements as mandatory and cover all in-scope facilities and systems. At the Procedure level, documented procedures must explain how to perform every element in enough detail for a qualified person to follow. Implemented means the control is in place and operating. Because the r2 scores several levels for each requirement, a control that runs well but lacks a written procedure can still lose points. Prepare documents and operating evidence together, and test both before the assessor arrives.
Who issues the HITRUST certificate after the assessment?
HITRUST issues the certificate after an Authorized HITRUST External Assessor completes the validated assessment and HITRUST performs central quality assurance. The assessor scores the requirements and submits results through MyCSF, and HITRUST reviews them before a report and certification are issued. The organization owns its controls and the decision to submit. DeployOpen does not issue reports, attestations or certifications. It plans, implements and prepares systems, controls and evidence on self-hosted open-source platforms in your infrastructure, which the independent assessor then tests. Validity depends on the level: e1 and i1 certifications last one year, and r2 certifications last two years, with an interim assessment due in the 90 days before the first anniversary. Before you sign any engagement, confirm the assessor's status in HITRUST's directory.
How DeployOpen prepares systems and evidence against HITRUST requirements
DeployOpen works on the requirement statements that sit behind each HITRUST domain, helping organizations prepare the systems, documentation and evidence that a validated assessment will test. The organization owns its controls and its certification decision, while an authorized External Assessor performs the validated assessment and HITRUST issues any report or certificate.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We map in-scope systems, facilities and third parties to the requirement statements for the chosen assessment level.
- The written scope states which domains and maturity levels the work will prepare evidence for, and what is excluded.
How we build
- We configure and harden self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks.
- We draft policies and procedures at the level of detail a maturity review checks for each in-scope requirement.
- We test implemented controls against the requirement statements and record gaps for remediation before fieldwork.
How we hand over
- You receive documented policies, procedures, configuration records and evidence mapped to each requirement statement and domain.
- N/A decisions and any rationale for them are documented per system, facility and third party in scope.
- Your team is trained to keep evidence current, so the assessor can sample it during the validated assessment.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- We help your team plan for changes to the CSF version and to requirement statements before a renewal or interim assessment.
- Questions about how a specific requirement or maturity level will be scored should go to your External Assessor, and we confirm the details in writing before work changes.
