Which HITRUST CSF version deadlines affect our assessment this year?
e1 and i1 assessments created after December 31, 2026 must use CSF v11.9.0, and v11.8.0 or earlier e1 and i1 submissions close on March 31, 2027. If a customer or contract now requires HITRUST, start by checking which assessment level it names and when your assessment was or will be created in MyCSF, because those two facts decide which version applies. An e1 or i1 created before the cutoff can finish on an older version, but only if it is submitted before the March 31, 2027 deadline. An e1 or i1 created after December 31, 2026 must be built on CSF v11.9.0 from the start, even if your team has been preparing on an earlier version.
The r2 follows different rules. It does not have to use the newest CSF version, it allows no service provider carve-outs, and it can be tailored to include privacy requirements. That means an r2 already underway may be able to finish on the version it was created under, while an e1 or i1 in the same program may not. Whether work is already underway matters too: evidence gathered against one version may carry into a newer one through inheritance of maturity scores, but only where the source assessment is still active and the rules allow reuse. Confirm the exact creation date, version and inheritance status with your external assessor before you spend effort on remapping controls. The HITRUST Assessment Handbook sets out these rules in detail.
Your organization owns its controls and the decision about which version and assessment to pursue. An implementation partner can prepare systems, configuration baselines and evidence against the chosen version, but it does not decide applicability or issue results. Only an Authorized HITRUST External Assessor performs the validated assessment, and HITRUST performs quality assurance before any report or certification is issued. Ask your assessor to confirm in writing which CSF version governs your submission, the submission deadline and any emergency mitigation errata that could add requirements before fieldwork starts, so the remediation plan is built on the right baseline.
How each assessment type handles a new CSF version
This table compares how the e1, i1 and r2 treat the CSF version in use at creation, service provider carve-outs, tailoring and privacy scope. Read each row against your assessment type to see which version rules apply before you start, and note that the e1 and i1 rules tighten as deadlines pass.
| Requirement | e1 and i1 | r2 |
|---|---|---|
| Version required at creation | Must use the newest CSF version (v11.9.0 for assessments created after December 31, 2026) | Need not use the newest version |
| Service provider carve-outs | Allowed, so provider requirements can be carved out | Not allowed |
| Tailoring | Fixed baseline, with no risk-based tailoring of the requirement set | Starts from the i1 statements and adds more through risk-based tailoring |
| Privacy scope | Not included in the e1 or i1 baseline | Can be tailored to include privacy |
| Deadline for older-version submissions | v11.8.0 or earlier e1 and i1 submissions close on March 31, 2027 | Confirm the deadline for your CSF version with HITRUST or your assessor |
| Work already in progress after a new version | Confirm with your assessor whether an in-progress assessment remains on its original version or must move | Usually continues on its version, so confirm the transition rules before planning changes |
| Emergency mitigation errata | Can add requirement statements and set earlier creation and submission deadlines for older versions | Same Emerging Mitigation Process applies, so confirm which version deadlines affect your assessment |
| Inheritance across versions | Maturity scores from another active validated assessment can be reused across CSF versions | Maturity scores from another active validated assessment can be reused across CSF versions |
What CSF v11.9.0 changed for e1 and i1 baselines
CSF v11.9.0 changed what the e1 and i1 baselines contain, so any assessment that will be created after December 31, 2026 has to be scoped against the new set. HITRUST released v11.9.0 on September 24, 2026, and according to its release advisory it refreshed the NIST SP 800-53 Rev. 5.2.0 mapping, added the OWASP Top 10 for Agentic Applications 2026, and refreshed technology-specific requirements covering PKI, TLS and passkeys. It also added considerations for post-quantum cryptography. In v11.9.0 the e1 contains 44 requirement statements and the i1 contains 182. Read the HAA 2026-005 release advisory for the full list of changes before you plan the work.
The two levels feel these changes differently. Every e1 requirement is also in the i1, and every i1 requirement is also in the r2 baseline, so a new or revised statement at the i1 level usually carries into the r2. The r2 starts from the 182 i1 statements and then adds requirements through risk-based tailoring, so its final count depends on your own risk decisions rather than on the baseline alone. An e1 or i1 holder that moves to r2 later will therefore inherit the v11.9.0 changes as well. The r2 also does not have to use the newest CSF version, which gives it more flexibility than the other two levels.
Before you scope anything, export your current control set and compare it line by line with the v11.9.0 baseline in MyCSF. Look first at TLS and certificate management, PKI, passkey or MFA enrollment, and any system that uses cryptography that may need a post-quantum plan. Mark each new or changed statement as already met, partly met or not met, and name an owner for each gap. Where a statement is covered by a provider's assessment, confirm whether that provider's result was produced under v11.9.0 or an earlier version, because the version it was tested against determines whether it can be reused. Ask your assessor to confirm how they will treat these statements before fieldwork begins.
How to check which deadline applies to your assessment
This sequence turns the v11.9.0 transition and the March 31, 2027 e1 and i1 close into a written decision on which CSF version your next assessment must use, and when you need to act. Work through it before you commit to a creation date with your External Assessor.
Confirm the assessment type you need
Decide whether your next validated assessment is an e1, an i1 or an r2, based on the assurance your customers, contracts or regulators require. Your compliance lead owns this decision, and your External Assessor can confirm whether the scope fits the level you choose. The step is done when you have a written statement naming one assessment type and the reason for it. If you are unsure, compare the requirement counts for each level in the current version before deciding, since the e1 and i1 baselines changed in v11.9.0.
Compare the planned creation date with December 31, 2026
Take the date you plan to create the assessment in MyCSF and check whether it falls before or after December 31, 2026. For e1 and i1 assessments created after that date, the CSF version must be v11.9.0. Your compliance lead records the planned creation date and the resulting version requirement in the assessment plan. The step is done when the plan states the required CSF version for that creation date.
Check for e1 or i1 submissions already in flight
Review any e1 or i1 assessment that is already underway and confirm whether it was built on v11.8.0 or earlier. Submissions on those versions close on March 31, 2027, so an assessment that is not yet submitted may need to be accelerated or re-scoped. Your External Assessor should confirm the status of each open assessment in writing. The step is done when you have a list of open e1 and i1 assessments, their CSF versions and their submission status against the March 31, 2027 close.
Identify work that can be inherited
Determine whether results from another active e1, i1 or r2 validated assessment, either your own or a provider's, can be reused in the assessment you plan. Inheritance can carry maturity scores across CSF versions, but readiness or incomplete assessments can only be inherited into readiness work. Your architects and assessor should map each candidate result to the requirement statements it covers. The step is done when you have a written inheritance decision for each area, naming the source assessment and the version it was scored on.
Confirm exact dates with your assessor and HITRUST
Verify the creation and submission deadlines directly with your Authorized HITRUST External Assessor and with HITRUST, and do not rely on this page for dates. Ask for written confirmation of any deadline that affects your plan, including any emergency mitigation errata that could set new deadlines for older versions. The step is done when you hold written confirmation from both parties and have filed it with the assessment plan.
Record the version decision in the assessment plan
Bring the outputs of the previous steps together into a single written decision that names the assessment type, the CSF version, the creation and submission dates, any open e1 or i1 deadlines and the inherited results. Your compliance lead owns the document and your assessor reviews it before creation. The step is done when the signed decision is stored with your assessment records and the team has confirmed it can start the assessment on the stated version.
What a version change means for your situation
If your e1 or i1 assessment has not been created yet, the creation date decides which CSF version you must use. Assessments created after December 31, 2026 must use v11.9.0. Assessments created earlier can still use v11.8.0 or earlier, but those submissions close on March 31, 2027, so the work has to finish well before that date. Readiness is the stage where a version change costs the least, because you can still re-map evidence before testing begins.
- Creation date sets the version: Confirm the date your assessment is created in MyCSF and whether it falls before or after December 31, 2026.
- Submission deadline for older versions: If you stay on v11.8.0 or earlier, plan to submit before March 31, 2027.
- Refreshed technical requirements: v11.9.0 refreshed requirements for PKI, TLS and passkeys and added post-quantum cryptography considerations. Review your evidence for these areas now.
- Baseline changes: The e1 has 44 requirement statements and the i1 has 182 in v11.9.0. Map your current controls against those counts.
- Inheritance limits: Readiness or incomplete results can only be inherited into other readiness assessments, so do not count on them for a validated assessment.
Before you commit to a version, ask your assessor to confirm the creation and submission dates that apply to your specific record in writing.
An assessment already in fieldwork is in a different position. The version is generally fixed once the assessment exists, and the assessor's validated fieldwork window is at most 90 days. The main risk at this stage is not a new deadline but a late change that disrupts evidence you have already collected. Treat any version question as a conversation to have with your assessor and HITRUST before testing moves forward, not as something to assume.
- Fixed version: Do not assume you can switch an in-flight assessment to a different CSF version without confirming it is permitted.
- Fieldwork window: The validated fieldwork window is at most 90 days, so schedule evidence delivery around it.
- Emergency mitigation errata: If HITRUST adds requirement statements through its Emerging Mitigation Process, it also sets creation and submission deadlines for older versions. Watch for these notices.
- Scope review: Ask whether any newly added statements touch systems already in scope or require new evidence.
- Submission timing: If your assessment uses an older version, confirm it will be submitted before the March 31, 2027 close date.
Ask your assessor to confirm in writing which version your assessment uses, the submission date and whether any errata affect your record.
An r2 certification lasts two years, and the interim assessment must be submitted in the 90 days before the first anniversary. The r2 has more version flexibility than the e1 or i1. It does not have to use the newest CSF version, and it does not allow carve-outs. For most r2 holders, the version decision is about timing and effort rather than a hard deadline, since the r2 can stay on its current version where that is permitted.
- No forced upgrade: The r2 need not use the newest CSF version, so you can keep your current version through the interim or recertification if your assessor agrees.
- Interim window: The interim submission window falls in the 90 days before the first anniversary, so plan the evidence refresh around that period.
- Cross-version inheritance: Maturity scores from another active e1, i1 or r2 can be inherited across CSF versions, which can reduce retesting of unchanged controls.
- Upgrade decision: Moving to v11.9.0 picks up refreshed technical requirements such as TLS and passkeys. Decide whether that effort is worth taking at recertification.
- Errata awareness: Emergency mitigation errata may add statements and set deadlines for older versions, so check each HITRUST notice against your current version.
Before your interim window opens, confirm with your assessor which version the next submission will use and which of your scores you can inherit.
An organization planning its first HITRUST assessment should decide the assessment level and the CSF version together, because the rules differ by level. An e1 or i1 must use the newest CSF version at creation, which means v11.9.0 for any assessment created after December 31, 2026. An r2 can use an older version if the assessor agrees and can be tailored, including to add privacy. Choosing the level first, then the version, keeps the scope and evidence plan consistent.
- Version at creation: An e1 or i1 created after December 31, 2026 must use v11.9.0, so build evidence to that version from the start.
- Level choice: The e1 and i1 allow service provider carve-outs, while the r2 allows none. That changes how much you can rely on vendor results.
- Tailoring for r2: An r2 can add requirement statements through risk-based tailoring, so decide early whether privacy belongs in scope.
- Authorized assessors: Only Authorized HITRUST External Assessor organizations can perform validated assessments submitted for certification. Confirm your firm's status before you sign.
- Quoted scope: Ask any implementation partner and assessor to state, in a written scope, which CSF version their work assumes and what happens if the version changes.
Before you sign, confirm the CSF version, the assessment level and the assessor's authorization in writing so the plan does not depend on assumptions.
Can results carry over across CSF versions?
Yes, in many cases. Inheritance reuses maturity scores from another active HITRUST e1, i1 or r2 validated assessment, whether that assessment is your own (internal) or belongs to a provider (external), and the reuse works across CSF versions. That makes an existing validated assessment a starting point for the next one rather than a fresh start, but it does not mean scores transfer automatically or without review. Confirm the source assessment is still active, identify which requirement statements you plan to inherit, and record which CSF version each inherited score came from before you open a new assessment.
Inheritance has a firm limit. Readiness assessments and incomplete assessments can only be inherited into readiness assessments, so a half-finished validated assessment cannot supply scores to a certification. Teams preparing for a new validated assessment should not plan around scores from a readiness exercise, even if that exercise looked complete internally. Ask your assessor early which of your candidate scores qualify, since this is the decision that most often removes work from the plan.
A version change still requires a check. Compare each inherited requirement against the new baseline, because a refreshed CSF can add, reword or retire requirement statements, and a score earned against older text may not map cleanly to the current one. In v11.9.0, for example, technology-specific requirements such as TLS and PKI were refreshed, so those statements deserve particular attention. Document the mapping for every inherited requirement, flag any that changed in substance, and send that list to your external assessor. The assessor makes the final call on what carries over, and that decision belongs to them, not to your internal team or a consultant.
How emergency mitigation errata can shift deadlines
HITRUST can change the rules for assessments already in progress without warning, because an urgent threat may need a control the CSF does not yet contain. The four cards below cover what triggers an errata, what it adds, how older-version deadlines are set and how to keep a plan flexible.
What triggers an errata
HITRUST's Emerging Mitigation Process starts when it finds an urgent threat that has no existing mitigation in the CSF. The trigger is a gap in the framework, not a scheduled release cycle, so an errata can arrive between regular versions. Your assessor and your own threat intelligence feeds are the places where early signals of such a gap usually appear. Ask your assessor how HITRUST notifies assessed organizations of an errata and which channel your team should monitor.
What an errata adds
An errata adds new requirement statements to the CSF rather than rewriting existing ones. Those statements apply to the version they are released against, so a control you already tested may now have a companion requirement that asks for a specific mitigation. Read the added statements against your current scope and evidence before the next fieldwork window. Confirm with your assessor whether an added statement changes the scope of an assessment already in progress.
How older-version deadlines are set
When an errata is released, HITRUST sets creation and submission deadlines for older CSF versions. Those deadlines can be earlier than the normal assessment calendar would suggest, so an e1 or i1 team that planned around a later date may need to move its fieldwork forward. Confirm the exact creation and submission dates in the HITRUST advisory that accompanies the errata, and record them in your assessment plan as fixed dates rather than estimates.
Keeping the plan flexible
A plan stays flexible when the team knows which CSF version each assessment is built on, which requirements depend on a single control owner, and how much evidence collection is still open. Build a short checklist that lists the version, the creation deadline and the submission deadline for each assessment, then review it whenever HITRUST publishes an advisory. Ask your readiness partner or assessor to estimate how much rework a new requirement would require before you commit to a fieldwork date.
How the version update work runs from planning to submission
The sequence turns a new CSF version into a validated assessment that an Authorized HITRUST External Assessor can submit and HITRUST can accept. Each phase produces a document or check that the next phase depends on.
Confirm the version and deadline for your assessment
Start by confirming which CSF version your assessment type must use, based on its creation date and the deadlines HITRUST has published for e1 and i1 submissions. The owner is usually the compliance lead, working with the external assessor to agree the assessment type and creation window. The output is a written decision record naming the CSF version, the assessment type and the submission deadline you are working to. Confirm the current dates in the HITRUST advisories directly, since deadlines for older versions can change.
Run a gap analysis against the new version
Compare the requirement statements of the target version with the version your current controls were mapped to, and list every added, changed or removed statement that applies to your scope. Security and compliance engineers do the mapping, with system owners confirming how each change touches their platforms. The output is a gap register that lists each affected requirement, the current evidence, and whether the gap is a new control, a changed procedure or a documentation update. Treat the register as the scope of all later work.
Assign owners and update control design
Each gap is assigned to a named owner who changes the control design, configuration or procedure where the new statement requires it. Platform engineers typically handle configuration changes on self-hosted systems, while policy owners update the governing documents. The output is a revised control set with change tickets, approved policy text and a record of what changed and when. Controls that did not change should be recorded as unchanged so the assessor can see the decision.
Collect and refresh control evidence
Owners gather fresh evidence for every updated control, such as configuration exports, access reviews, change records, test results and logs covering the period the assessor will examine. Evidence from earlier versions can be reused only where the requirement wording still matches. The output is an evidence index that maps each requirement statement to its artifacts, dated and stored in a location the assessor can reach. Gaps in evidence are logged back into the gap register.
Test readiness against the new requirements
Before the assessor arrives, internal reviewers test a sample of updated controls against the requirement statements, following the same logic the assessor will apply. The reviewers are often independent of the control owners, and a readiness consultant can perform this step if the organization has no internal capacity. The output is a readiness report listing each requirement as met, partially met or open, with corrective actions for every open item. Confirm that the readiness work stays separate from the validated assessment itself.
Submit the assessment through an authorized assessor
The organization engages an Authorized HITRUST External Assessor, which performs the validated assessment and submits it for certification. The assessor runs fieldwork within the fieldwork window of at most 90 days, tests the evidence and records its findings and scores. The output is a completed validated assessment package submitted to HITRUST in the required format, with the assessor's own working papers retained for review. Ask the assessor to confirm the submission date against the deadline in your decision record.
Receive HITRUST quality assurance and the report
HITRUST performs central quality assurance on the submitted assessment before it issues a report or certification. HITRUST may ask the assessor for clarification or additional support, and the organization responds through the assessor. The output is the issued HITRUST report and certification, which the organization then shares with customers and relying parties. Only HITRUST issues the certification, so an internal or consultant-prepared summary should never be presented as one.
What to have in place before you move to the new version
Moving an assessment to a new CSF version is mostly a planning exercise. The four items below decide whether your team can choose the right version, scope the work correctly and meet the creation and submission rules without rushing.
Control inventory mapped to your version
Start with a current list of every requirement statement your assessment uses, tied to the CSF version you are running today. Note which requirements were refreshed in the newer version, such as technology-specific areas for PKI, TLS and passkeys, and which are unchanged. Check each entry against an owner, a system and the evidence you hold. The gaps you find here are the work that the new version will require, so this list also becomes your effort estimate for the update.
Carve-out and inheritance decisions
List every system, cloud platform and service provider that touches the scope, and record whether each one will be carved out, inherited from another active validated assessment, or tested directly. Carve-outs are available for e1 and i1 but not for r2, so the choice of assessment level changes the answer. Confirm that any inherited score comes from an active HITRUST assessment and that the provider's report still covers the new version. Ask each provider when they plan to move to the newer version.
Dated plan tied to deadlines
Build a calendar that works backward from the creation and submission rules. An e1 or i1 created after December 31, 2026 must use the newest version, and submissions on older versions close on March 31, 2027. Set internal dates for scope sign-off, readiness testing, evidence collection, assessor engagement and fieldwork. Fieldwork runs for at most 90 days, so the plan should leave room for the assessor to start and finish inside the window. Confirm each date with your assessor and HITRUST before you commit.
Named owners for each evidence set
Assign one accountable owner to each control area, and a backup, before the update starts. The owner confirms that evidence is current, matches the requirement text in the new version, and can be produced on request during fieldwork. Record where each artifact is stored and how often it refreshes. Owners should also flag any technology-specific requirement they cannot yet evidence, so the gap reaches the plan early instead of during testing.
Where DeployOpen fits when the CSF version changes
DeployOpen prepares your systems and evidence for a HITRUST CSF version change, but it does not issue HITRUST reports, certificates or inheritance decisions. When a new CSF version such as v11.9.0 changes the e1 or i1 baseline, the practical work sits with your team and your implementation partner: mapping changed requirement statements to the self-hosted open-source platforms you run, updating configurations and retained evidence, and preparing documentation the External Assessor can test. DeployOpen plans and implements those platforms inside your own cloud accounts, data centers or air-gapped networks, so the controls and records are yours from the start. Authorized HITRUST External Assessors perform the validated assessment, and HITRUST performs quality assurance before any report is issued.
Several decisions stay with you and your assessor. Confirm with your assessor which CSF version applies to your assessment, whether it was created before or after December 31, 2026, and which deadline governs your submission, since v11.8.0 or earlier e1 and i1 submissions close on March 31, 2027. Whether a service provider requirement is carved out, and whether inherited maturity scores from a cloud provider or another assessment are accepted, are determinations made by the assessor under HITRUST rules, not by DeployOpen. Ask your assessor to confirm those positions in writing before implementation work begins, so the scope reflects what will actually be tested.
Most engagements are fixed-scope. Before work starts, agree in writing which platforms, requirement statements, documentation and assessor support are included, along with deliverables and timelines. A quote follows from that written scope, and DeployOpen does not publish a price list. Ask for the quote to separate one-time work, such as remapping evidence to the new version, from recurring work such as retainers for upgrades and ongoing support. If the assessor later requests changes, confirm whether they fall inside the agreed scope or require a new one.
Questions buyers ask about HITRUST version deadlines
Does an e1 in progress have to move to the newest HITRUST CSF version?
It depends on when the assessment was created. Under HITRUST's advisory, e1 and i1 assessments created after December 31, 2026 must use CSF v11.9.0, which was released on September 24, 2026. Assessments created on v11.8.0 or earlier can still be submitted until March 31, 2027, so an e1 already in progress on an earlier version has a fixed submission deadline rather than an immediate switch. The driver is the creation date, not the date you submit. Ask your authorized assessor to confirm the creation date recorded in MyCSF and the deadline that applies to your assessment. Engineers should also check whether v11.9.0 changes the technical requirements for PKI, TLS or passkeys that apply to the systems in scope, because those changes affect the work plan even when the version stays the same.
Must an r2 assessment use the newest CSF version?
No. An r2 does not have to use the newest version. The e1 and i1 must use the newest CSF version at creation, but the r2 allows that flexibility, so the organization can choose a version that fits its renewal calendar, its readiness work and its customer commitments. That flexibility sits alongside other r2 rules: the r2 allows no service provider carve-outs and can be tailored to include privacy requirements. Version choice is therefore one scoping decision among several. Confirm with your assessor which version their plan supports and whether the timing of any tailoring or privacy inclusion depends on it. Keep in mind that a later move to a newer version still requires review of new and changed requirement statements, so a deliberate version choice should include a plan for the next cycle.
How does inheritance work when the CSF version changes?
Inheritance reuses maturity scores from another active HITRUST e1, i1 or r2 validated assessment, whether that assessment belongs to your organization (internal) or to a provider (external). The reuse works across CSF versions, so a provider's assessment on an earlier version can support your assessment on a newer one, subject to the assessor's review of what the inherited scores actually cover. Readiness assessments and incomplete assessments can only be inherited into readiness assessments, which means a provider's work-in-progress cannot stand in for a validated result. In practice, your shared responsibility matrix must match each inherited requirement to the provider's scope, and the provider's assessment must be active. Ask the provider for the version, validity dates and scope statement of its assessment before you plan around it. Whether a specific score carries over is the assessor's determination.
What does an emergency mitigation errata mean for a current assessment?
When HITRUST identifies an urgent threat that the CSF has no existing mitigation for, its Emerging Mitigation Process adds requirement statements in an errata release. The same process sets creation and submission deadlines for older CSF versions, so an errata can affect both the content you must test and the window in which your version remains usable. For an assessment in progress, the practical questions are which new statements apply to your systems, whether you can produce evidence for them within your fieldwork window and whether your version's deadlines still allow submission. Illustrative example: if an errata added a statement about a specific authentication control, the team would need to identify the systems that control affects, configure them, and collect evidence before testing starts. Confirm with your assessor which errata release applies, its deadlines and whether your in-flight assessment is affected.
What does a version update require from our internal team?
A version update is mostly a mapping and evidence exercise, and it needs four types of work from internal staff:
- A gap review of new and changed requirement statements against current controls, including v11.9.0 items such as PKI, TLS, passkeys and post-quantum cryptography considerations.
- Named evidence owners for each changed statement, with the artifacts and sampling periods the assessor will request.
- Configuration and documentation changes in the in-scope systems, tracked through normal change management.
- Updates to the shared responsibility matrix and inheritance records so provider and internal responsibilities still match.
Decision-makers also need to approve scope and budget and to decide the version and timeline. The effort depends on how many statements changed for your scope and how much evidence already exists. Ask your assessor to walk through the changed statements that apply to your scope before you estimate internal time.
Can an implementation partner handle the version update alone?
A partner can prepare the systems, controls and evidence for the update, but it cannot issue the assessment or certification. Only Authorized HITRUST External Assessor organizations perform validated assessments submitted for certification, and HITRUST performs central quality assurance before it issues reports. Your organization still owns its controls, decides its scope and accepts its risk. DeployOpen plans, implements, documents and supports self-hosted open-source platforms in your own infrastructure, and it prepares systems and evidence for compliance assessments, but it does not issue reports or certificates. Engagements are usually fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask any partner in writing which statements it will update, what evidence it will produce, who signs off on that evidence and which assessor will perform the validated assessment.
How long is the assessor's fieldwork window for e1, i1 and r2?
The assessor's validated assessment fieldwork window is at most 90 days for e1, i1 and r2 assessments, according to the HITRUST Assessment Handbook. That figure is a ceiling on the fieldwork period, not the length of your whole project. Preparation, readiness testing, evidence collection and corrective work before fieldwork all take time that the window does not cover, and that preparation is where most version-update effort sits. A version change does not automatically change the fieldwork ceiling, but the new statements it adds can extend the preparation period. Ask your assessor to confirm how the fieldwork window will be scheduled against your version deadline, and which evidence should be ready before the window opens so the 90 days are spent on testing rather than on collection.
How DeployOpen prepares your systems and evidence for a version update
A new HITRUST CSF version can change which requirement statements apply to an assessment you have already started. DeployOpen works with your team to confirm which version and deadlines apply to your assessment, then prepares the systems and evidence those requirements depend on, while your organization and an authorized External Assessor keep ownership of the controls and the validated assessment.
How we scope
- We confirm which assessment you are running (e1, i1 or r2) and its creation or submission date.
- We map changed requirement statements against your current systems, configurations and documented evidence.
- Each engagement is fixed-scope, with deliverables and timelines agreed in writing before work starts.
- Our written scope states which version updates and requirement areas are covered and which stay with your assessor.
How we build
- We update technical configurations for changed areas such as TLS, PKI and passkeys within your own infrastructure.
- We implement or adjust self-hosted open-source platforms so they produce logs, access records and change history.
- We test each changed control and record results so your team can show the control working before fieldwork.
- We confirm inheritance candidates from earlier active assessments and flag where their version no longer matches.
How we hand over
- We document configuration changes, owners, and evidence locations in a handover pack your team keeps.
- We prepare evidence packages organized by requirement statement, ready for your External Assessor to sample.
- We walk your compliance and engineering staff through what changed and why, and which items remain open.
- We record any decisions about carve-outs or tailoring so the assessor can trace them to the written scope.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the initial work closes.
- We can rerun checks when a later HITRUST CSF release or an urgent emerging mitigation changes requirements.
- We help your team confirm deadlines with HITRUST directly, since deadlines depend on the assessment and its version.
- Only independent assessors issue reports or certifications. We prepare the systems and evidence for their review.
