How do HITRUST r2 factor answers set your requirement statements?
When a customer or contract asks for an r2, the r2 starts from the 182 i1 requirement statements, and your answers in the MyCSF scoping questionnaire add to or shape that set. The questionnaire covers general, organizational, geographic and technical factors, plus optional compliance factors tied to authoritative sources you are obligated to meet. Each answer is an organizational decision, so the organization owns it. Your External Assessor validates whether the answers are accurate and consistent with your environment, and HITRUST performs quality assurance before any report is issued. Any factor answered No needs a written rationale, and that rationale is one of the first things a reviewer will read.
Before you answer, confirm with your assessor which factors your systems actually trigger. A cloud-hosted platform, a processing location outside your home jurisdiction or a new AI component can each change which requirement statements apply. Map each answer to a named system, data flow or obligation in your own records so you can show where it came from. Note also that the e1 and i1 cannot be tailored to include privacy. Only the r2 can, so if a customer needs privacy coverage in the certification itself, the r2 is the route, and you should confirm that requirement early rather than discover it at scoping.
Treat the questionnaire as a document you will defend, not a form you complete once. A combined e1 or i1 with compliance factors yields Insights Reports for each authoritative source, but certification still counts only the core requirement statements, so the two outcomes should not be confused in customer conversations. Ask your assessor for a quote that lists the factors in scope, the rationale expected for each No answer and who prepares the supporting evidence. Changing a factor answer later is a significant change under HITRUST's guidance, so decide the answers with your architecture and compliance owners before the fieldwork window opens.
How the scoping questionnaire turns answers into requirements
The r2 scoping sequence turns your answers about the organization, data, geography, technology and compliance obligations into a fixed set of tailored requirement statements. Each step produces a record that the next step depends on, so the assessor tests the same set you confirmed.
Answer the MyCSF scoping questionnaire
The entity's compliance lead or assessment owner works through the risk-based questionnaire in MyCSF, covering general, organizational, geographic and technical factors. Optional compliance factors are answered where they apply to the entity's obligations. The output is a complete set of factor answers stored in the assessment record, with no unanswered items before the next step can begin.
Generate the tailored requirement statements
Based on the factor answers, MyCSF builds the r2 requirement set. The r2 starts from the i1 requirement statements and adds requirements that the organizational, compliance and system risk factors call for. The output is a generated list of requirement statements that reflects the answers, not a list the organization picked by hand.
Write rationales for every No answer
Any factor answered No needs a written rationale explaining why that factor does not apply to the entity. Consultants and internal owners should draft these with the people who run the environment, then attach the explanation to the factor. The output is a rationale on file for each No answer, which an assessor can read and test against the environment.
Confirm the requirement set internally
Before fieldwork, the organization's leadership and assessment owner review the generated requirement statements, the factor answers and the rationales together. They confirm that the set matches the systems, data, locations and obligations in the defined scope. The output is a recorded internal sign-off on the set, which fixes the baseline the assessor will test.
Test the confirmed set in fieldwork
The External Assessor tests the requirement statements generated from the confirmed answers during the validated assessment fieldwork window. The assessor does not add or drop requirements on its own, so gaps in the questionnaire show up as test results. The output is the assessor's testing of this exact set, which feeds the submission to HITRUST quality assurance.
Treat changed answers as significant changes
The set stays fixed for the assessment unless a significant change occurs. Changing a factor answer is one of HITRUST's examples of a significant change, so a later edit to a factor can alter the requirements that apply. Before changing any answer, the owner should check the renewal guidance and talk to the assessor, because the change may affect the certification in effect.
Which factor categories change your requirement set most
An r2 scoping questionnaire has four core factor groups and optional compliance factors. Each answer can add or remove requirement statements, so the answers you give need to match your actual data, hosting and service footprint before you submit.
Organizational factors
These describe the entity itself: its size, the number of users and records it handles, its business lines and whether it runs or depends on third-party services. Answers here tend to add requirements when the organization handles high volumes of records or serves many users. Before answering, confirm the user and record counts from systems of record, not from memory, and confirm which business units and legal entities sit inside the assessed environment.
Geographic factors
These capture where data is stored, processed and accessed, including the countries where staff or contractors connect. Answers placing data or administrators in additional jurisdictions can bring in requirements tied to those locations. Confirm the hosting region of every data store, backup, log pipeline and support access path, because a backup in a second region is easy to overlook.
Technical factors
These cover the architecture: on-premises or public cloud, internet-facing applications, APIs, mobile access, wireless networks and the use of containers or AI components. Moving in-scope systems to public cloud or adding internet-facing services commonly adds technical requirement statements. Walk through the architecture diagram and confirm each component against the scope you intend to certify.
General factors
These capture broad operating conditions such as outsourced operations, the use of mobile devices and the data types handled. They are answered once and tend to shape many requirements at once. Confirm the data classes actually processed, for example health information, payment data or personal identifiers, and whether any service provider touches that data.
Optional compliance factors
These add requirements when a regulation or contract applies to the environment, such as a privacy law or a sector rule the organization must meet. They differ from the core factors because they are optional and are chosen by the organization. Confirm each obligation with legal or compliance counsel and record which source it comes from, since each one you add needs its own written rationale if answered No.
Factor changes after certification
Changing a factor answer after certification is a significant change under HITRUST rules, so the answers you give at scoping carry forward into the life of the certification. Review factor answers whenever a new data type, region or architecture is planned, and route the change through your assessor and HITRUST before work starts.
What a combined e1 or i1 does instead of tailoring
An e1 or i1 cannot be tailored into a different requirement set for certification. The requirement statements you are tested against are fixed by the assessment, and only the r2 builds a tailored set from your factor answers. What an e1 or i1 can do is add compliance factors to form a combined assessment. Each added factor produces an Insights Report for an authoritative source, so you can show how your controls map to that source without changing what the certificate covers. The Handbook states that certification still counts only the core requirement statements, so the report is additional information, not an extra certified scope.
Before you submit a combined assessment, confirm the current process for each factor. The Handbook describes an Insights Report credit that must be obtained for each factor before submission, and the mechanics of purchasing and applying those credits in MyCSF can change between CSF versions. Ask HITRUST directly how credits are counted for your assessment type, and ask your External Assessor how the Insights Report findings will be reviewed alongside the core testing. Get both answers in writing before you plan fieldwork, since a factor added late may not fit the window you have booked.
Treat the combined option as a reporting decision, not a scope decision. If a customer or regulator asks whether your certificate covers a particular source, the honest answer is that the certificate covers only the core requirement statements, and the Insights Report shows the mapping for the factor you added. Document that distinction in the assessment letter and in your sharing materials, so a relying party does not read an Insights Report as proof that every requirement of that source is certified. If the source needs tailored requirement statements in the certified set, the r2 is the route, not a combined e1 or i1.
When to choose an r2 with tailoring or a combined e1 or i1
Choose an r2 with tailoring when a customer or contract requires a certified assessment that reflects your specific risk profile, such as the data you hold, where you operate, how your technology is built or which compliance obligations apply to you. The r2 starts from the 182 i1 requirement statements and adds requirements based on your answers to the scoping questionnaire in MyCSF. The certificate covers the requirement statements generated from those answers, so a buyer reading it is learning which factors you were assessed against.
- Answers decide scope: Your responses on organizational, geographic and technical factors, plus any optional compliance factors, generate the requirement set. Answer them before you commit to a scope.
- Written rationale for No answers: Any factor answered No needs a documented reason. Assessors and QA will look at these rationales.
- Privacy is available only here: Only the r2 can be tailored to include privacy requirements, so choose it when privacy obligations are part of the request.
- Two-year term with an interim: An r2 certification lasts two years, and an interim assessment is due in the 90 days before the first anniversary.
- Factor changes are significant changes: Changing a factor answer later can require you to report it as a significant change, so plan the factors around the systems you expect to run for the full term.
Confirm with the requester which factors they care about before you answer the questionnaire, and ask your assessor how each No answer will be reviewed.
Choose an e1 or i1 when the requester needs independent validation of a defined baseline rather than a tailored r2. The e1 has 44 requirement statements and the i1 has 182 in v11.9, and each is a one-year certification. The e1 and i1 are traversable: every e1 requirement is in the i1 and every i1 requirement is in the r2 baseline, so a team that starts with an e1 can move up without rebuilding its controls. The e1 and i1 cannot be tailored to add privacy, which is the main limit to weigh against the r2.
- Fixed requirement set: The e1 and i1 do not generate requirements from your factor answers, so the scope of the certificate is the same for every organization at that level.
- Annual recurrence: Both certifications last one year, so the full validated assessment repeats every year rather than an interim check at year one.
- Compliance mapping through add-ons: If the requester also wants mapping to other sources, an e1 or i1 can add compliance factors, which is covered in the next tab.
- Upgrade path: Because the levels nest, moving from an i1 to an r2 later keeps the work you have already done, though the r2 adds tailored requirements on top.
- Cost driver: Effort depends on how many requirement statements you must evidence and how many systems are in scope, so ask for the scope and requirement count in any quote.
Before choosing, check with the requester whether they accept a one-year term and whether they need privacy coverage, since those two points usually decide between this option and the r2.
Choose a combined e1 or i1 when a regulator or contract names several authoritative sources and you need to show how your controls map to each one. A combined assessment adds compliance factors to the e1 or i1 and produces an Insights Report for each authoritative source. The certification itself still counts only the core requirement statements, so the mapping is a reporting layer over the validated baseline rather than a larger certificate.
- Insights Report per source: Each compliance factor you add produces its own Insights Report, which is what the regulator or customer reads for that source.
- Credit before submission: Each factor needs an Insights Report credit before you submit the assessment, so account for these in your planning.
- Certification scope stays core: The certificate covers the core requirement statements only, so do not present it as proof that every named source is certified.
- One-year cycle: The combined assessment renews annually with the e1 or i1 term.
- Confirm the source list early: Ask the regulator or contract owner exactly which sources they require, because each added factor affects the reports you must produce.
Ask the requester whether they need the Insights Reports or the certificate itself, since a combined assessment may satisfy the first without fully meeting the second.
Why changing a factor answer later is a significant change
A changed factor answer can change the requirement set your certificate was issued against, so treat it as a significant change, not an administrative edit. HITRUST's Assessment Handbook lists changing a factor answer among its examples of significant changes, next to moving from on-premises to public cloud, replacing in-scope applications, changing service providers, and acquisitions and mergers. The reason is structural. An r2 generates its tailored requirement statements from the scoping questionnaire, so an answer that flips from No to Yes (for example, adding a geographic factor or a compliance factor) can add requirement statements that were never tested, while an answer that flips the other way can remove statements that were. Either movement changes what the certificate actually covers, and the validity of the current certificate depends on that coverage remaining accurate.
The practical step is to document every factor decision before submission: who answered each factor, the business and system facts behind it, and the written rationale that the Handbook requires for any answer of No. Keep that record with the scope documents, the MyCSF questionnaire export and the assessor's correspondence, so that a later reviewer can see why each requirement statement was in or out. Before you change any answer during the certification cycle, raise it with your External Assessor and check the handling with HITRUST, since they decide whether the change is significant and what it means for your interim assessment. Confirm the current process and any notification timing in the Handbook and with HITRUST directly, rather than assuming a change can be made quietly.
Factor mistakes that create rework or failed QA
Most r2 tailoring problems start in the scoping questionnaire, not in the controls. The mistakes below share a root cause: factor answers are treated as a paperwork step instead of a record of how the organization actually operates, so they drift away from the evidence assessors later test.
Answering factors without system owners
Factor questions about data types, user populations, hosting and integrations are answered by whoever holds the questionnaire, often a compliance lead working from memory. Business and system owners know which datasets are actually processed and which services sit behind each application. Involve them before anyone clicks an answer, and record who confirmed each factor. Answers given without that input tend to generate requirement statements that do not match the environment, which surfaces later as N/A rationales or evidence that cannot be produced.
Leaving No answers unexplained
Any factor answered No requires a written rationale in MyCSF. Teams often select No for speed and add a short note later, or leave the rationale generic, such as saying the factor does not apply. Write each rationale as a specific statement tied to the system, data flow or contract that makes the factor irrelevant, and have the owner sign off. Vague rationales are a common reason QA questions the tailored scope, because an assessor cannot test an answer the organization cannot justify.
Scoping geography and technology from memory
Geographic and technical factors decide which requirements apply, including where data is stored, which regions and facilities are used, and which platforms and endpoints are in use. Answers drawn from memory tend to omit shadow services, backup locations and recently added cloud accounts. Build the answers from the current asset inventory and cloud account lists, then reconcile them against the scope letter and network diagrams. An inventory that is out of date at scoping will produce a tailored requirement set that misses real systems.
Changing answers without a significant change review
Factor answers can drift between scoping and fieldwork, for example when a team moves a workload to public cloud or adds a new data type. HITRUST lists changing a factor answer among its examples of significant changes, so the change must be assessed rather than quietly updated. Keep a dated log of every factor edit, the reason for it and the approval, and check whether the change affects the scope letter or the assessment. Unrecorded edits are the kind of inconsistency that undermines confidence in the whole submission.
Treating combined factors as free additions
Teams sometimes add compliance factors to an e1 or i1 without planning for the extra work. Each added factor needs an Insights Report credit before submission, and the certification still counts only the core requirement statements. Confirm which authoritative sources are wanted and what credits they need before the factor list is locked, so the combined assessment does not stall at submission.
Who decides each factor answer, and who validates it
This table shows which party owns each step from answering the r2 scoping questionnaire to receiving the outcome. Read it as a chain of responsibility: the organization decides, system owners supply facts, an implementation partner prepares evidence, and only the independent assessor and HITRUST issue results.
| Decision point | Who owns it | What they must produce |
|---|---|---|
| Factor answers (general, organizational, geographic, technical) | Leadership or compliance lead | Final Yes or No answer for each factor in MyCSF, with the reasoning on file |
| Written rationale for any factor answered No | Compliance lead, reviewed by the risk owner | Dated written rationale that explains why the factor does not apply |
| Facts behind technical and data factors | System owners and data owners | Accurate descriptions of platforms, data types, user counts and hosting locations |
| Optional compliance factors and combined e1 or i1 choices | Compliance lead with legal or privacy input | Decision on which authoritative sources to add and which Insights Reports to credit |
| Documentation of the chosen requirement set | Implementation partner, working for the organization | Mapped policies, procedures and evidence aligned to the tailored statements |
| Evidence preparation and remediation | Control owners, supported by the implementation partner | Evidence that meets the assessor's sampling and dating rules for each statement |
| Testing of the tailored requirement set | Independent External Assessor | Fieldwork results, scoring and the validated assessment submitted for review |
| Quality assurance and certification outcome | HITRUST | Central quality assurance review and the report or certification decision |
Questions teams ask about r2 tailoring
Can we change a factor answer after we submit the r2 scoping?
Changing a factor answer after it has shaped your requirements is treated as a significant change, so it should not be done quietly. HITRUST lists changing a factor answer among the events that can trigger a significant change, which affects how your certification is maintained. Because the answers generate your tailored requirement statements, a change can add or remove requirements from scope. Before you change anything, confirm with your External Assessor and HITRUST how the change will be reported and whether it affects your current assessment or your next one. Work through the reasoning in the HITRUST Assessment Handbook and record each decision in MyCSF.
Can a combined e1 or i1 replace an r2?
No. A combined e1 or i1 adds compliance factors to produce an Insights Report for each authoritative source, but certification still counts only the core requirement statements of the e1 or i1. An r2 is built from the 182 i1 requirement statements plus additions driven by your organizational, compliance and system risk factors, and it is the only validated assessment that can be tailored to include privacy. If a customer or regulator requires a certification scoped to the r2 factors, a combined e1 or i1 will not satisfy that requirement. Ask the customer exactly which assessment and which factors they expect before you choose.
Can r2 tailoring add privacy requirements?
Yes. Only the r2 can be tailored to include privacy, because the e1 and i1 cannot be extended that way. The privacy domain is reached through the r2 scoping questionnaire, which generates the requirement statements that apply to your data and geography. If privacy obligations matter to your customers, decide early whether you need the r2 at all, since choosing the wrong assessment type later means a new assessment. Confirm the privacy requirements that your factor answers produce with your assessor before fieldwork is planned.
Who must sign off on a No answer in the r2 scoping questionnaire?
Every factor answered No needs a written rationale, and that rationale should be reviewed by the people accountable for the risk it touches. In practice this usually means the security or compliance owner who maintains the control environment, with input from system owners and legal or privacy staff for compliance factors. HITRUST does not expect a single named approver, but the rationale must be specific enough for an assessor to test. Record who reviewed it, the date and the evidence behind the answer, because an unsupported No is a common point of challenge. Confirm your sign-off expectations with your External Assessor before you submit.
How long does r2 factor scoping take?
The time depends mainly on how many systems, locations and compliance obligations you have, and on how quickly your team can answer each factor with supporting facts. The questionnaire is completed in MyCSF, so the work is partly data gathering: confirming hosting models, data types, user counts, geographies and which regulations apply. No duration for this step is set in the researched sources, so confirm the expected effort with HITRUST and your External Assessor, and plan from the steps they give you. Also check whether your answers will change if your scope or environment changes before fieldwork.
Can our own team do the r2 scoping without a consultant?
Often yes, because the scoping questionnaire is completed by the entity in MyCSF. An internal team that knows its systems, data flows and regulatory obligations can answer most factors directly. A consultant or readiness provider can help with the harder questions, such as whether a No answer is defensible or how a factor affects requirement statements. What no one outside the organization can do is issue the assessment result: only an Authorized HITRUST External Assessor performs the validated assessment, and HITRUST performs quality assurance before issuing the report. Ask any outside party to show you the exact work they will deliver, and keep ownership of the answers and rationales in-house.
What happens to our tailored requirements when our hosting changes?
A move such as shifting from on-premises infrastructure to public cloud is one of HITRUST's listed examples of a significant change, and it can change the factor answers that generated your requirement statements. Before the move, review every factor that describes technology, hosting and service providers, because a change can add requirements or alter which controls are inherited from a provider. Check with your assessor whether the change requires reporting to HITRUST and whether your existing r2 remains valid. Document the decision and the impact analysis in MyCSF so the history is traceable.
How do the factors relate to the 19 assessment domains?
The factors do not replace the domains; they decide which requirement statements sit under each domain for your assessment. Each domain is scored from the requirements that remain in scope, so a factor answer that adds or removes a requirement can change how a domain is scored. This is why an answer given during scoping has effects far beyond the questionnaire itself. Review the domain-level impact of your answers with your assessor before fieldwork, and use the HITRUST framework page to understand how the CSF is organized.
How DeployOpen works on this
DeployOpen helps organizations turn their r2 factor answers into a documented requirement set and the systems and evidence that match it. We plan and implement self-hosted open-source platforms inside your own infrastructure, then prepare the controls and evidence for the independent assessor, who alone performs the validated assessment and issues any report.
How we scope
- We review your MyCSF factor answers with you before any build work starts, so the requirement set matches your real environment.
- Each factor answered No is documented with a written rationale that your team and assessor can read.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
How we build
- We implement and harden the self-hosted platforms that the in-scope requirement statements depend on, inside your cloud, data center or air-gapped network.
- We configure logging, access controls and backups so the evidence they produce matches the requirement statements and their dates.
- We document where each platform supports a requirement, so your team can trace controls to their owners.
How we hand over
- You receive system documentation, control descriptions and an evidence map linking each in-scope requirement to its source.
- We flag any factor change, new compliance obligation or platform replacement that could trigger a significant change to review with your assessor.
- Your team keeps administrative ownership of the platforms, configurations and evidence repositories after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, covering changes to factors or in-scope systems between assessments.
- Before the interim assessment or renewal, we can refresh evidence and documentation so your team is not rebuilding them under deadline.
- Questions about whether an assessor will accept a particular approach should go to the assessor, since DeployOpen does not issue reports or certifications.
