RTO is what the business agreed to tolerate. CRT is what will actually happen.
Cyber Recovery Time is the elapsed time from the start of a cyber incident to the point at which critical services are restored to a defined operational level. It accounts for identity recovery, backup integrity verification, malware eradication, dependency ordering and validation steps that a traditional Recovery Time Objective does not factor in.
This page defines CRT, contrasts it with RTO and RPO, explains the factors that extend recovery time under cyber incident conditions, and walks through the modelling methodology that produces a defensible CRT number per critical service.
See how the CRT number is actually producedCRT defined against RTO, RPO and traditional DR metrics; the factors that extend recovery under cyber incident conditions; the CRT modelling methodology step by step; where identity recovery sits on the critical path; and where CRT modelling produces commercial value — insurance, governance and incident response. This page is most relevant for engineers, IT leaders and governance stakeholders who have a documented RTO and want to understand why cyber incident conditions produce a recovery time that exceeds it, and what to do about the gap.
What it is, how it differs from RTO, and why it matters.
What is Cyber Recovery Time?
The elapsed time from the start of a cyber incident to the point at which critical business services are restored to a predefined level of operation. A measurement of actual recovery time under adversarial conditions, including identity recovery, backup integrity verification, malware eradication, dependency-ordered restore and validation. Distinct from RTO, which is the planning target.
How is CRT different from RTO?
RTO is a goal: what the business would tolerate. CRT is a projection: what will actually happen. RTO assumes a clean restore path; CRT models the additional steps that cyber attack introduces — clean-room setup, identity rebuild, backup integrity verification, dependency ordering, validation. The two numbers address the same question from opposite directions: the business-tolerance side and the engineering-reality side.
Why does it matter now?
Cyber insurance underwriters, governance reporting and incident response planning all increasingly expect CRT to be documented per critical service, with stated assumptions. An untested RTO is no longer an adequate answer to the renewal questionnaire or to a leadership question about exposure during an incident. A modelled CRT replaces the target with a measurement.
RTO was built for a different threat model. CRT names what cyber attack actually does to recovery time.
Traditional Recovery Time Objective was built for a different threat model. It assumed recovery scenarios where the failure was mechanical — hardware fault, site outage — or logical, such as database corruption or a bad deployment, and the backup was clean because the backup was not itself the target. In that world, RTO and the actual recovery time stayed close to each other because the gap between planning assumption and recovery reality was small.
Cyber attack inverted the model. The backup is now the primary target. The attacker reaches identity infrastructure, modifies retention policies, encrypts or destroys backup copies, and uses production credentials to do all of it. Recovery now requires steps that traditional RTO did not model: verifying backup integrity against tampering, rebuilding identity from a clean position, restoring in dependency order rather than in parallel, validating that restored services are operationally clean.
Cyber Recovery Time names this reality explicitly. It is not a new acronym for marketing purposes. It is the metric that business continuity teams were implicitly reaching for when they set an RTO and then discovered, during an actual incident, that the number was a target rather than a measurement. CRT makes the measurement side visible alongside the target.
Time to rebuild Entra ID or Active Directory from a clean position before dependent services can authenticate.
Time to verify that restore candidates are clean rather than containing the encryption or malware that triggered the incident.
Time to establish an isolated environment where restoration can proceed without reintroducing compromise from production.
Time consumed by sequential restore ordering, which is materially different from the parallel restore that traditional DR typically assumes.
Time to verify that restored services are clean, functional and safe to return to production load before allowing users back onto them.
CRT does not replace RTO or RPO. It measures what they assume.
The existing metrics remain useful. RTO still sets the business-tolerance target. RPO still defines the data-loss boundary. DR still governs the routine failure scenarios. CRT does not displace any of them. It introduces the cyber-specific measurement alongside them, addressing the gap in scenarios where cyber attack is the threat rather than hardware failure.
Recovery Time Objective
Target downtime window the business would tolerate before material harm. Remains the target. CRT measures whether it is achievable under adversarial conditions.
Recovery Point Objective
Maximum tolerable data loss, typically measured in time. Remains relevant for data freshness. If backups are compromised, actual data loss may be different from target; CRT modelling verifies RPO integrity.
Disaster Recovery
Recovery from infrastructure failure with the assumption of clean backups. Assumes clean-restore. Cyber scenarios cannot assume backups are clean; clean-room recovery and staged verification are required in addition.
Cyber Recovery Time
The actual modelled or measured time to restore critical services after a cyber incident, including the identity, clean-room, dependency and validation work the other metrics do not account for. A specific cyber-scenario measurement, involving containment, identity rebuild, staged restore, and insurance or regulatory reporting.
Specific sources of the gap between paper RTO and modelled CRT.
Each factor below is a real operational constraint visible during incident response. Each is also a lever that remediation work can shorten, which is why CRT modelling produces remediation priorities rather than just recovery numbers.
If Active Directory or Entra ID is compromised, recovery cannot proceed until identity is rebuilt from a clean position. NIST SP 800-184 explicitly notes identity services typically must be restored before dependent files and applications. Without a clean authentication foundation, restored data cannot be accessed.
Modern cyber attack groups actively target backup infrastructure before encrypting production. Restore candidates must be verified clean before use, and where they are not, earlier backup generations must be identified and verified. The Maersk–NotPetya case is commonly cited: a single offline domain controller provided the only clean recovery point across the global environment.
Recovery in an isolated environment prevents reintroducing compromise into production. The clean-room provides known-good infrastructure for identity rebuild and backup verification before staged cutover. It adds time to the critical path but is commonly the only way to ensure a genuinely clean outcome.
Services depend on each other in ways that only become visible during recovery. NIST notes that environments typically contain "less obvious dependencies" that are not captured in documentation. Recovery in the wrong sequence produces restored services that cannot function because their dependencies have not yet returned.
Insurance policies, regulatory obligations and legal discovery may require that certain systems remain in a preserved state for forensic examination. This constraint can extend recovery time by preventing cutover to systems that would otherwise be ready.
Recovery is not purely a technical exercise. Decisions require human judgement under pressure, often across multiple stakeholders with different authorities. Communication channels may themselves be affected by the incident. Task handoffs, approval waits and coordination overhead add real time that purely technical modelling understates.
Recovery does not begin until authentication is clean.
Of all the factors that extend CRT, identity recovery has the greatest single impact. It sits on the critical path through the dependency graph for almost every critical service, which means the time to restore identity is a lower bound on the time to restore everything else that depends on it. And in cyber incident scenarios where the attacker has reached the identity layer, the identity rebuild is often the longest single task in the recovery sequence.
Why identity goes first. Without a functioning authentication system, users cannot log in to recovered services, applications cannot authenticate to each other, and administrative actions on restored infrastructure cannot proceed. Every downstream recovery step waits on identity.
Why cyber attack reaches identity. The attacker's primary goal before encryption is often to reach the highest-privilege credentials available — Domain Admin in Active Directory, Global Administrator in Entra ID. Once reached, the identity layer itself becomes part of the compromise, and recovery requires rebuild rather than restore.
What identity recovery actually involves. Clean-room setup, offline domain controller promotion or equivalent Entra recovery procedure, credential resets for all privileged accounts, verification that the identity layer is uncompromised before dependent services authenticate against it, and staged cutover. The work is substantial and commonly takes days rather than hours in environments where it has not been pre-planned.
Where organisations commonly fall short. Identity recovery is missing from most DR plans or covered only at a high level. A plan that says "restore AD from backup" does not address whether that backup is clean, whether the restore reintroduces the compromise, or how credential resets would proceed. CRT modelling exposes these gaps specifically.
Could your team say, today, how long an Entra ID or AD rebuild would take from a clean position? If the honest answer is "we'd find out during the incident", that is the number worth knowing first.
Find out before it matters →CRT modelling turns recovery assumptions into a sequence the organisation can test.
CRT modelling is a structured analysis, not an estimate. The phases below produce documented numbers with stated assumptions per critical service, which is what makes the output defensible to an underwriter or governance review. Each phase builds on the previous, and gaps identified at later phases often send earlier phases back for revision.
Business Impact Analysis or equivalent exercise to identify the minimal viable set of services that must recover. Agreement on what "recovered" means for each service, including the level of functionality required and the users or workloads that must be able to access it. This defines what CRT is measuring against; without it, CRT numbers are not comparable across services.
Documentation of critical assets — servers, networks, cloud tenants, application platforms — and their dependencies. NIST's framework emphasises mapping dependencies explicitly, including the less obvious ones that only surface during actual recovery. The dependency map is the basis for the sequencing analysis in the next phase.
For each scenario being modelled, the step-by-step recovery sequence. Typical order: containment, identity rebuild (AD or Entra), network restoration, infrastructure integrity validation, data and application restore from backup, service validation, cutover. Sanitation steps such as malware scanning and patching are factored in where relevant to the scenario.
Realistic time estimates for each step, developed with the engineers and operations staff who would actually perform the work under incident conditions. Includes restore throughput based on measured or vendor-specified rates, identity recovery timings based on the specific AD or Entra architecture, validation time, and communication and coordination overhead. Estimates are tied to stated assumptions so that the assumptions are visible when the estimate is used.
The critical path through the dependency graph determines the CRT floor: the recovery time cannot be less than the sum of times along the longest dependency chain. Validation where possible through tabletop exercises, partial restore tests or full-restore dry-runs in an isolated environment. Where validation is not practical, the assumptions that most affect the critical path are identified as priority candidates for future testing.
Any one of these phases can quietly own your critical path. A Recovery Readiness Assessment shows which one owns yours.
Model my recovery timeRTO was the right metric until recovery time became an evidence question.
CRT modelling became commercially relevant when the audiences for the recovery time conversation started asking for evidence rather than assertion. Distinct conversations now commonly require a modelled CRT with documented assumptions, and the untested RTO is no longer a sufficient answer in any of them.
Cyber insurance renewal
Underwriter questionnaires increasingly request defined and tested recovery time per critical service rather than a single top-level RTO. A modelled CRT per service, with assumptions documented, is the kind of answer underwriters now expect. It is also what differentiates a claim that would be accepted on investigation from one that would not.
Governance and leadership reporting
Leadership oversight of cyber risk requires a realistic view of exposure during an incident. A paper RTO that the environment could not actually meet provides a false sense of control. A modelled CRT makes the exposure visible and gives governance the basis to direct remediation investment with accuracy.
Incident response planning
Response plans built against paper RTO commonly collapse under actual incident conditions because the sequencing and timing do not match operational reality. Response plans built against modelled CRT reflect what will actually happen, which produces a plan that can be executed rather than one that requires improvisation under pressure.
One output of broader recovery readiness work, not a standalone deliverable.
CRT modelling is part of a broader recovery readiness position. It connects to backup architecture (whether the restore candidates are clean and reachable), to identity recovery sequencing (where the largest single CRT factor usually lives), to dependency modelling (which produces the critical-path floor) and to the evidence layer that current insurance questionnaires increasingly require.
Where the broader question is "could we recover from a destructive cyber event with evidence that holds up at renewal," CRT modelling is produced inside a Recovery Readiness Assessment alongside the architecture review, evidence pack and remediation sequencing.
Where the rest of the recovery position is already understood and only the CRT measurement is open, the work can be scoped directly within Backup and Disaster Recovery.
The Inlight IT view on Cyber Recovery Time modelling.
RTO was useful when recovery was a technical problem and backups were the answer. Cyber attack made it an evidence problem, and evidence requires a measurement. CRT is that measurement.
The specific thing CRT modelling surfaces that RTO does not is the critical path. A recovery plan can look technically complete and still have a single task — usually identity rebuild, sometimes backup verification, occasionally a specific dependency — that sits on the critical path and determines the whole recovery time. Shortening any task off the critical path does not shorten recovery. Only critical-path work moves the number. CRT modelling exposes which tasks those are; RTO does not.
A defensible recovery time projection is the benefit. The operational honesty required to document assumptions and identify where the gaps are — rather than stating an aspirational target — is the trade-off.
As an illustration of the pattern rather than a headline: recovery readiness work for a multi-clinic healthcare provider included Cyber Recovery Time modelling per critical service across the environment, with identity recovery sequencing and dependency mapping producing a defensible per-service number that the previous paper RTO could not support.
A backup that exists is not the same as a recovery path that works. The difference matters most on the day it is tested by an attacker.
Questions Australian organisations ask about Cyber Recovery Time, what it measures, how it is modelled and how it relates to insurance and governance.
What is Cyber Recovery Time (CRT)?
Cyber Recovery Time is the elapsed time from the start of a cyber incident to the point at which critical business services are restored to a predefined level of operation. It is a measurement of actual recovery time under adversarial conditions, including identity recovery, backup integrity verification, malware eradication, dependency-ordered restore and validation. It is distinct from the Recovery Time Objective (RTO), which is the planning target.
How is CRT different from RTO and RPO?
RTO (Recovery Time Objective) is a target: a statement of how long the organisation would tolerate an outage before material commercial harm. RPO (Recovery Point Objective) is a data-loss tolerance: how much data loss the organisation would accept. CRT (Cyber Recovery Time) is a measurement: the modelled or actual elapsed time to restore operations under cyber incident conditions. RTO and RPO are goals set during business continuity planning. CRT is what happens when those goals meet adversarial reality.
Why does CRT typically exceed RTO?
Six common factors: identity and control-plane compromise that requires rebuild from a clean position; backup integrity verification before restored candidates can be trusted; clean-room recovery setup to prevent reintroducing compromise; dependency chains that only become visible during recovery; forensic holds and evidence preservation that constrain cutover; communication and human coordination overhead. Each is real, each is a lever for remediation, and CRT modelling exposes which factors are extending the number on the critical path.
What does CRT modelling actually involve?
Five phases: scope definition and critical service tiers (business impact analysis), inventory and dependency mapping, recovery sequence planning per scenario, task duration estimation tied to stated assumptions, and critical-path analysis with validation. Output is a documented CRT number per critical service, with stated assumptions, tied to the dependency map and recovery sequence.
Why is identity recovery central to CRT?
Because identity sits on the critical path through the dependency graph for almost every critical service. Without functioning authentication, users cannot log in, applications cannot authenticate to each other, and administrative actions cannot proceed. The time to restore identity is a lower bound on the time to restore everything that depends on it. And in cyber incident scenarios where the attacker has reached the identity layer, identity rebuild is commonly the longest single task in the recovery sequence.
What is a clean-room recovery and how does it affect CRT?
A clean-room recovery is restoration in an isolated environment to prevent reintroducing compromise from the production environment. The clean-room provides known-good infrastructure for identity rebuild and backup verification before staged cutover to production. It adds time to the critical path, but it is commonly the only way to ensure the recovered environment is genuinely clean. Skipping it produces faster recovery on paper but risks reintroducing the compromise that triggered the incident.
How does CRT relate to cyber insurance and governance reporting?
Cyber insurance underwriters increasingly ask for defined and tested CRT rather than for attestation that recovery would be timely. A modelled CRT with documented assumptions is a substantively different answer to the renewal questionnaire than an untested RTO claim. At the governance layer, leadership reporting that includes modelled CRT per critical service gives decision-makers a realistic view of exposure during an incident, which is what governance oversight of cyber risk is designed to achieve.
How much longer than RTO is CRT typically?
It varies substantially by environment. In environments where identity recovery has not been pre-planned, CRT can be multiples of RTO. In environments where backups, identity and dependencies have all been hardened against cyber incident scenarios, CRT may sit close to RTO. The honest answer is that the gap is environment-specific and is exactly what CRT modelling exposes. A general number is less useful than the specific one for the organisation's own architecture.
Does CRT modelling require a full restore test?
Not necessarily, though full restore tests produce the most rigorous data. CRT can be modelled from task-level estimates, vendor throughput specifications, measured partial restores, and documented dependency maps, combined into a critical-path analysis. The model is a projection based on evidence, not a measurement from a single end-to-end exercise. Where a full restore test has been performed, the results feed directly into the model. Where it has not, the model identifies the assumptions that would most benefit from testing, which informs the restore test programme.
How do I get a CRT model produced for my environment?
A Cyber Recovery Time model per critical service is one of the outputs of a Recovery Readiness Assessment. The assessment covers backup architecture, identity recovery sequencing, dependency modelling and CRT calculation, producing documented recovery time projections with stated assumptions alongside the broader architecture and evidence work.
Replace the paper RTO with a recovery time the organisation can defend.
A Recovery Readiness Assessment models it per critical service — with the assumptions written down.
Discuss Recovery Readiness