A backup plan has to work through four distinct responsibilities.
- 01
Protect
Define the systems, data, method, storage, retention, and access controls in scope.
- 02
Monitor
Watch agreed jobs and investigate failures instead of assuming that scheduled means successful.
- 03
Test
Restore selected data on an agreed cadence and record whether it opens and works.
- 04
Recover
Follow a documented sequence with clear owners when a real recovery is needed.
Every backup plan should answer these in writing.
Most backup disappointments trace back to an assumption nobody recorded. These six answers expose the assumptions before a recovery depends on them.
- 01
What is covered?Name the machines, applications, and data instead of assuming everything is included
- 02
Where is it stored?Cloud, local, or both, in approved locations with defined access controls
- 03
How long is it retained?State the retention window, storage allowance, and what happens when either is reached
- 04
Who watches failures?Assign responsibility for alerts, investigation, reporting, and remediation
- 05
When was a restore tested?Record the date, workload, destination, result, and person who verified it
- 06
What happens during recovery?Define the order, decision-makers, communications, and responsibilities before the incident
Coverage, method, retention, storage allowance, location, encryption, testing cadence, recovery responsibilities, recovery objectives, exclusions, and pricing are defined in the applicable agreement.
RPO and RTO turn “quickly” into two questions the business can answer.
The public page does not invent a number. Where objectives are contractually confirmed, the agreement states them for the covered workload.
Recovery Point Objective
How much recent data could the business afford to recreate?
The answer guides backup frequency and depends on the workload.
Recovery Time Objective
How long could a service be unavailable before operations are materially affected?
The answer guides recovery design and priorities.
Restore testing
A green tick means the job ran. It does not mean the data comes back.
Backup software reports on whether it completed, not on whether what it produced is usable. A job can succeed for months against a database that was never quiesced properly, or a machine whose most important folder stopped being included after a rebuild.
The only way to know is to restore something and open it. We do that on an agreed cadence, record the result, and tell you when a test fails — which is the useful moment to find out, because there is nothing else going wrong that day.
Scoped in your agreement
Which workloads are test-restored, how often, to where, who witnesses or signs off the result, and how failures are reported and remediated.
Testing raises confidence that a recovery will succeed. It is evidence, not a guarantee.
Recovery
The worst time to design a recovery is during one.
Accidental deletion, equipment failure, ransomware, a failed update — the events differ, the first hour does not. Someone has to decide what is being recovered, to where, in what order, and who tells the rest of the organization what to expect.
That sequence belongs in a document written on a calm Tuesday. Where recovery point and recovery time objectives are contractually confirmed, they are stated in your agreement in terms you can hold us to — and where they are not, we say so rather than implying a number.
Scoped in your agreement
Recovery procedures, escalation and decision-making, the order systems are restored in, what your team does, what we do, and any recovery point or recovery time objectives that have been confirmed.
Recovery duration depends on data volume, available infrastructure, and what you are recovering to.
We will never tell you your data is safe.
It is a comforting phrase that commits to nothing and cannot be tested. Here is what we will tell you instead — and what no backup service can honestly claim.
Existing is not the same as recoverable
A backup existing does not guarantee recovery. Coverage gaps, corruption, and untested restores are ordinary, and they are only discovered by testing. We report what has been verified and when.
Recovery times are contractual or they are guesses
We state recovery point and recovery time objectives only where they have been confirmed in your agreement. Any provider quoting a recovery time before scoping your data volume and target infrastructure is estimating.
Not a complete answer to ransomware
Recoverable copies limit the operational impact of an attack. They do not prevent one, and modern attacks deliberately target backups — which is why isolation and access control are part of the design. Managed cybersecurity
Nothing here is set and forget
Environments change. New machines appear, applications move, folders get reorganized, and a scope agreed last year quietly stops matching the business. Coverage is reviewed, not assumed.
Ask your current provider the first one today.
If the answer takes more than a minute to produce, that is the finding.
01When did you last prove a restore actually works?
This is the question that separates a backup service from a backup subscription. A dashboard of green ticks answers whether jobs completed. It does not answer whether the data comes back.
Ask for the date of the last successful test restore, which workload it covered, and who verified the result. A provider running real tests will have that to hand, because they wrote it down when they did it.
02How long would it take to get us running again?
It depends on how much data is involved, what infrastructure is available to recover onto, and whether you are restoring a file, a database, or an entire server. Those variables change the answer by orders of magnitude.
We scope it against your environment and state any recovery time objective in the agreement. We will not quote you a figure we have not committed to contractually — that number only matters on the day it is tested.
03Isn't backup already part of managed IT?
Backup oversight and recovery coordination for covered workloads sits inside managed IT — we watch the jobs and coordinate a recovery.
The backup platform itself, storage allowance, retention, encryption, testing cadence, and recovery objectives are scoped and priced separately, because they depend entirely on how much data you hold and how far back you need to reach.
04Will backups protect us from ransomware?
They reduce the operational impact of an attack by giving you somewhere to recover from, which is genuinely valuable. They do not prevent the attack, and they are not a security programme.
Attackers routinely go after backups first, so how copies are isolated, who can delete them, and whether credentials to the backup platform are separated from everyday admin accounts all matter. That is design work, and it belongs in the same conversation as your security programme.
05Where is the data actually held?
In approved locations that you agree to before anything is configured — cloud, local, or both, depending on how quickly you need to recover and what you are protecting against.
Where data resides is not only a recovery question. For organizations handling sensitive or regulated information it affects your obligations too, which is worth settling alongside a readiness assessment rather than after one.
Find out what is really covered.
A backup review establishes which systems are actually in scope, how far back you can reach, where copies are held, and when a restore was last proven to work. Most organizations find at least one assumption that was never true.
Or call (734) 772-9499 · A human answers