Having backups is not the same as being ready to recover. The attacker playbook is designed to exploit that gap.
The gap between perceived and verified readiness is the single most consistent finding in cyber incident research. It is not a gap of negligence; it is a gap of untested assumption — and cyber insurance renewals have shifted from asking "do you have backups?" to "show us the dated restore test and the architecture diagram."
See what a defensible posture actually containsRecovery readiness is the operational and evidentiary posture that lets an organisation recover from a major cyber incident within defined timeframes, with defined data-loss limits, and without paying the ransom. It is not the same as having backups, or having a recovery plan document. It is the architecture, the tested process, the measured recovery time, and the dated evidence that proves recovery would actually work under adversarial conditions.
Three questions that come up before the recovery readiness conversation properly starts.
What is recovery readiness?
The operational and evidentiary posture that allows recovery from a major cyber incident within defined timeframes, with defined data-loss limits, and without paying the ransom. Not backups; not a plan document. It is architecture, tested process, measured recovery time and dated evidence that proves recovery works under adversarial conditions.
Why is having backups not the same as readiness?
The attacker playbook targets backup infrastructure before encrypting production. A backup reachable by the attacker is not a recovery path; a backup never tested under pressure is an assertion, not evidence. Readiness tests backups as part of a broader architecture including identity recovery, dependency modelling and the process that runs during an incident.
What is the commercial driver in 2026?
Cyber insurance renewal questionnaires have shifted from attestation questions ("do you have backups?") to evidence questions ("show us the dated restore test and the architecture diagram"). The shift reflects claims history where organisations that attested to recovery capability were found, after a loss event, unable to recover.
Most organisations believe they are ready. The data says otherwise.
The gap between perceived and verified readiness is the single most consistent finding in cyber incident research. It is not a gap of negligence; it is a gap of untested assumption. Organisations that have invested substantially in backups, documented plans and controls still find, mid-incident, that the pieces do not hold together under pressure.
Figures vary by research source, methodology and year (Veeam 2026 Data Resilience Report and other industry research), but the direction is consistent across every major dataset. Confidence is high; full recovery rates are substantially lower. The gap is not random — it reflects specific structural weaknesses that readiness assessment is designed to surface.
A major cyber incident is a different problem from a routine data-loss event.
A routine data-loss event is a backup-and-restore problem. A major cyber incident is a different problem entirely, because the adversary is actively working to defeat recovery capability. The same backup that would have handled the routine scenario fails under the adversarial one, for reasons that only become visible when they matter.
Attackers with production admin credentials reach the backup infrastructure and destroy, encrypt or modify retention policies. The backup existed; it did not survive the attack because the architecture did not isolate it from the compromised environment.
The backup restored the data, but the Active Directory or Entra ID that provided authentication was also compromised. Without a clean identity recovery path, the restored data cannot be accessed by the business, and recovery stalls at the authentication layer.
Services depend on each other in ways the plan did not document. A file server restores, but the application that reads it is still down; the database restores, but the middleware depends on a service that has not come back yet. Recovery happens out of sequence, and business services do not return in the time the plan assumed.
The plan stated a 24-hour RTO. The actual time to restore a representative workload under realistic conditions had never been measured. When the incident occurred, the 24 hours became 96 hours, and the business ran on contingency for three days longer than was operationally tolerable.
Point restores had been tested (a single file recovered). A full-environment restore had never been performed. Issues trivial at small scale became blocking at large scale: storage throughput bottlenecks, licensing reactivation, IP address conflicts, DNS propagation, certificate re-issuance.
The backup was in place and the restore had been tested. The renewal questionnaire asked for dated evidence with scope and outcome, and no document existed that met the specification. The claim was true; the evidence was not available.
Each failure mode is fixable, and none is a failure of spending or intent. They persist because the adversarial scenario is not what most recovery plans were designed to address — a structured assessment is how the plan is brought into alignment with the scenario it actually has to handle.
Six components. Any single one missing or weak produces a recovery path that fails under adversarial conditions.
Assessment is the process of identifying where each component currently sits, documenting the gaps, and sequencing remediation. None of the six is exotic; all six are commonly absent or under-developed in environments where leadership would report confidence.
Immutable backup architecture
Copies an attacker with admin credentials cannot alter or delete during the retention period — storage-enforced, retention outlasting dwell time, credentials separated from production.
Identity recovery sequencing
A documented, tested path to restore Entra ID or Active Directory from a clean position. Without identity recovery, data restoration does not translate to business recovery.
Dependency mapping
Explicit documentation of which services depend on which, and in what sequence they must return. Undocumented dependencies are where recovery plans stall in practice.
Cyber Recovery Time per critical service
Modelled or measured recovery time under cyber incident conditions — not a paper RTO. The gap between paper RTO and modelled CRT is usually where commercial readiness is overstated.
Tested recovery with dated evidence
A real restore test, recent enough that the report is current, covering a representative workload. This is what converts the plan from assertion to evidence.
Operational runbook
A working document that can be run under incident pressure by the people who would actually run it — clear authorities, escalation paths, contacts and sequencing decisions. Not a policy document.
Six components, and any one weak produces a recovery path that fails under pressure. A Recovery Readiness Assessment shows exactly where each currently sits — with dated evidence, a Cyber Recovery Time model and a 90-day roadmap.
Assess your recovery readinessRTO is the goal. CRT is the projection. The gap is where recovery plans commonly fail commercially.
- How long the organisation would tolerate an outage before material harm
- Agreed during business continuity planning
- Carried forward as a target for recovery design to aim at
- A round number on paper
- Modelled or measured time recovery would actually take
- Accounts for identity recovery, dependency ordering and validation
- Includes the human decision points during the incident
- Tied to stated, checkable assumptions
A CRT model per critical service is one of the standard deliverables of a Recovery Readiness Assessment, replacing paper RTO targets with defensible modelled numbers. What the model accounts for:
- Identity recovery time — before Entra ID or Active Directory is restored to a clean authentication state the rest of the recovery can build on
- Restore throughput under realistic load — speed from immutable storage to target, accounting for network, storage and API constraints invisible at small-scale test
- Dependency sequencing — services returning in the correct order so downstream services have the upstream ones they need
- Validation time — verifying recovered services are clean, functional and ready to carry production load before users return
- Stated assumptions — every number tied to an assumption, so the reader can verify applicability and the underwriter can see the basis
Recovery readiness review tends to be triggered by an external event, not a scheduled internal process.
The four most common triggers are commercial or operational in origin, which is why the review is most valuable when it produces commercially legible outputs rather than purely technical ones.
The questionnaire arriving for the next renewal is substantially more detailed than last year. Evidence questions have replaced attestation questions. The organisation cannot answer from existing records and needs a structured review to produce the evidence.
A publicly reported major incident in the sector raises the internal question of whether the same outcome is possible. Leadership asks for a defensible answer. An existing internal review does not satisfy the question; an external, evidence-led assessment does.
A significant customer or regulated counterparty requests evidence of recovery capability as part of onboarding or annual review. The evidence requested is specific — architecture diagrams, dated restore tests, dependency maps — and the organisation does not have it in the format requested.
An incident has occurred (own organisation or peer) that revealed specific gaps. The review covers remediation of the identified gaps and broader readiness evaluation to surface what else may be exposed — turning a specific lesson into broader posture improvement.
Engineering-led, evidence-based, end-to-end.
The approach starts with the trigger that drove the review. An insurance-renewal-driven review emphasises the evidence pack and questionnaire mapping; a sector-incident-driven review emphasises architecture review and specific attack-scenario modelling; a due-diligence-driven review emphasises external legibility of the outputs. Same underlying work, different output emphasis based on what the review is actually for. The work is engineering-led end to end — the same engineer scopes the review, runs the work, presents the findings and is available for follow-up. Findings are documented with configuration evidence, restore-test results and dependency models rather than checklist responses. Where findings are unflattering, they are documented unflatteringly; the output is only useful if it is honest. Remediation is not assumed — findings are handed over as written evidence a third party could execute.
What the work produces:
Architecture scored against the categories underwriters and auditors commonly look at, each cited with evidence, gaps documented with specificity.
Modelled recovery time for each critical business service under cyber incident conditions, tied to a documented dependency map and stated assumptions.
A structured collection of dated artefacts indexed against the questions insurers, auditors and governance teams typically ask — built so the conversation runs from records, not recollection.
A prioritised closure plan sequenced by risk, commercial impact and dependency, scoped into 30, 60 and 90-day tranches, written so the internal team or any capable third party could execute it.
Readiness review establishes the position. Maintaining it is a separate question.
Most organisations reach a point where the assessment is complete and the gaps are documented. The harder question is whether the operational discipline exists to close them and sustain the posture as architecture, services and dependencies change. Readiness drifts in specific ways: new services come into scope without inheriting the same backup architecture; new dependencies appear that are not in the map; restore tests fall behind schedule; identity recovery sequencing becomes inaccurate as identity platforms evolve. The drift is not a failure of intent; it is a function of how environments change. Several paths exist for maintaining the posture after the assessment:
- Internal execution — for organisations with the engineering depth and operational discipline to carry the work without external delivery support
- Defined remediation engagement — where the assessment surfaces architectural gaps significant enough to require a structured project, scoped separately based on what is surfaced
- Ongoing managed-resilience relationship — recovery-specific posture maintenance that keeps recovery aligned as architecture changes, with refreshed restore evidence and updated dependency mapping
- Managed Cyber Security — for organisations where recovery readiness sits inside a broader security operating-discipline requirement; one operating path of several, not the default destination
The maintenance path is a separate decision from the assessment itself. The outputs stand on their own whether the maintenance work is internal, a project engagement, an ongoing managed-resilience relationship or a broader managed cyber security model.
The Inlight IT view on recovery readiness.
Recovery readiness is usually framed as a technical question. In practice, it is an evidence question wrapped around a technical one. The organisation that can demonstrate readiness with dated artefacts has a materially different renewal conversation, claim conversation and post-incident conversation from the organisation that cannot. Verified recovery capability is the benefit; the operational honesty required to surface gaps that have been invisible, and the willingness to remediate them before they matter, is the trade-off.
Most organisations that approach this conversation are at the point where the gap between confidence and evidence is starting to feel commercially uncomfortable. The renewal questionnaire is sharper this year; a peer incident has surfaced the board-level question; an auditor or major customer has asked for evidence the organisation cannot currently produce. The assessment is the structured way to close that gap before the recovery position has to be proven under pressure.
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.
If the last full restore test predates your last staff change, the plan is documentation, not capability.
Test the plan →Questions Australian organisations ask about recovery readiness.
What is recovery readiness?
Why is having backups not the same as being ready to recover?
How wide is the gap between perceived and actual readiness?
What are the components of a defensible posture?
Why are insurance questionnaires driving this now?
How is recovery readiness assessed?
What is Cyber Recovery Time, and why is it different from RTO?
How often should recovery readiness be reviewed?
What happens if we have a major incident without being ready?
How long does a Recovery Readiness Assessment take?
How is the recovery position maintained over time?
Clarify the recovery position with evidence, before it has to be proven under pressure.
A Recovery Readiness Assessment reviews the architecture, models Cyber Recovery Time per critical service, builds the evidence pack, and hands back a 90-day remediation roadmap, so the recovery position is understood before something forces the test.
Discuss a Recovery Readiness Assessment