Cloud assessments / Continuity
Your recovery plan has a number in it. Nobody has measured it.
Every continuity plan promises a recovery time. Very few have ever been timed. Recovery Proven takes a representative set of your systems, brings them up somewhere else in an isolated environment, and measures how long it takes until someone can work. You get the real number next to the promised one, and the list of everything that stood in between.
What you will know afterwards that you don't know today
- Your real recovery time, per system. Measured from the moment the failure is declared to the moment a user can work. Not estimated from a spec sheet.
- How much data you would actually lose. The recovery point your replication and backup policies really give you, next to the one the business signed off on.
- What comes back in the wrong order. The database that has to be up before the ERP, the license server nobody listed, the name that still points to the old site.
- What your runbook is missing. The steps that live only in someone's head, and who would have to be awake for them.
How it works
- We start from your targets, not ours. The recovery time and data loss your business already committed to are the bar. If they were never set, we set them with you, system by system, before anything else. Without a target there is nothing to pass or fail.
- Evidence without access. Your team runs a read-only script with its own credentials and reviews the output before sharing it. From that evidence we read how recovery is configured today: replication, backup policies, redundancy, networking and names.
- A real failover, isolated from production. The selected systems come up in a separate recovery network. Production keeps running, users are not affected and nothing is switched over for real.
- A stopwatch, not an estimate. Every step is timed and recorded. When a step fails, the exercise has not failed. That failure is the finding the exercise exists to produce.
What it covers
- What gets tested. A representative set of systems agreed with you, with at least one from each recovery tier; a controlled failover and failback of that set; a test restore of each backup policy; and a results session with IT and operations leadership.
- What helps it go well. Someone who can bring infrastructure, applications and security to the table; your recovery objectives, or the people who can set them; a window for the isolated test; and the evidence from the read-only script.
- What you usually walk away with. Recovery time and data loss measured per system, next to its objective; a findings matrix traceable to the evidence; your runbook, corrected with what the test taught; a maturity score per domain you can compare year over year; and a prioritized plan. The exact scope is set in your proposal.
How we work
Scoping session
We agree which systems go into the test, what the targets are and which questions the report has to answer.
Evidence
Your team runs the script and sends the package. The calendar starts when the evidence arrives, not when the contract is signed.
Test plan
Recovery order, dependencies, success criteria per system and the way back, all written and approved before the window opens.
Controlled failover and failback
We bring the systems up in the isolated network, validate data integrity, time every step and bring everything back.
Report and runbook
Results, gaps and plan, presented to leadership. Anything we could not test is declared as a scope gap, never presented as a finding.
What comes next
Each gap points to a specific fix. A copy that lives on the same site as production is a backup problem. Nowhere to bring systems up is a disaster recovery problem. A single firewall between the plant and the ERP is an availability problem. The plan tells you which one you have and in what order to solve it.
The score is built to be repeated. A recovery plan ages every time a server is added or an application changes, so a second run a year later tells you whether you are getting better or just getting older.
Questions
Will this affect production?
No. The test runs in an isolated recovery network. Production keeps running and your users keep working.
What if we have no disaster recovery today?
Then the test measures what you actually have: how long it takes to rebuild the selected systems from your current backups in a clean environment. That number is usually the most persuasive one in the report.
Do you need access to our cloud or our servers?
Not for the evidence: your team runs a read-only script and decides what to send. For the failover itself we work alongside your team, with access limited to the recovery environment and to the length of the test.
What if we never set recovery targets?
Then the first session sets them per system, with the people who own each process. Without targets the test would have nothing to measure against.
Which platforms do you cover?
Servers in your own data center recovering to AWS, and workloads already running on AWS or Azure. If your recovery runs on something else, we tell you in the scoping call, before you commit.
What happens if the failover fails?
Then the exercise did its job, a month before it mattered instead of on the day it did. Every failure is timed, explained and turned into a line in the plan.
Find out your real recovery time.
One scoping call to agree the systems, the targets and the window.