Backups you have actually restored from.
Protection engineered against a stated recovery point, held where ransomware cannot reach it, and tested on a schedule — because an untested backup is a hypothesis.
Why backups fail when they are finally needed
Almost every organisation has backups. Far fewer have restored from them recently, know how long a restore would take, or hold a copy an attacker with domain credentials could not delete. The gap between having backups and being recoverable is where the damage happens.
- The last full restore test was more than a year ago, or has never happened.
- Backups are reachable using the same credentials that administer production.
- Nobody can state the recovery point objective for a given system in hours.
- Backup jobs report success, and nobody checks what they actually captured.
What we build
A protection design derived from what the business can tolerate losing, with immutable copies, verified restores and evidence you can hand to an auditor or an insurer.
- A recovery point objective per system, agreed with the business rather than assumed by IT
- Backup scheduling and retention that meets those objectives
- Immutable or air-gapped copies that compromised credentials cannot delete
- Encryption in transit and at rest, with key custody defined
- Automated restore testing on a schedule, with the results recorded
- Monitoring that alerts on failure, and on success that captured nothing
How it runs
Start from what the business can afford to lose, then work back to the schedule.
- 01Set the objectives
For each system, how much data the business can tolerate losing. That number sets the backup frequency, not the other way round.
- 02Protect the copies
At least one copy immutable or offline, held outside the credential boundary that administers production.
- 03Schedule to the objective
Frequency and retention derived from the agreed recovery point, per system rather than one policy for everything.
- 04Test restores automatically
Scheduled restores into an isolated environment, verified and recorded. This is the step that turns a hypothesis into a capability.
- 05Monitor meaningfully
Alerting on failures and on jobs that succeeded while capturing nothing — the failure mode nobody watches for.
What changes once it is running
The difference between having backups and being recoverable.
Restores are proven
You know they work because they are performed on a schedule, not because the job log says success.
Ransomware has less leverage
An immutable copy outside the production credential boundary changes the negotiating position entirely.
Exposure is quantified
Recovery point is a stated number per system rather than a hopeful assumption.
Evidence exists
Test results and retention records are available for auditors and insurers without a scramble.
How an engagement is shaped
The current-state assessment is usually uncomfortable and always worth doing.
Assessment
One to two weeks establishing what is protected, what is not, and what a restore would actually take today. The gap list is yours regardless of what follows.
Implement
Protection built to the agreed objectives, including immutability and automated restore testing.
Operate
Optional managed operation: monitoring, test verification and periodic review as systems change.
Common questions
The things buyers ask before they commit. If yours is not here, it is a good first question for the assessment.
- We back up to the cloud already. Is that enough?
- It depends entirely on whether those copies are immutable and whether the credentials that administer production can delete them. Cloud storage that a compromised admin account can wipe is a copy, not a protection.
- How often should restores be tested?
- Frequently enough that a failure is found before you need it. For critical systems, monthly automated restore verification is a reasonable baseline, with a full rehearsal annually.
- Is this the same as disaster recovery?
- No. Backup protects the data and answers "how much could we lose". Disaster recovery restores the service and answers "how long until we are running". You need both, and they are designed differently.
When did you last restore from backup?
If the answer is a shrug, that is the finding. We can establish the real position in a fortnight.