OT Backups: How to Test Restoration Without Touching Production

An operational technology backup is useful only when an authorized team can locate it, understand what it contains and restore the system under controlled conditions. A file copied to a server is not the same as a tested recovery capability. NIST's OT security guidance treats backup and restoration as part of availability and recovery planning, which gives equipment owners a basis for asking better questions during a support handover.

Define what must be recoverable

List the controller programs, configuration files, system images, firewall rules, access-control lists and other data the process depends on. Separate information needed to restart a particular component from information needed to restore the complete workcell. An asset inventory can identify where each item belongs, but the recovery plan should state the order and authority for using it.

The NIST Guide to Operational Technology Security describes backup and restoration as ways to improve OT availability and lists operational data, programs, configurations and system images as examples of important files. The guide is general; the exact backup scope depends on the equipment, process and organization.

Record ownership and version

For each backup, record the asset identifier, software version, configuration date, creator, storage location and retention period. If a file contains credentials or proprietary programs, restrict access and use the approved transfer method. A backup without an owner may exist technically but still be unusable during an incident because no one can authorize or interpret it.

Include the time zone and clock source used for the configuration date when the equipment operates across sites. If two files appear to be from the same event, consistent timestamps help reviewers establish their order. Keep a hash or other integrity check where the organization's procedure requires one, but remember that integrity does not prove the file is the correct or complete recovery image.

Keep the original and the restoration-tested copy distinguishable. A later backup may include changes that were not present when an incident occurred. Record which version was accepted for recovery and which person approved it. Do not overwrite the only known-good file without preserving the earlier record.

Test restoration without risking production

A restoration test should use a controlled environment, spare hardware or an approved simulation where possible. Define the test objective, the files used, the expected result and the rollback plan before starting. Do not restore an image to a live controller or interrupt a production cell simply to confirm that a file opens.

NIST's OT security publication page frames the guidance around OT's performance, reliability and safety requirements. That context matters: a recovery test should protect the physical process as well as the data and should be approved by the people responsible for the equipment.

Capture the elapsed time, messages, missing dependencies and differences between the restored environment and the production configuration. A file that loads successfully may still require licenses, calibration, network settings or external machine interfaces. These dependencies belong in the test record rather than being discovered during an emergency.

Use more than one recovery location

NIST discusses a backup-in-depth approach with recent local copies and protected copies for larger incidents. The relevant storage design depends on the site's risk and connectivity. Identify which copies are available when the normal network is unavailable and which are protected from unauthorized changes.

Check that backup media, encryption keys and access procedures remain available to the people responsible for recovery. A protected archive can become an operational gap if its key owner leaves or if the format cannot be read by the current equipment. Review the access path during each planned exercise.

Include restoration in the service agreement

Ask the equipment supplier or integrator what files they need, what they will restore, and who is responsible for validating the result. Put the service scope, response time and information handling terms in writing. If an external provider holds the only copy of a configuration, agree how the owner can obtain an authorized copy and how credentials are protected.

Record any hardware or software dependency that is no longer supported. A recovery plan based on an unavailable controller image or obsolete license may need a migration path. Keep that risk visible instead of assuming that an old backup guarantees an old system can be rebuilt.

Close the exercise with evidence

After a restoration test, record what worked, what failed, the corrective action and the next review date. Link the results to the asset inventory and the relevant support contact. A tabletop exercise can verify responsibilities and communications even when it cannot test the physical controller; label its scope clearly.

For related equipment records, see our connected-equipment inventory guide and browse the smart equipment archive. A tested, owned and versioned backup gives a recovery plan practical value.