Almost every organisation has backups. Far fewer have ever restored one under pressure, and fewer still can say how long it took or whether the application actually started afterwards. A backup that has never been restored is a hypothesis, and a ransomware incident is a poor time to test it.
Status: product concept, in active development. This is something we are building, not something you can buy today. We publish our roadmap because the engineering thinking behind it is the useful part — and because we would rather show you the design than imply a finished product.
Designed Capabilities
- Backup and recovery-plan inventory — what is protected, and what quietly is not.
- Isolated restore orchestration — real restores into a sealed environment, routinely.
- Integrity and malware checks — confirm you are not restoring the infection.
- Application and dependency startup tests — data restored is not the same as service restored.
- Database consistency validation — the restore is coherent, not merely complete.
- RPO and RTO measurement — measured, not assumed from the policy document.
- Recovery evidence and gap reporting — proof for auditors and insurers.
- Remediation workflow and recurring schedules — gaps become tracked work.
Proof Beats Policy
The point is to replace a stated recovery objective with a measured one. Knowing a critical system restores and starts in four hours — because it was tested last week — is a very different conversation with the board than pointing at a document claiming it should.
Tell us if this matches a problem you have — early input shapes what we build first, and we will give you an honest view of where it stands.
Related services
- Incident Response and Digital Forensics — Recovery starts with containment: incident response and digital forensics.
What Would You Bring Back First?
Recovery plans usually list systems in order of business importance. Recovery itself happens in order of dependency, and the two lists are rarely the same document. Identity comes before the applications that authenticate against it. DNS and certificate services come before nearly everything. Licensing servers, message brokers and shared file services sit underneath applications that look self-contained on an architecture diagram. Working that order out on paper is cheap. Discovering it during an incident, with a tired team and a ringing phone, is not.
Nothing Here Is on Sale Yet
This validation platform is in development. It is not available to purchase, license, or pilot today, and nothing described in the capability list is shipped behavior. We publish the design because the underlying practice, restoring into isolation and measuring what happens, is something you can begin without any product at all.
Immutability Is a Claim You Have to Test
Vendors offer retention locks, object lock, air gaps and immutable tiers, and a feature being enabled is not the same as that feature being effective. The questions worth asking are whether the backup console authenticates against the same directory as the systems it protects, whether an administrator of that console can shorten retention on their own, whether deletion requires a second person, and how you would detect an attempt. Treat backup infrastructure as production, because working backups are what let a victim decline to pay. Any credential able to administer both production and backups undoes much of the design around it.
A Tabletop and a Restore Test Find Different Problems
Discussion exercises surface decision failures. Who declares an incident, who is authorized to approve or refuse a payment, who speaks to customers, whether anyone has phone numbers once the mail system is down. Technical restore tests surface a different class entirely: missing encryption keys, a database that restores but will not start, an application that depends on a license server nobody backed up, a runbook that names a person who left last year. Both are worth running, and neither substitutes for the other.
Insurers and Assessors Ask Different Questions
An auditor asks whether a documented process exists and was followed. An insurer or broker asks what you can demonstrate about recovery capability, and those questions reach into backup isolation and testing detail that a policy document does not answer. How either audience judges what you produce is not ours to promise. What you can control is having dated restore records, measured durations, and a list of known gaps with named owners already in hand rather than assembled against a deadline. That material is the same evidence described on our security compliance readiness page.
If You Have Never Restored Anything, Start Small
Pick one system that matters and restore it into an isolated environment. Time the whole thing end to end, including the hours spent hunting for credentials and waiting on transfers. Try to start the application, not only to recover the data. Write down everything that surprised you, because those surprises are the actual gaps in the plan and they do not turn up in a document review. If an incident is already underway, the containment and evidence questions on our incident response page come first and this work comes after.