How long must a new HITRUST control run before it can be tested?
A new or remediated control has to run before a HITRUST validated assessment can test it. The rule in the Assessment Handbook is at least 90 consecutive days in its current state, or 60 days for policies and procedures. A control that has run for 89 days does not get partial credit. The clock restarts from the date the control reached its current form, so any change to the control's design or operation during that window resets it. Confirm the start date for each changed control against its change record, not against the date someone first wrote the procedure.
The answer depends on three things: which controls changed, when each one went live, and whether a service provider already runs the control for 90 days. Controls that were stable before your current assessment cycle need no wait. Controls you rebuilt or fixed after a gap or corrective action need the full period, so map each changed requirement to its go-live evidence now. Where a provider performs the control and has run it for at least 90 days, for example for other customers, or where you inherit or rely on the provider's existing report, the wait can be avoided. Check that the provider's evidence covers the same control in its current state, because a recent redesign restarts the provider's clock too.
Work backward from the incubation dates to find your earliest fieldwork start. Fieldwork is limited to a 90-day window that ends when management signs the representation letter, so any control still incubating on that date cannot be tested as implemented. Ask your assessor to confirm in writing which controls it will treat as incubating and what evidence it needs for each. For details on how the fieldwork window and the representation letter interact, see the HITRUST Assessment Handbook.
Which clock applies to which control
A control you have built for the first time must run in its current state for at least 90 consecutive days before an External Assessor can test it as implemented. The clock starts on the date the control begins operating in its current form, not when the design was approved or the ticket was closed. HITRUST gives no partial credit for a shorter run, so a control that operated for 75 days and then changed does not count toward the 90.
- Start date: the first day the control operated as described in its final design, in production.
- Continuity: the same control must run without a material change for the full 90 consecutive days.
- Proof: dated configuration exports, system logs, tickets or approvals showing the first operating instance and each run after it.
- Overlap: the 90 days can overlap fieldwork only if testing happens after the period completes.
- Scope check: the system must be installed and operating in production with all primary scope components for the same period.
Confirm with your External Assessor how they want the start date recorded and whether they expect a log sample from the first operating week.
A remediated control is an existing control that failed, was found deficient, or was redesigned to close a gap. The same 90-day rule applies from the point the corrected control is in its current state, so a fix does not reset or shorten the wait for the rest of the program. The corrective action plan process sets how the fix is tracked, but a completed corrective action plan still has to meet the incubation rule before the control is tested.
- Clock trigger: the date the corrected version went live, not the date the gap was first identified.
- Plan records alone: project plans or tickets do not show progress. Meeting minutes, draft documents or configuration changes with change records can.
- Earlier failure: the period before the fix does not count toward the new 90 days.
- Further changes: any later change to the remediated control restarts the period if it alters how the control works.
- Documentation: the change record, approval, deployment evidence and the operating log for each day of the period.
Ask your assessor whether a remediation that changes only documentation, rather than operation, is treated as a new control or as a policy with a 60-day wait.
Policies and procedures need a shorter wait than operational controls: 60 days rather than 90. The period is about the document being in force and followed, so the clock starts when the approved version takes effect and the organization begins operating under it. A draft circulated for comment does not start the clock.
- Start date: the effective date of the final, approved version.
- Version control: each approved revision that changes the requirement can restart its own 60-day period.
- Evidence of use: acknowledgments, distribution records, and references in procedures or tickets showing staff are working to the document.
- Linked controls: a procedure that depends on a 90-day control is still bounded by that control's wait for testing.
- Approval record: signed or system-recorded approval with the version number and effective date.
Confirm with your assessor which of your documents fall under the policy wait and which are operational procedures, because the boundary can be contested for documents that describe a running process.
When a service provider performs a control on your behalf, the 90-day wait can be avoided if the provider shows the control has already run for at least 90 days. That can mean operating history for other customers, or reliance on a current assessment report that covers the control. The handbook describes this path for provider controls, so you do not have to wait for a new run inside your own environment.
- Provider history: evidence the control has run for at least 90 days, such as logs or records from other customers.
- Inheritance: using an existing provider report that covers the control and its period.
- Your own clock: the control still has to operate in your environment for the scope you are certifying, so inheritance does not remove that requirement.
- Gaps: if the provider's period does not cover the whole timeframe, the difference may need its own 90 days.
- Written agreement: the contract or responsibility matrix that states who runs the control.
Before relying on provider history, confirm with your assessor and provider which report, period and evidence they will accept, and when inheritance rules apply to your scope.
How service provider controls and inheritance avoid the wait
A control run by a service provider does not have to wait for its own 90-day clock if one of three routes applies. Each route moves the incubation evidence to someone else, so the entity still has to confirm that the provider's record fits its own scope and environment.
Provider has run the control 90 days
The first route applies when the provider shows that the control has operated for at least 90 consecutive days in its own environment, for example while serving other customers. The entity should request dated evidence from that period, such as change records, operating logs or sample tickets, and confirm the control matches the version it relies on. A provider run that was reset by a recent configuration change does not satisfy the test.
Inheriting an existing provider report
The second route lets the entity inherit or rely on the provider's existing HITRUST report for controls the provider performs. The entity must map each inherited requirement to the provider's scope statement, carve-outs and service boundaries, then confirm that the provider's system is the same one that supports its own primary scope. Ask for the report, the bridge letter covering the gap since its date, and any exceptions noted.
Provider control with an established period
The third route covers a provider control that already has an established operating period, which the provider can document independently of the entity's project. This matters most for shared platforms where the entity adopts a provider's existing process rather than building one. The entity should confirm the period is continuous, that no material change reset it, and that the control runs in production for the entity's environment.
Confirming provider scope matches yours
Inheritance only holds where the provider's control covers the same service, data flows and environment the entity uses. Compare the provider's in-scope components, regions and facilities against your own scope letter, and document where your responsibilities begin. A gap in this comparison, such as a log pipeline the provider does not cover, leaves the matching control on the entity's clock.
Ownership stays with the entity
Relying on a provider does not transfer responsibility for the control. The entity still owns its risk decisions, its evidence repository and its answers to assessor questions about how it oversees the provider. Keep a shared responsibility matrix current and review it whenever the provider changes a service, since an assessor may test the entity's oversight as well as the inherited result.
Inheritance is not automatic
Inheritance is not always accepted. Assessors can reject it when the provider's evidence is too old, the scope is unclear, or the provider's report does not test the specific requirement the entity cites. Before planning fieldwork around inherited results, ask the assessor to confirm which route they will accept, and build a fallback plan for any control whose incubation evidence cannot be produced in time.
How to work backward from the fieldwork start date
This sequence turns the 90-day incubation rule into a dated plan. You list every control and scope component that must run before testing, find the earliest date each one qualifies, and agree a fieldwork start that the assessor can accept.
Build the control change register
Start with every control that is new, redesigned or remediated since the last assessment or since the planned assessment began. Record the control reference, owner, the date the change went live, and the change record that proves it. Include controls you have not yet built, with their planned go-live dates. Work from change tickets and deployment logs, not from memory. The output is a dated control change register that your compliance lead and control owners sign off. The step is done when every row has a go-live date backed by a change record.
Separate policies and provider-performed controls
Mark which rows are policies or procedures, which carry a 60-day incubation period, and which are performed by a service provider. For provider-performed controls, decide whether the provider can show it has run for at least 90 days, for example for other customers, or whether you will inherit or rely on the provider's existing report. Ask each provider for written confirmation of run dates and a copy of the report or evidence you intend to use. The output is an incubation type assigned to every row and an inheritance evidence request sent to each provider that has a gap to fill.
Calculate the earliest qualifying date for each control
For each row, count forward from the date the control began operating in its current state. Use 90 consecutive days for standard controls, 60 days for policies and procedures, and the provider's qualifying history where a provider has shown it. Note that there is no partial credit: a control that ran for 85 days does not qualify until it reaches the full period. Any control that changes during its incubation period restarts the clock, so freeze the design before you count. The output is an earliest qualifying date column in the register. The step is done when a second reviewer has recalculated a sample of rows and matched the dates.
Confirm scope components have run in production
HITRUST certifies only implemented systems that are installed and operating in production, with all primary scope components in place for at least 90 days. Check each primary component against your scope statement and record the date it entered production. Components that went live late set the earliest date for the whole system, so flag them early. Where the 90-day period can overlap with fieldwork, note the overlap window, but confirm it with the assessor rather than assuming it. The output is a scope readiness log showing each component's production date and its qualifying date.
Identify the controls that will still be incubating
Take the latest qualifying date from the register and compare it with the date your organization can realistically prepare evidence and hold fieldwork. Any control whose qualifying date falls after that point must either be moved earlier, handled through a provider's qualifying history, or addressed through a corrective action plan or another approved route. Be exact about which option applies to each control. Project plans and tickets alone do not count as corrective action plan progress, so only log items that have change records, meeting minutes or draft documents as evidence. The output is a short list of blocking controls, each with a named owner and a decision.
Agree the fieldwork start with the assessor
Bring the dated register, the scope readiness log and the blocking list to your External Assessor. Only an Authorized HITRUST External Assessor can perform the validated assessment, so the assessor decides how the incubation dates apply to your evidence. Ask the assessor to confirm the fieldwork start date and the 90-day fieldwork window that ends when the management representation letter is signed. Agree the cut-off for any control that must qualify during fieldwork. The output is a written fieldwork start date and a confirmed list of controls the assessor will test. Do not treat your internal estimate as final until the assessor has confirmed it in writing.
Re-check the register before fieldwork opens
Repeat the calculation just before fieldwork starts. Confirm that no control has changed during its incubation period, that every provider run date has been verified, and that every scope component is still in production. Any change made after the register was built may reset a clock, so record it and recalculate the affected rows. Keep the change records and the signed register together as one evidence package. The output is a final, dated incubation register and a change log that the assessor can review. This step is complete when the assessor has acknowledged the package and no open rows remain without an agreed route.
What restarts or delays the 90-day clock
Incubation is measured from the moment a control runs in its current state, so any change to how the control works, where it runs or who performs it can start the count again. The cards below cover the events that most often reset the clock and the corrective action plan evidence that does and does not count as progress.
Reconfiguring a running control
Changing a threshold, rule, role assignment or approval step makes the control a different control in its current state. The 90 consecutive days then start from the change date, not from the original go-live. Check every configuration change against your control descriptions and record which changes altered the control's behavior, so you can show the earliest date the current version has operated.
Adding systems to scope late
A system that enters the assessment scope mid-stream must be installed and operating in production with all primary scope components for at least 90 days before it can be certified. Bringing a new application, database or facility into scope close to fieldwork can therefore push the earliest testable date out. Confirm the production go-live date for every new component before you commit to a fieldwork window.
Changing a service provider
Switching a managed service, cloud tooling or outsourced function to a new provider restarts the wait unless the new provider can show the control has run for at least 90 days, for example for other customers, or you can rely on its existing report. Ask the new provider for operating history and an existing assessment report before the transition, and keep the change record that dates the handover.
Project plans and tickets
A project plan, a Jira ticket or a status slide does not count as corrective action plan progress, and it cannot support a control that has just been fixed. Evidence that does count includes meeting minutes, draft documents and configuration changes backed by change records. Build your evidence trail as you work, because reconstructing dates after the fact weakens the incubation record.
Meeting minutes, drafts and change records
Dated meeting minutes, draft policies or procedures and configuration changes with approved change records show that remediation is underway and when each step happened. Policies and procedures need 60 days of operation rather than 90, so a policy finalized late in the cycle still has its own clock. Keep the signed final version and its effective date alongside the drafts that led to it.
Completed corrective action plans
A corrective action plan that is marked complete still has to pass the incubation rule. The remediated control must have run in its new state for the full 90 days before it can be tested as implemented, so closing the ticket is not the finish line. Confirm the completion date with your assessor and plan fieldwork around the run period that follows it.
Incubation questions buyers ask before scheduling fieldwork
Can a HITRUST control be tested before it has run for 90 days?
No. A control must run in its current state for at least 90 consecutive days before an External Assessor can test it as implemented, and this applies to new controls and to controls you have remediated. There is no partial credit for a shorter run. The clock starts when the control is operating in its current form, so a change to the control's design or operation restarts the count. Ask your External Assessor to confirm how they will date the start of the period for each control you plan to present, because the evidence you upload must show the control operating throughout that window.
Do policies and procedures get the same 90-day wait?
No. Policies and procedures need 60 consecutive days in effect before they can be tested as implemented, which is shorter than the 90-day period that applies to operating controls. The shorter period still has no partial credit, so a policy approved 45 days before fieldwork does not qualify. Confirm with your External Assessor which requirement statements in your scope are policy-based, because some statements combine a policy element with an operating element, and each element may carry its own incubation clock.
Does inheritance from a service provider remove the incubation wait?
It can, but only under specific conditions. A control performed by a service provider does not need its own 90-day wait if the provider shows the control has already run for at least 90 days, for example for other customers. Relying on the provider's existing HITRUST report is another route. Your organization still owns the controls it operates itself, and those keep their own incubation clock. Document each inherited control, the provider's evidence period and how it maps to your scope, and confirm the approach with your External Assessor before you plan the fieldwork date.
How does incubation affect the date I can start fieldwork?
Fieldwork cannot start until every control in scope has completed its incubation period, so the slowest control sets the earliest date. Work backward from the planned fieldwork window, which is at most 90 days for e1, i1 and r2 validated assessments. Each new or remediated control needs 90 days of operation before that window begins, or 60 days for policies. Systems in scope must also be installed and operating in production with all primary scope components for at least 90 days, and that period may overlap fieldwork if testing happens after the 90 days. Build a control-by-control calendar that shows the completion date of each incubation period.
What happens if a control changes during fieldwork?
A material change to a control during fieldwork can disrupt the evidence that already supports it. Because the control must run in its current state for the required period, a changed control generally starts a new incubation count, and evidence collected before the change may no longer show the control in its tested form. Treat any change during fieldwork as a question for your External Assessor, and log it with the date, the reason and the approval. Avoid making control changes in the weeks before fieldwork unless they fix a known gap, and plan those changes against the incubation calendar.
What must our team do, and what can an implementation partner or assessor do?
Your organization owns its controls, so it must operate them, keep the evidence they produce and make the calendar decisions. An implementation partner such as DeployOpen can plan the incubation calendar, configure the systems that generate evidence, document how controls run and prepare the evidence package. DeployOpen does not issue HITRUST reports or certifications. Only an Authorized HITRUST External Assessor performs the validated assessment, and HITRUST performs quality assurance before issuing a report. Ask each party to put in writing which incubation decisions they will make and which they will confirm with the assessor.
How DeployOpen prepares systems and evidence for the incubation window
The incubation clock starts when a control runs in its current state, so the work that matters is getting systems live, configured and logged on a known date. DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own infrastructure, then prepares the controls and evidence that the assessor will later test.
Fixing a go-live date for each control
Each control's incubation period starts from the date it runs in its current state, so DeployOpen records a go-live date per control and per primary scope component at deployment. Your team should confirm that every system in the planned scope is installed and operating in production, because a component that goes live late moves the earliest fieldwork date for the whole assessment. Ask for this date log as a written deliverable.
Documenting policies before the 60-day clock
Policies and procedures have a shorter incubation period than technical controls, so the ordering of policy approval and rollout matters. DeployOpen can prepare draft policy sets and procedures for your review, but your leadership must approve and publish them, and the approval date should be recorded. Confirm with your assessor which version and approval date will be tested.
Configuring logs and tickets as evidence
Assessors test whether a control ran over the incubation window, so the platform must keep records from day one. DeployOpen configures logging, access reviews, change records and backup jobs in self-hosted platforms so that evidence accumulates with dates attached. Check retention settings and where the logs are stored, since evidence that rolls off before fieldwork cannot be tested.
Using inherited provider results
A control run by a service provider can skip the wait if the provider shows it has operated for at least 90 days, or if you rely on the provider's existing report. DeployOpen documents which controls sit with your cloud or hosting provider and which sit with your team, so that the shared responsibility matrix matches the evidence. Confirm with your assessor and provider whether their report covers the control you need.
Keeping corrective action plan progress provable
A corrective action plan counts as progress only when the record shows real change, such as meeting minutes, draft documents or configuration changes with change records, and a completed item must still run through incubation. DeployOpen can implement remediation and keep change tickets linked to the configuration changes they describe. Project plans alone will not satisfy an assessor, so ask for the change history to be part of the handover.
Setting roles and sign-off boundaries
Your organization owns its controls, owns the management representation letter and decides which fieldwork dates to commit to. DeployOpen prepares systems, controls and evidence and documents its own work in writing, but it does not issue reports or certifications. Only an authorized HITRUST External Assessor performs the validated assessment, and HITRUST performs quality assurance before issuing the report. Scope and deliverables are agreed in writing before work starts, and no price is published, so request a quote built from that written scope.
