For a system you cannot patch, back up the system image, the application and its configuration, and the data. Keep copies off the network the system lives on, protect them from tampering, and test a full restore on a schedule. Recovery is the control that still works if prevention fails.
Why backups matter more here
If a flaw cannot be fixed, you are betting that isolation and monitoring hold. A backup is what you rely on when they do not. It also helps with a less dramatic problem: old hardware dies, and the only person who knew how the system was configured has left.
NIST's system backup control asks for backups of user-level information, system-level information and system documentation including security documentation, and for protecting the confidentiality, integrity and availability of the backup. Its guidance defines system-level information as including system state, operating system software, middleware, application software and licenses, and notes that integrity protections for backups can include digital signatures and cryptographic hashes.
What to include
| Item | Why legacy systems need it specifically |
|---|---|
| Full system image | Rebuilding an old OS from scratch may be impossible if install media is gone |
| Application binaries and installers | Vendors may no longer offer downloads |
| Licenses and activation keys | Often lost with the original purchaser |
| Configuration and scheduled jobs | Undocumented settings are the usual surprise |
| Data and databases | The reason the system exists |
| Documentation and diagrams | Including the isolation plan and firewall rules |
Protect the copies
- Keep at least one copy off the legacy segment. If ransomware reaches the system, it should not reach the backups through the same path.
- Use a separate credential for the backup system. Do not reuse a domain admin account.
- Prefer write-once or immutable storage where you have it. Otherwise keep an offline copy.
- Record hashes. NIST mentions cryptographic hashes as an integrity mechanism. A hash lets you notice a changed backup.
- Encrypt backups that leave the building. Manage keys separately.
Test the restore, not just the backup
A backup job that reports success proves little. Run a restore test at least on a set schedule, and after major changes:
- Restore the image to an isolated test environment, matching hardware or virtualization as closely as you can.
- Start the application and run a short checklist: login works, a key transaction completes, a report prints.
- Record the time taken. This is your honest recovery time.
- Note what was missing and fix the backup scope.
Because the system is old, expect surprises such as a hardware dongle, a license server or a driver that the new platform lacks. Finding these in a test is cheaper than finding them during an outage.
Write it into the exception
Add the backup location, the schedule, the last successful restore test date and the measured recovery time to the exception record. A reviewer reading it can see what happens in the bad case, not just how you hope to avoid it.
Quick check
Is a snapshot on the same storage a backup?
Not on its own. A snapshot on the same array and the same network shares the same failure and attack paths. Keep a separate copy.
How often should I test restores?
Pick a schedule you will keep, such as yearly for low impact systems and more often for critical ones, plus after any significant change.
Sources
- NIST SP 800-53 Rev 5 control catalog (OSCAL JSON, NIST oscal-content repository) (CP-9 System Backup)
Last reviewed: 19 October 2026.
