This backup checklist marks a backup setup on 15 checks in three groups: jobs, alerts and restore tests. Backup verification shows that a copy is intact. Restore testing shows that a person can use it, and the list scores both. Each row names a task, the evidence to keep and a yes-or-no test. A recovery point is the moment in time a copy represents.
Last reviewed 2026-11-02 by Manish Sharma.
This list suits an IT manager at a firm of roughly 250 to 2,000 people in India or the GCC, who marks one set of systems at a time. It rates the setup and its evidence, not the recovery plan. The marks are Signisys’ own method. Besides that, the two sources are US guidance from CISA and vendor documentation from AWS, not local rules.
Backup Checklist in Short: 15 Checks, Three Groups
Overall, the list rates one setup by the evidence you can show today.
Jobs are checks 1 to 5, alerts are checks 6 to 9 and restore tests are checks 10 to 15. The top mark is 30, and the total is not a certificate.
In Signisys’ view, jobs come first because alerts and tests mean little until you know what each job copies. Backup verification and restore testing differ. Verification shows a copy is intact, while a restore test shows a person can use it. These are working definitions, not a standard. Backup verification needs a person who reads the evidence, not only a tool that reports it.
Four things are not checks on this list, and each has a home elsewhere:
- The recovery plan list scores the plan and its targets.
- Copies out of an attacker’s reach are checks 8 to 11 of the scored ransomware list.
- The whole-plan exercise has a guide of its own.
- Good practice, silent failures and monitoring tools each have a separate Signisys article.
Marks for the List: Checked, Assumed or Unknown
First, put the marks on a sheet of your own, one row per check, so the sheet doubles as the record.
- Checked, 2 points: a person looked at the copy, the log or the restored file itself, and saved what they saw with a date where someone who was not there can open it.
- Assumed, 1 point: a tool, a dashboard or a colleague says it is so, and nobody has looked at the thing itself.
- Unknown, 0 points: nobody can say, or the thing does not exist.
Also, where a row says sample, take three systems from different groups. For example, pick one server, one cloud workload and one SaaS tool, and mark the weakest of the three.
Mark a row that does not apply as N/A, and take its 2 points off the maximum. For instance, a firm with no database marks check 11 N/A, so the maximum falls from 30 to 28.
Here is an illustration, not a client. The dashboard shows green for a file server. Nobody has opened the restore-point list, so check 3 scores Assumed, 1 point. Then a person reads the timestamp of the newest restore point on three systems and saves a screenshot. The mark becomes Checked, 2 points.
There is no target total and no band, because 30 is arithmetic, not a standard. Backup verification here means reading the copy itself, so a tool’s own status does not count.
Key Takeaway A green dashboard that nobody has compared with a copy earns one point, however long it has been green.
Backup Checklist, Group 1: Jobs and Backup Verification, Checks 1 to 5
This part of the backup checklist covers the jobs. They must cover the right systems, run on time and leave an intact copy. Backup verification, the proof that a copy is intact, covers checks 1 to 5. However, proof that it is usable belongs to the restore group.
Checks 1 to 3: Scope, Schedule and Age of the Last Good Copy
| Check and task | Evidence to keep | Checked when |
|---|---|---|
| 1. Every system on a job list: set the inventory of servers, cloud workloads and SaaS data beside the job list, and give each system an owner. | A dated side-by-side list of systems and jobs. | Yes if each business-critical system has a job, or a written reason it has none. |
| 2. Schedule matches the recovery point: write the recovery point objective (RPO, how much recent data the business can lose) next to each job’s real interval. | The objective, the person who agreed it, and the job schedule. | Yes if the interval is no longer than the objective on the sample of three. |
| 3. Age of the last good copy: read the timestamp of the newest usable recovery point, not the date of the last report. | A screenshot or export that shows the date. | Yes if the age sits within the accepted recovery point on the sample of three. |
Open the restore-point list and read the date of the newest usable point, because a report’s date is not the copy’s date.
Checks 4 and 5: Completion Detail and Target Health
Reading the log is part of backup verification, because a green colour can hide the detail. Backup verification also covers the health of each target.
| Check and task | Evidence to keep | Checked when |
|---|---|---|
| 4. Skipped items and size read, not just the colour: open the last job’s log, read the skipped-item and warning counts, and compare the size or file count with the run before. | The log page and the two figures. | Yes if skipped items are zero or each has a written reason, and any jump or drop in size has an explanation. A size comparison alone does not show that a copy is intact. |
| 5. Target space and credentials watched: list the free space on each target and the expiry date of each credential, key or token the job uses, plus a spare path if one fails. | The list, with dates or readings. | Yes if each item has a date or reading and a named person who renews it. A full target or an expired credential can stop a job, though no rate backs that claim. |
Key Takeaway A check earns Checked only when the evidence sits where a stranger can open it.
Backup Checklist, Group 2: Alerts, Checks 6 to 9
This backup checklist gives alerts a group of their own. A job that does not start may produce no failure message. Checks 6 to 9 ask who receives the alert and what counts as silence. They also ask whether the path stands alone and whether anyone acts. Also, a separate Signisys article explains how copies fail without anyone noticing.
Checks 6 and 7: Who Is Told and What Counts as Silence
| Check and task | Evidence to keep | Checked when |
|---|---|---|
| 6. A failure reaches a named person and a deputy: write who gets the failure alert, who covers when they are away, and where it arrives. | The alert rule, with its recipients. | Yes if both people are current staff and the alert lands where someone reads it. |
| 7. A missing run raises an alert too: add an alert for no good copy within the accepted age, so a job that does not start is caught. | The rule and its threshold. | Yes if the rule exists and has fired, in a test or in a real case. |
Checks 8 and 9: An Independent Path and a Follow-Up
| Check and task | Evidence to keep | Checked when |
|---|---|---|
| 8. The alert path does not depend on what it watches: confirm that the alert does not use the same account, network or mailbox as the job it reports on. | A note of the path, and a test message received. | Yes if a test message reached a person by a route the job’s system does not control. |
| 9. An alert becomes a ticket with a closing note: take three recent alerts, or send a harmless test alert if none exists, and follow each to a closed ticket with an owner. | The ticket references. | Yes if each alert in the sample has an owner and a closing note. The sample rule applies. |
Key Takeaway The list asks for an alert on a missing run, because a job that does not start may send no failure message.
Backup Checklist, Group 3: Restore Testing, Checks 10 to 15
Group 3 of this backup checklist covers restore testing. A person restores copies to prove they can be read and are complete. CISA’s #StopRansomware Guide says to maintain offline, encrypted backups of critical data. It also says to test their availability and integrity regularly (September 2023 version of the guide). It gives no interval, so this list gives none either.
The AWS Backup developer guide describes restore testing for the resource types it lists, such as Amazon EBS, EC2, RDS and S3. A plan sets a frequency and a start time, you choose specific or random recovery points, and AWS Backup starts the restore jobs and monitors the time they take. Validation is optional, and the service deletes the resources involved once validation completes or its window closes. Automation can run the restore, but a person still decides what counts as valid. A mark of Checked therefore needs a person to have read the result.
First, this group restores from copies to prove they open. The whole-plan exercise has a declared failure and a running clock. It sits in a guide to testing the whole plan and its scored version.
Checks 10 to 12: A File, Some Data and a Whole System
Next, restore testing climbs from one file to a whole system.
| Check and task | Evidence to keep | Checked when |
|---|---|---|
| 10. A sample file restored and opened: restore one file to a separate place and have a person open it. | The file name, the date and the person who opened it. | Yes if the file opened and matched what was expected. The sample rule applies. |
| 11. Database or application data restored to a scratch location, meaning a separate area used only for tests: run a simple query or open a record. | The query and its result. | Yes if a person read the result. Mark N/A if the firm holds no database. |
| 12. One whole system restored in isolation and timed: restore one server or workload to an isolated place, and stamp the start and the finish. | The two times, and a screenshot of a login. | Yes if the system started and a person signed in. Compare the time with the recovery time objective (RTO, how long the business can wait) if one is agreed. No failover or runbook drill belongs here. |
Checks 13 to 15: An Older Copy, Another Person, a Written Record
Finally, restore testing also needs an older copy, a second pair of hands and a written record.
| Check and task | Evidence to keep | Checked when |
|---|---|---|
| 13. An older copy restored, not only the newest: restore from a recovery point near the far end of retention, or from a date a few weeks back that the business names. | The recovery point date and the restored item. | Yes if the older copy opened. |
| 14. Restored by someone who did not set the job up: a deputy or colleague follows the written steps, asks questions and logs them. | The question log. | Yes if the deputy completed the restore and every question has a written answer. |
| 15. Each test written down and each failure followed up: record the date, scope, result and time of each test, and open a ticket for each miss. | The record. | Yes if a stranger can open the record and every miss has an owner and a date. Agree written success criteria before each test. |
From Marks to a Fix Order for Your Backup Checklist Result
A backup checklist result is more than the total. Add the marks, subtract 2 from the maximum for each N/A, and write the result as x of y. Then read the rows before the total, because one Unknown can matter more than three Assumed.
You would not know when copies go stale.
Restore a file and some data.
Cover every system and match the schedule.
Read the logs, and put dates on space and credentials.
Write each one down.
Backup verification and restore testing then run together: re-mark only the rows that changed. This order is a judgement, with no calendar and no cadence rule behind it.
Limits of the Marks: One Setup, One Day, One Reader
The marks show what the marker could find on the day. A second reader who opens three rows cold shows whether the evidence stands alone. In Signisys’ view, that second read is worth more than a polished first draft.
The total is arithmetic over one sample of systems, read once. It is not a certificate, a rating or a pass mark. CISA and AWS are US government guidance and vendor documentation, not Indian or GCC rules. Your regulator, contracts or auditor set any rule that applies.
For which copy to restore from, see the comparison of copy types, and for tamper-resistant copies see immutable copies. The practices behind a good setup and the criteria for monitoring tools each have a separate Signisys article.
Ask for outside help in these cases:
- Nobody owns the sheet.
- A check needs a restore of production data, and nobody has clearance to run it.
- Two rounds in a row leave the same check Unknown.
Signisys provides data protection, backup and cyber recovery solutions, as well as cybersecurity services. Read this as a description of a Signisys service, not neutral advice. Our pages on improving backup reliability and data protection and cyber recovery set out the approach.
Backup Checklist FAQ
What is the difference between backup verification and a restore test?
Does a green backup report earn full marks?
Can an automated restore job count as Checked?
Which checks should a very small team mark first?
Can a firm in India or the GCC use a list built on CISA and AWS guidance?
Can one person mark all 15 checks alone?
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.