“We have backups” is reassuring. The more useful question is: “Could we get the right information back, and could we use it?”
You do not have to become a backup specialist to find out. Ask your provider for coverage, a recent restore result, and any limitations. If nobody can show a test, make that your next action.
Find out what is included
List the systems that keep the business running: email, shared files, accounting, customer records, and any specialist application. Ask which are backed up and which are excluded.
Cloud hosting does not by itself tell you what recovery is available. A provider may offer versions or deleted-file recovery with specific limits. File synchronization may also copy an accidental deletion. Ask what independent backup arrangement exists rather than assuming every cloud service is covered.
For each important service, get answers to these questions:
- What data, settings, and permissions are included?
- How often is it backed up, and how far back can we recover?
- Who checks failures, and what happens when that person is away?
- Can the same compromised account delete both the originals and the backups?
- When was a restore last completed and checked by someone who uses the data?
A successful backup job is only part of the answer
A job report can show that a scheduled copy completed. It does not, on its own, establish that the right files were included, the application can open them, or your team can access them with the correct permissions.
CISA recommends regularly testing backup procedures and protecting backups from attack. Its StopRansomware Guide explains why recovery planning matters. The safe sample test below is a practical first exercise, not a substitute for a full recovery plan.
Ask for a safe sample restore
Have your provider choose a small, approved sample and restore it to a separate, controlled location. Do not delete live files, overwrite production, or disconnect security controls to create a test. If an actual compromise is suspected, coordinate with the incident lead before ordinary restoration work.
Agree on the data, destination, authorized operator, expected cost, and cleanup before starting. Avoid sensitive real records if an appropriate test dataset will do. Your provider should choose a suitable method for databases and applications, where a file-only restore may not be enough.
The business owner or a staff member familiar with the records should help validate the result. Check:
- The expected files and versions are present.
- Representative content opens and makes sense.
- Intended users can access it and unrelated users cannot.
- Required application checks pass for the scope being tested.
- Any missing items, errors, and delays are recorded.
Measure two things in plain English
How long could we be unable to work? This is the recovery-time target, sometimes called RTO. Set it based on business needs, then compare it with tested capability. Measure through validation, not just the time spent copying files.
How much recent work could we afford to lose? This is the recovery-point target, sometimes called RPO. Compare the time of the restored data with the point you needed to recover to. A backup made yesterday may not meet a need to recover this morning’s orders.
Choose targets with management and your provider. A small file restore does not prove the entire business could recover in the same time.
What a meaningful result looks like
In an illustrative test, the provider restores a sample project folder successfully. The file count and contents match, but a worker cannot open the folder because its permissions were not restored correctly.
That is a partial result. Assign the permissions issue to an owner, correct the process, and repeat the test. Recording the limitation gives the business more useful information than calling the exercise a success because files appeared.
A message you can send your provider
Please confirm backup coverage and exclusions for [systems], who monitors failures, and the latest validated restore result. If we have no recent test, please propose a safe sample restore to a separate location. Include the scope, cost, expected timing, validation steps, and how test data and temporary access will be cleaned up.
Keep a short record and repeat proportionately
Record the system, restore point, start and validation times with time zones, checks performed, result, limitations, and follow-up owner. Protect the record and restored data; do not include credentials or recovery keys in ordinary notes.
Schedule future tests based on business risk, changes, contracts, and applicable obligations. Include fuller-service recovery when needed. NIST also provides guidance for providers on maintaining and testing backups.
If a customer asks you to describe your recovery process, use these actual results when answering their security questionnaire. Your next step today is simple: ask for the latest restore result, not just the latest backup report.