A folder of recent control-system projects can look reassuring until someone needs to recover an asset and finds that the compatible software version, a license, or an engineering cable is missing. Ask whether an authorized team could rebuild and verify the intended function, then return it to service within the plant’s safety constraints. An inventory and bounded tests completed before an incident help answer that question.
In June 2026, NIST published a short guide specifically for OT backups. It recommends linking backups to change and risk management, prioritizing assets by criticality, accounting for dependencies, and testing restores on non-production systems. NIST SP 1339, pp. 1 and 2.
The guide turns those recommendations into a preparation and evidence-recording method. It does not explain how to load logic onto a PLC, write to an HMI, or intervene on a production line. Plant operators and approved site procedures remain responsible for operational and recovery decisions.
A saved copy does not prove recoverability
A backup answers a narrow question: was a version of certain files or data retained? Recoverability raises others. Can the team identify the asset it belongs to? Can it read the storage media? Are the authorized software and credentials available? Does the version still fit with the rest of the cell? Are qualified staff and compatible spare parts available? Who checks the function before the asset returns to operation?
NIST’s OT security guide treats recovery as a restoration that must account for system state and physical consequences. It warns that resetting state variables to initial or earlier values can affect a process that is still running; the appropriate state depends on the system. NIST SP 800-82 Rev. 3, §F.7.6, control CP-10, p. 251.
NIST SP 1339, a newer guide focused on OT backups, recommends testing restores on non-production systems and checking the recovered system’s functional integrity. NIST SP 1339, p. 2.
Record each stage separately:
- Backup created: a saved set is associated with an identified source.
- Backup verified: there is evidence that the stored content matches what was expected and remains accessible.
- Recovery exercised: the set was recovered within the stated test scope and passed agreed functional checks.
An integrity check such as a hash helps answer the second question. It cannot tell you by itself whether the tools, equipment, license, manuals, or validation sequence are available. NIST SP 1339 recommends keeping procedures for hash checks before restoration and conducting recurring tests outside production; these are different checks. NIST SP 1339, p. 2. CISA also recommends testing backups periodically and keeping them isolated from connections that could spread malware. CISA, FBI, and NSA, guidance for OT/ICS systems.
The goal is not to promise that an entire plant will return to its previous condition within a fixed time. A test demonstrates only what was exercised, for the configuration and scope it records. If versions, components, tools, or system relationships change, earlier evidence may no longer represent the current environment.
Inventory what is needed to rebuild the function
Start with assets that support operations and hold important configurations. NIST SP 1339 names PLCs, switches, firewalls, transmitters, actuators, DCS, SCADA servers, variable-frequency drives, and HMIs. It also recommends using criticality to set backup frequency, retention periods, and recovery sequence. The list is a starting point; each plant should compare it with its own inventory and process. NIST SP 1339, p. 1.
For each asset, document what is needed to rebuild its function. The guide includes program and logic files, configuration, input/output lists, firmware, HMI graphics, licenses, vendor configuration tools, support documentation, and operating-system or virtual-machine images where needed. It also mentions compatible spare parts alongside digital backups and defined recovery objectives. NIST SP 1339, p. 1.
The voluntary CISA Cross-Sector CPG calls for backups stored separately from source systems and tested on a recurring basis no less than once per year, and lists OT configurations, roles, PLC logic, engineering drawings, and tools as minimum backup content. That annual interval is a target in CISA’s voluntary program, not a universal rule or regulatory requirement for every plant. CISA, Cross-Sector CPG, action 2.R.
Separate the project file from the dependencies that make it usable. A project copy may be incomplete if no one knows which engineering environment opens it, which license it requires, or what hardware can run it. Cells do not all have the same dependencies, so an asset record should point to the document or inventory that confirms each relationship. A generic checklist is not a universal recipe.
At a minimum, each asset record should answer these questions:
| Field | Question to answer |
|---|---|
| Asset and functional location | Which part of the process does it support, and where is it? |
| Identifier and version | Which device, firmware, project, and revision does the backup represent? |
| Included content | Which files, documented parameters, licenses, or manuals come with it? |
| Dependencies | Which server, tool, spare, medium, or external service is required? |
| Criticality and priority | Which operation depends on it, and what recovery sequence has the plant approved? |
| Custodian and owner | Who retains the material, and who validates its use? |
| Test evidence | When were access, integrity, and recovery checked, and with what result? |
Recovery order depends on interdependencies. An engineering server, authentication system, or license may be needed before work can begin on the controller. An HMI can display values, but that does not replace checking the process. NIST recommends accounting for infrastructure dependencies and having manuals, utilities, software, cables, and specialized licenses available at the site. NIST SP 1339, pp. 1 and 2.
A peer-reviewed study by Staves and coauthors examines standards and interviews with UK critical-infrastructure operators and regulators. It proposes assessing response and recovery capability as an organizational practice, beyond merely having tools. Its setting is UK critical infrastructure; its interview findings should not be treated as representative of plants elsewhere. Staves et al., International Journal of Critical Infrastructure Protection, 37 (2022).
Tie backups to changes and trusted versions
A backup is useful only if the team can tell which approved state it represents. Associate each set with the asset, revision, capture time, source, and approved change that prompted it. Keep the information needed to compare versions without replacing the original or calling a copy current before its relationship to the installed equipment is confirmed.
NIST SP 1339 recommends integrating backup management with change and risk processes. It also says to set frequency, media, and location based on how much the information changes, system type, and risk, and to label and index media with details such as system name, date, and time. NIST SP 1339, p. 1.
This avoids an arbitrary universal schedule: an asset that changes often or whose loss could interrupt a critical operation may need different controls from one that rarely changes. Record the reason for the policy and who approved it.
NIST SP 1339 recommends redundant storage inside and outside the plant, mechanisms that support integrity and availability, and safeguards against unauthorized access, modification, or destruction. NIST SP 1339, p. 1. For its Cross-Sector CPG, CISA also recommends storage separate from the source system and recurring backup tests. That voluntary guidance does not prescribe one schedule for every plant. CISA, Cross-Sector CPG, action 2.R.
Define who may create, review, store, and retire backups; which role approves a change that affects them; and how staff record a mismatch between the inventory and the observed asset. A traceable record does not depend on one particular repository technology; it can point to an approved store. Access and custody still need clear owners.
NIST SP 1800-10 uses capabilities such as change control and file integrity in a manufacturing lab. It is a tested technical example, not an architecture every plant should copy. NIST SP 1800-10, project summary.
A vendor change, hardware replacement, firmware update, or license change can affect recovery even when the file itself remains intact. NIST SP 1339 recommends keeping documentation, specialized tools, and compatible spares available, and reviewing constraints on legacy equipment. NIST SP 1339, pp. 1 and 2. Do not treat a recent timestamp as proof that a backup is valid; confirm which state and dependencies it represents.
Test restoration away from the production process
An exercise should answer a specific question in an authorized environment. For example: “Can the team rebuild the engineering environment and confirm that the recovered project matches a known revision?” That question does not require loading logic onto a plant PLC or interrupting an operation to see what happens.
NIST SP 1339 recommends recurring restore tests on non-production systems to check media reliability, practice procedures, and verify the recovered system’s functional integrity. It also recommends cryptographic hashes where feasible and approved engineering methods for verifying OT assets. NIST SP 1339, p. 2.
NIST SP 800-82 Rev. 3 explains that testing OT backups and restores may depend on spare equipment or redundant systems. If those are unavailable, it describes alternative verification methods, including hashes or checksums. NIST SP 800-82 Rev. 3, §F.7.6, p. 251.
NIST SP 1339 puts the recommendation plainly: “Conduct recurring restoring tests of backups on non-production systems.” The wording is the guide’s; the test scope still needs to fit the site’s equipment and safety conditions.
A test might begin with an inventory and access review, continue with integrity checks, then move to an isolated recovery on a test bench, spare device, or virtual environment if it adequately represents the dependency being tested.
These checks do not prove the same thing. A hash confirms that content matches under the algorithm used; it does not confirm the system boots, the project is compatible, or the process produces an acceptable result. Functional validation needs criteria set in advance and people with the technical authority to apply them.
Agree on scope first: asset or group, selected revision, included dependencies, assumptions, owners, resources, acceptance criteria, and stop conditions. Criteria might require the material to be identified and opened, the version to match the controlled configuration, relevant functions to be checked in the test environment, and any differences to be recorded. These are planning criteria, not operating instructions for a production controller.
CISA recommends planned tests, exercises for backup equipment against realistic timeframes, and acceptance tests that allow the responsible authority to declare a system fully operational. The same document notes that ICS recovery has complications beyond ordinary IT recovery. CISA, Developing an Industrial Control Systems Cybersecurity Incident Response Capability, §4.4. NIST SP 1339 says practices should fit site operating conditions and safety requirements. NIST SP 1339, p. 2.
If the plant has no safe way to represent the asset in a test, do not turn a backup check into a production experiment. Record the limitation and decide whether one part of the procedure can be exercised without affecting physical control.
Assign that decision to the people responsible for operations, automation, and process safety, together with the vendor. A partial test can be useful if the record labels it partial; it should not be presented as a complete demonstration.
Record what the test proved and what remains open
The exercise record should let another person understand the evidence without repeating the test blindly. Note the date, asset, revision, backup source, test environment, included components, available dependencies, criteria, observations, result, owner, and follow-up action. If verification tools were used, record their version or reference when that matters for interpreting the result.
Keep milestones distinct: backup located, content readable, integrity checked, system recovered in the intended environment, function validated, dependencies resolved, and result accepted by the authorized person. Each milestone answers a different question. Do not mark a system “recovered” because someone calculated a hash or opened one file.
NIST SP 1339 says to review procedures and documents based on lessons from tests, to improve recovery readiness. It also lists technical records such as I/O lists, specifications, control narratives, cause-and-effect matrices, network and wiring diagrams, and historian configurations. NIST SP 1339, p. 2.
CISA’s Cross-Sector CPG treats backups and response plans separately, and recommends maintaining, practicing, and updating plans with common and organization-specific scenarios. It is voluntary guidance, not an audit or an automatic declaration of compliance. CISA, Cross-Sector CPG, actions 2.R and 2.S.
A test may reveal that no trusted version exists, a license is missing, or an available spare does not match the expected hardware. The useful result is not always “passed.” It may be “inconclusive” or “blocked by a dependency.” Those outcomes keep missing evidence from being mistaken for recovery capability.
Staves and coauthors describe challenges that affect the quality of response and recovery plans for UK critical-infrastructure operators. Their proposal includes capability assessment as part of organizational improvement. This is evidence about that setting, not a quantitative measure of the maturity of a particular plant. Staves et al., 2022, article abstract.
NIST SP 1800-11 presents a lab for recovering from data corruption in enterprise IT environments. It may offer ideas for structuring evidence and detecting untrusted versions, but its stated scope is not OT control. NIST SP 1800-11, summary and scope.
After each test, assign owners and review dates to findings. If the scope was partial, keep that label and schedule the next exercise based on risk, changes, and available resources. To make a recovery-time claim, measure the exercise and state its conditions. A lab result alone does not predict the duration of a real outage; dependencies, authorization, staff availability, and process constraints also matter.
Connect backup readiness to plant continuity
Backups are one part of operational continuity. The plan should connect the inventory, owners, storage, tools, spare availability, dependencies, validation criteria, contact paths, and escalation decisions. It should also distinguish recovery after technical failure from response to suspected compromise. The newest backup is not necessarily the right choice if no one knows when the system was altered.
CISA, FBI, and NSA guidance for OT recommends keeping recovery procedures with configuration parameters for common and critical equipment, testing backups periodically, and separating them from network connections that could spread malware. CISA, FBI, and NSA, critical-infrastructure guidance. The inventory section above lists manuals, tools, licenses, documentation, and spare parts the plant may need to resolve those dependencies.
Recovery objectives require a local decision. A site may define time or data-loss objectives, but these are not automatic properties of a backup and a general guide cannot set them for a plant.
Agreement requires knowing which service takes priority, which operation can remain degraded, what risks a partial restoration introduces, and what evidence makes the recovered state acceptable. CISA describes acceptance testing and explicit authorization as part of ICS recovery; NIST notes that restoring state can affect the physical process. CISA, §4.4; NIST SP 800-82 Rev. 3, CP-10.
Start with one priority asset and named operational and technical owners. Gather its inventory, known versions, dependency records, and the authorized backup location. Decide which test can be run outside production with available resources, who will validate the result, and what it will leave unproven. Set the next review date when a relevant change occurs or asset criticality calls for it.
If information is missing, the next step is to close a specific gap: locate the source file, confirm who maintains the tool, check the spare’s compatibility, or reserve a test environment. For help defining boundaries between information and operational systems, see the practical IT/OT integration guide. To connect a new backup with approved changes, see the guide to change management with evidence.
Frequently asked questions
What should an OT backup include?
It depends on the asset and what is needed to rebuild its function.
A logic file may not be enough if compatible firmware, the engineering project, licenses, graphics, drawings, spare parts, or documentation are missing. NIST recommends identifying the set required for each asset. NIST SP 1339, p. 1.
CISA also includes configurations, roles, PLC logic, engineering drawings, and tools in its voluntary goals for OT backups. The asset record should say which item is stored and where. A generic list does not show that the dependencies for a specific asset are available. CISA, Cross-Sector CPG, action 2.R.
How often should PLCs and HMIs be backed up?
There is no single backup schedule that fits every asset.
NIST recommends setting frequency according to how much the information changes, the system type, criticality, and risk, and linking backups to change management. NIST SP 1339, p. 1. CISA’s Cross-Sector CPG gives a minimum annual reference within its voluntary goals; it is not a legal rule and does not replace site risk analysis. CISA, Cross-Sector CPG, action 2.R.
A separate CISA, FBI, and NSA advisory also recommends periodic backup tests for OT, without setting an annual interval. After an approved change affects an asset, the organization should apply its documented policy and confirm which version represents the controlled state. CISA, FBI, and NSA, guidance for OT/ICS systems.
Does checking a hash prove that a system can be recovered?
No. A hash check confirms that the calculated hash matches the expected hash value, but it does not show that the storage medium is readable, the dependencies are available, or the restored system performs its function.
NIST recommends testing restores on non-production systems. Its OT security guide explains that such exercises may depend on spare equipment or redundant systems, and describes alternative integrity checks when neither is available. NIST SP 1339, p. 2; NIST SP 800-82 Rev. 3, §F.7.6, p. 251.
A functional test should be recorded as evidence separate from a cryptographic integrity check. A separate NIST lab addresses recovery from data corruption in enterprise IT; that example does not establish OT functional recovery. NIST SP 1800-11, summary and scope.
Should you test a restore directly on a production PLC?
This guide does not recommend a write or restore test on a production controller.
NIST recommends testing on non-production systems, while NIST SP 800-82 warns that restoring state can affect an active physical process. NIST SP 1339, p. 2; NIST SP 800-82 Rev. 3, control CP-10, p. 251.
CISA recommends agreeing on acceptance tests and leaving the declaration that a system is operational to the responsible authority. Any work on plant equipment requires local safety and operating procedures, evaluation, and authorization. If there is no safe environment that represents the asset, record the limitation and leave the functional test pending. CISA, Developing an Industrial Control Systems Cybersecurity Incident Response Capability, §4.4.
What is the difference between a backup and a recovery test?
A backup is the retained set of files and records for an OT asset.
A test provides evidence that, in an authorized environment, the system can be recovered and meet defined criteria. Beyond checking files, the exercise should record its scope, available dependencies, result, and unresolved conditions.
CISA recommends acceptance tests so the responsible authority can decide when to declare an ICS operational. Its Cross-Sector CPG also calls for recurring backup tests as a voluntary baseline, separate from site acceptance evidence. That validation cannot be inferred from the existence of a backup or a matching hash. CISA, Developing an Industrial Control Systems Cybersecurity Incident Response Capability, §4.4; NIST SP 800-82 Rev. 3, control CP-10, p. 251; CISA, Cross-Sector CPG, action 2.R.