Recovery Readiness Assessment: the recovery position documented, the gaps prioritised and a 90-day roadmap to close them
Most organisations have backups. Fewer have tested whether recovery would actually work under cyber-incident conditions. Inlight IT runs a scenario-based review of recovery capability — backup architecture, identity recovery sequencing and dependency modelling — when the position has to be evidenced for insurance, audit or the board.
- Scope, timing and cost agreed before the work starts
- Engineering-led, not interview-based
- Scenario-based, not questionnaire-based
- Findings documented whichever path follows
Organisations usually arrive here because a renewal, audit, incident or board question has made recovery evidence urgent.
Six situations drive most Recovery Readiness Assessments. Select one to see what is usually behind it.
A structured way to clarify the recovery position when evidence is needed.
A Recovery Readiness Assessment is the structured form of Backup and Disaster Recovery work that organisations engage when the recovery position needs to be documented, not just discussed. It is the engagement Inlight IT runs when insurance, audit, board governance or post-incident review requires a defensible recovery position with dated evidence.
Once the assessment is complete, holding that position over time is a separate operating question. How that happens depends on the organisation.
Take the remediation roadmap and execute it internally, with existing IT capability or provider
Engage Inlight IT for the remediation work, scoped separately against the gaps the assessment surfaces
Bring recovery posture into an ongoing managed-resilience relationship so it stays aligned as architecture changes
Fold it into a broader cyber operating discipline through Managed Cyber Security, where recovery readiness sits inside the wider security operating layer
Backup existence is not recovery evidence. Underwriters, auditors and leadership can tell the difference.
Most organisations enter the assessment assuming the recovery posture is stronger than the evidence supports. The work converts each assumption into documented fact, and flags where the assumption was wrong.
Recovery architecture reviewed against the categories underwriters and auditors look at.
Eight categories, each scored with the evidence behind the score. The grade reflects what the environment can actually show, not what the policy states.
Recovery modelled as a sequence, identity first.
Cyber Recovery Time is modelled per critical service against a real cyber incident scenario, tied to a dependency map. The order matters: nothing recovers cleanly until identity does. The timeline below shows an illustrative sequence.
Dated artefacts you can hand to an insurer, an auditor or the board.
A documented recovery position, built to be useful across the conversations the organisation needs to have. Select an artefact to see what it contains.
The outputs are produced whether or not Inlight IT does the remediation work, and are written so a third party could execute them. The value is in the recovery position itself.
Scoped and priced up front, then run in defined phases.
Scenario modelling and evidence collection run in parallel where possible to keep the engagement compact, typically three to four weeks from scope agreement to final outputs.
The assessment boundary is defined, critical business services confirmed, cyber incident scenarios to be modelled identified, and the initial dependency map produced. Scope is locked before evidence collection begins.
Technical verification across the eight audit categories: backup architecture, separation from production, restore test history, RTO and RPO documentation, privileged access controls, immutability posture, operational documentation, ownership assignment. Engineering-led, not interview-based.
Cyber Recovery Time per critical service modelled against the identified scenarios. Includes the identity recovery sequence, the restore-and-validate path, and the documented assumptions behind each estimate.
The outputs are produced, findings presented in both technical and summary formats, and the 90-day roadmap handed over. The work is led by an engineer who understands the environment, presents the findings and is available for follow-up questions.
Delivered with engineering discipline, not a checklist run.
Engineering-led, scenario-based, and useful whatever happens next.
The assessment is shaped by what insurers, auditors and leadership teams actually do with the output. That shapes how the work is done.
01Engineering-led, not consultant-led
The work is done by engineers with hands-on experience across backup architecture, identity recovery, Microsoft 365, endpoint, network and incident response. Maturity claims are tested against operating reality, not against a checklist.
02Scenario-based, not questionnaire-based
Recovery is modelled against actual cyber incident scenarios, not generalised DR conditions. Identity recovery sequencing, restore throughput under realistic load, dependency ordering and validation steps are part of the model.
03One engineer, end to end
The same engineer scopes the work, runs the review, presents the findings and is available for follow-up questions. The person presenting the findings is the person who collected the evidence, and that continuity is part of why the work holds up under external review.
04Findings stand on their own
The outputs are produced whether or not Inlight IT carries the remediation work, and are written so a third party could execute them. The assessment is not structured as a lead-in to follow-on work; the value is in the recovery position itself.
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.
Recovery readiness assessed against real commercial drivers
Practical questions about scope, pricing, delivery and what the assessment produces.
What is the Recovery Readiness Assessment?
Engineering-led work Inlight IT does alongside the organisation to clarify whether recovery would actually hold under cyber incident conditions. It is scenario-based and evidence-led, typically runs three to four weeks, and produces a documented recovery position, a Cyber Recovery Time model per critical service, evidence indexed for insurance and audit conversations, and a 90-day remediation roadmap.
What does the assessment cost?
The cost is agreed at the scoping call, based on user count, platform mix, number of sites and the critical services in scope. Scope, timing and cost are settled before the work starts, so the organisation knows what is being reviewed and what will be produced. Any material change is talked through before it proceeds.
How long does the assessment take?
Three to four weeks from scope agreement to final outputs. Timeframe depends on environment size, platform mix and the availability of existing documentation. Scenario modelling and evidence collection run in parallel where possible to keep the engagement compact.
How is this different from a generic backup audit?
A backup audit typically checks whether backups are running and producing reports. This work asks whether the organisation could actually recover from cyber attacks, a different question. Scenario modelling, identity recovery sequencing, dependency mapping, Cyber Recovery Time and the evidence pack for insurance and audit conversations are part of this work that a backup audit does not produce.
Does the assessment cover Microsoft 365 data?
Yes. Microsoft 365 backup, retention and malware replication risk are assessed as part of the scope. Where platform-native retention alone would not be sufficient under cyber incident conditions, that gap is documented and included in the remediation roadmap.
What happens after the assessment?
It depends on the organisation. Some teams execute the 90-day roadmap internally or through an existing provider. Some engage Inlight IT for the remediation work, scoped separately. Some bring recovery posture into an ongoing managed-resilience relationship, or into a broader cyber operating discipline through Managed Cyber Security. The outputs are usable whichever path follows.
Is this a penetration test?
No. This work looks at recovery capability, not offensive security posture. It does not attempt to breach the environment or test control bypass. It is a structured review of backup architecture, identity recovery sequencing, scenario modelling, dependency mapping and evidence maturity. For offensive security testing, a separate penetration testing engagement is the right kind of work.
Will it produce something we can give to our insurer?
Yes. The work produces an evidence pack indexed against the categories underwriters commonly review: backup architecture, privileged access controls, restore test evidence, RTO and RPO per critical service, dependency modelling and operational documentation. Each claim is mapped to a specific dated artefact, so the renewal conversation runs from records rather than recollection.
What if we have already had a backup audit?
This work is useful even where a prior review exists. A common pattern is that a previous audit scored the environment but did not produce actionable remediation or evidence structured for insurer use. The work can be scoped to build on prior reviews rather than duplicate them, if the earlier work is shared at the scoping call.