- The asset inventory, to know what should be backed up at all
- Access to the backup tool's job history and destination configuration
- The business's recovery-time expectations — how long each system can be down before it hurts
ATL-024WORKSHEETEDITORIAL REVIEW COMPLETE
Backup Inventory and Restore-Test Worksheet
Two tables that turn 'we have backups' into a verifiable claim: an inventory of what is backed up, where, and with what protections, and a restore-test record measuring actual recovery times against targets. Built on one rule — an untested backup is an assumption.
Using this artifact
Purpose, inputs, and completion
Purpose. Backups are the safeguard everyone claims and few can demonstrate. This worksheet forces the two demonstrations that matter: an inventory proving each important system is actually protected — including at least one copy an attacker with admin credentials cannot reach — and a restore-test record proving recovery happens within the time the business can survive. Together they convert a comfortable feeling into measured fact.
When to use it. Fill the inventory from the backup tool's own configuration and job history, then reconcile against the asset inventory — the gap between the two lists is the finding. Schedule restore tests from the inventory rows, run them, and record actual numbers, including the failures; a failed test recorded honestly is the system working. Revisit quarterly, and treat any system whose 'last success' cell is older than its frequency claim as unprotected until shown otherwise.
- Build the inventory from what the backup tool actually protects, then compare it against the asset inventory to find what silently is not.
- Verify each offline or immutable copy claim by inspecting the configuration, not by recalling the sales pitch.
- Run restore tests on the schedule each row sets and record actual times against targets — an untested backup is an assumption, not a capability.
- For production systems, record recovery dependencies — vendor images, license servers, controller programs — because the backup file is only one ingredient of a restore.
Keeping it honest
Evidence, validation, and failure modes
- A dated inventory of what is backed up, where, and with what protections
- Restore-test records with measured times against targets
- A recovery-dependency list for production systems
- Pick one critical system and perform a file-level restore this week; time it and record it — the row becomes real the day this happens.
- Compare this inventory against the asset inventory: every system marked critical there appears here, or its absence is a written decision.
What looks done but is not
- Backup health is read from job-completion emails; the jobs run nightly, but nobody has restored anything in a year — an untested backup is an assumption.
- Every copy is online and reachable with domain credentials, so the ransomware that takes the systems takes the backups in the same hour.
- The controller program restores perfectly, but the machine needs a vendor license server nobody inventoried — and a two-hour recovery target becomes a two-week vendor engagement.
Mapped relationships
Practices and requirements this artifact relates to
Brilliant at the Basics practices
NIST SP 800-171 Rev. 2
NIST SP 800-171 Rev. 3
Relationships are mapped support, not equivalence: completing this artifact documents work relevant to these requirements and does not by itself address any of them. Retention: Retain restore-test records for at least two test cycles per system; a dated pass from last year plus one from this year shows a working capability, not a lucky day.
Full document
Preview — exactly what prints
WORKSHEET · BACKUP & RESILIENCEv1.0 · REVIEWED 2026-08-06
Backup Inventory and Restore-Test Worksheet
Brilliant at the Basics Resource Center · brilliantatthebasics.us · published by inDirectIT, Inc.
Independent educational material. Not affiliated with, sponsored by, approved by, or endorsed by the U.S. Department of War. Does not establish compliance, certification, or contractual standing.
Purpose
Backups are the safeguard everyone claims and few can demonstrate. This worksheet forces the two demonstrations that matter: an inventory proving each important system is actually protected — including at least one copy an attacker with admin credentials cannot reach — and a restore-test record proving recovery happens within the time the business can survive. Together they convert a comfortable feeling into measured fact.
How to use it
Fill the inventory from the backup tool's own configuration and job history, then reconcile against the asset inventory — the gap between the two lists is the finding. Schedule restore tests from the inventory rows, run them, and record actual numbers, including the failures; a failed test recorded honestly is the system working. Revisit quarterly, and treat any system whose 'last success' cell is older than its frequency claim as unprotected until shown otherwise.
Backup inventory
One row per system worth recovering. The offline / immutable column is the one ransomware cares about: a copy that domain-admin credentials can delete is not a safe copy.
Rows beginning EXAMPLE: show the expected shape — replace them with your own.
| System | What is backed up | Frequency | Destination | Offline / immutable copy? | Encryption | Owner | Last successful backup |
|---|---|---|---|---|---|---|---|
| EXAMPLE: File server (FS01) | All shares incl. project library | Nightly incremental, weekly full | Backup appliance + cloud vault | Yes — cloud copy immutable 30 days | At rest and in transit | IT leader | 2026-08-04 |
| EXAMPLE: Line 2 PLC program | Controller program and HMI project | After every approved change | Version repository + USB in fire safe | Yes — offline USB copy | Repository encrypted; USB in locked safe | OT engineer | 2026-07-22 |
Restore-test record
An untested backup is an assumption. One row per test — including the failed ones, which are the tests earning their keep.
Rows beginning EXAMPLE: show the expected shape — replace them with your own.
| System | Test scenario | RTO target | Actual restore time | Data-loss window (actual) | Issues found | Pass / fail | Next test date |
|---|---|---|---|---|---|---|---|
| EXAMPLE: File server (FS01) | Full restore of project library to spare hardware | 4 hours | 5.5 hours | 18 hours (last incremental) | Restore saturated office link; schedule off-hours | Fail — over target; rerun planned | 2026-09-15 |
| EXAMPLE: Accounting system | Single-database restore to test instance | 8 hours | 2 hours | 24 hours | None | Pass | 2027-02-01 |
Record the failures
A restore test that misses its target and gets written down has done its job: it found the surprise on a Tuesday afternoon instead of during an outage. The worksheet loses its value the day someone starts recording only passes.
OT recovery dependencies
Restoring a production system takes more than the backup file. List everything a real restore would need and where each piece actually is.
Rows beginning EXAMPLE: show the expected shape — replace them with your own.
| Production system | Dependency | Where it lives / who holds it | Verified how / when |
|---|---|---|---|
| EXAMPLE: Line 2 packaging line | Vendor recovery image for HMI PC | USB in fire safe + vendor portal account | Booted spare PC from image, 2026-06 window |
| EXAMPLE: CNC cell | License server for CAM software | VM on host ESX2 — single point of failure | Identified during tabletop; VM now in nightly backup |
OT restore tests happen in windows, with the process owner
Never run a restore test against live production. Test to spare hardware or in an approved maintenance window with the process owner present, a tested rollback, and — where the equipment is vendor-supported — the vendor scheduled in advance. A restore that needs the machine builder's engineer works only if that engineer's availability is part of the recovery plan, not a surprise.
Document control, version history, and approval
An artifact without an owner, a review date, and an approval trail is a snapshot, not a record. Complete this section before the document is used, and update it at every review.
| Field | Entry |
|---|---|
| Document owner (named person) | |
| Suggested owner role | IT leader |
| Approval authority | Executive sponsor |
| Review frequency | Quarterly for the inventory; restore tests on the schedule each row sets, at least annually per critical system |
| Next scheduled review | |
| Storage location of the completed document | |
| Retention | Retain restore-test records for at least two test cycles per system; a dated pass from last year plus one from this year shows a working capability, not a lucky day. |
Version history
| Version | Date | Author | Summary of change | Approved by |
|---|---|---|---|---|
Review and approval
| Reviewed by | Role | Date | Signature / initials |
|---|---|---|---|
Complete this offline — and mind what you write down
Fill this in inside your own environment, not on any public website or unapproved cloud tool. A completed copy may reveal your security posture: never include CUI, export-controlled data, credentials or keys, unremediated vulnerability details, network diagrams, or customer-sensitive information beyond what the artifact strictly needs, and store the completed document with the same care as the systems it describes.
What completing this artifact does and does not do
This is independent educational material. Completing it documents your work and produces records a reviewer can examine — it does not, by itself, implement a safeguard, satisfy any NIST SP 800-171 requirement, establish compliance with DFARS or CMMC, or replace your own analysis within your defined system boundary. Requirement references are mapped relationships, not equivalence claims. Tailor every section to your technical, operational, contractual, regulatory, and safety requirements.