How Can You Test a PLC Backup Without Connecting to the Live Process?

Restore a controlled copy to a representative, isolated controller or test environment; verify its software, firmware, configuration and relevant retained state against approved references; then exercise the functions that environment can actually represent. Record the remaining differences from production. A successful offline restore supports a bounded recovery claim. It does not authorize reconnection or establish that the physical process is ready to restart.

I'd begin with the question the exercise must answer: could the recovery team reconstruct this particular control function, using the resources that would survive the assumed incident? That is more useful than asking whether a backup file opens. It also gives the operations owner something concrete to review before committing equipment, engineering time or a maintenance window.

This article develops an evidence framework for that decision. It combines authoritative guidance, two manufacturers' documented behavior and original testbed research. The framework, scenario and acceptance cases are my analytical proposals, not a vendor procedure or a report of plant testing. No controller, operational network or physical process was accessed. Equipment-specific restoration and safety validation remain engineering responsibilities.

Define the claim before choosing the test equipment

An offline test can establish several different things: a copy is retrievable, the engineering tools accept it, a representative controller loads it, selected functions behave as expected, or the proposed recovery sequence can be executed by the designated team. These claims require different observations. Treating them as one pass/fail result conceals the difference between a readable archive and a recoverable control function.

NIST's OT backup guide recommends recurring restoration tests on nonproduction systems, alongside functional-integrity checks and integration with change management (Maysey et al., 2026, pp. 1–2). The recommendation establishes that testing belongs in routine backup management. It does not supply a universal acceptance threshold for every plant. I'd make the intended claim explicit before deciding how much of the production environment the test must reproduce.

For example, testing whether the correct engineering software can open a project needs no energized field equipment. Testing whether a replacement controller recognizes the configured modules needs a more representative hardware arrangement. Testing how an actual valve responds requires evidence about that valve and its installation. Increasing the sophistication of the bench does not automatically close every gap between those questions.

The following table is a proposed way to report the result. These are evidence categories, not an industry certification or a compulsory sequence.

Claim being assessed	Evidence an offline test can collect	Inference that remains unjustified
Backup is recoverable as information	Authorized retrieval, decryption and integrity comparison	Its contents are approved for today's plant
Recovery package is compatible	Specified tools, firmware and hardware accept the package	Every other controller revision will behave identically
Selected functions are restored	Defined inputs produce independently specified observations	Untested modes and field interactions are correct
Recovery team can execute the procedure	Documented actions, dependencies, elapsed times and exceptions	An actual incident will take the same time
Production restart is acceptable	Offline evidence informs a separate site decision	A bench pass alone permits reconnection

A rejected claim can still produce a valuable result. Discovering that the available spare cannot accept the archived project is a successful discovery and a failed compatibility test. The report should preserve both facts. Otherwise, the incentive to report a successful exercise can erase the very defect the exercise was funded to find.

Specify a recovery package, including the state it omits

The recovery object should be a defined package for a control function. I would include the project identity, approved change baseline, applicable hardware and firmware, engineering software, required support files, relevant configuration exports, access prerequisites and the associated operating procedure. Every item needs an owner and an explanation of how it contributes to restoration. A large directory of unexplained files is not a specification.

NIST SP 1339 explicitly includes logic, I/O lists, firmware, HMI graphics, licenses, vendor tools, supporting software and compatible spare parts in OT recovery preparation (Maysey et al., 2026, p. 1). That breadth matters because the controller file may be only one recoverable component. The test should expose whether the rest of the package can be assembled without quietly borrowing undocumented resources from production.

Backup methods also differ within a single product family. Siemens' STEP 7 V20 documentation distinguishes snapshots, software uploads, station uploads and device backups, with different contents and operating-mode requirements. Its table identifies retentive data in some methods but not others. The associated footnotes distinguish non-retentive start values from retained actual values and identify write-access restrictions for consistent retained-data capture (Siemens, 2024, tables and footnotes). Those are product-specific conditions, not instructions to interrupt a running plant for this exercise.

My inference is that the label “PLC backup” is insufficient evidence of completeness. Ask which method produced the copy and which information that method could capture. If the package contains an editable engineering project but no usable representation of relevant runtime state, document that limitation rather than assuming the project supplies it. Conversely, a device image that cannot be opened or edited may require a different inspection strategy from a source project.

I would divide state into three decisions: what should be restored unchanged, what should be reconstructed from an approved baseline, and what must be established from the current process condition. A production recipe may belong in the first category; a site-specific network setting may require reconciliation; a previous batch's progress indication may be inappropriate to resume. These are examples for engineering review, not universal assignments. The package should make those choices visible before anyone loads it.

Treat firmware and startup behavior as part of the restore

A recovery test should record what the restore operation can change, not merely the file selected in the tool. Rockwell Automation's Logix 5000 memory-card manual explains that loading a project from a memory card may change controller firmware. Its examples also distinguish loading into Program mode from configurations that return to Run mode (Rockwell Automation, 2022, pp. 12–14). Applicability depends on the documented controller, revision and settings; this is not a claim about every PLC.

That example changes the test design. A team examining only the logic checksum might overlook a change in the execution environment or startup condition. I would therefore require a before-and-after record of the relevant device identity, firmware, project revision and operating mode, with expected changes defined in advance. An unexpected change should stop progression until its meaning has been resolved.

The same discipline applies to engineering tools. If opening an old project prompts a conversion, the converted file becomes a separate test artifact. Preserve the original and record the tool version, conversion action and comparison result. A successful load of a converted project establishes something about that conversion path; it cannot retroactively prove that the original recovery instructions were complete.

“Equivalent spare” also needs a defensible definition. I would ask engineering to identify which differences can affect the function under test: module arrangement, supported features, communication interfaces, timing behavior or available firmware, for example. Record accepted substitutions and their supporting rationale. A procurement description saying two devices belong to the same family is not an engineering equivalence argument.

The deliverable is a compatibility envelope: the set of versions, components and conditions covered by the observations. That envelope can be narrow and still useful. It becomes misleading when a pass on one spare is presented as proof for an entire fleet without reviewing the differences between the tested combination and the installed assets.

Design isolation around possible effects, not a network label

Calling a bench “offline” should describe an established boundary. I'd want a reviewed account of its power, communications, I/O and administrative connections, including any engineering workstation or support service that could bridge it to production. The criterion is whether test activity can affect the operating process through any relevant path. A different subnet alone does not answer that question.

NIST's OT security guide frames protection around performance, reliability and safety constraints, and recommends testing patches in a sandbox where possible before production deployment (Stouffer et al., 2023, abstract and §5.2.5.2). For restoration, I apply the same separation principle: first establish an environment where an unexpected result can be contained. The actual isolation method must be selected by personnel responsible for the equipment and physical hazards.

The test authorization should identify what will be energized, which outputs are represented rather than connected, the permitted operating modes, the observations that trigger a stop, and who can stop the exercise. That does not require publishing sensitive plant details. A controlled engineering record can hold the specifics while an executive report states the approved boundary and its limitations.

A test environment may need services that normally exist elsewhere: authentication, a license server, name resolution, time, or a vendor tool. I would provide approved test equivalents where appropriate and document the substitution. If the team restores successfully only because its laptop retains a cached entitlement or an undisclosed production connection, the test has not demonstrated the claimed independence from that service.

Isolation also has a lifecycle. Inventory the artifacts introduced, preserve the relevant evidence, and control how devices or media leave the test environment. A bench that has processed a suspect recovery candidate should not become an unexamined source of trusted spares. The proposed test plan should state how equipment is re-established to an approved condition before another use; the method is equipment-specific, not a generic instruction to wipe or reset every device.

Check provenance before trusting a technically valid restore

Availability, integrity and suitability answer different questions. Can the team retrieve the copy? Is it the copy the record identifies? Is its content appropriate for the current control function? I'd keep these questions separate because a cleanly retrieved, unchanged file can still contain an unauthorized configuration or an obsolete approved design.

The joint StopRansomware guide recommends offline, encrypted backups and regular tests of availability and integrity in a disaster-recovery scenario (Cybersecurity and Infrastructure Security Agency et al., 2023, p. 5). Protection from deletion is necessary, but protection cannot establish that the content was correct when captured. My implication for immutable storage is limited: preserving a candidate against later alteration does not resolve its original provenance or suitability.

The Australian Signals Directorate's OT principles explicitly question whether backups can be trusted after an adversary has occupied the network and whether the recovered system can be validated as safe (Australian Signals Directorate's Australian Cyber Security Centre [ASD's ACSC], 2024, principle 1). That is a stronger question than whether malware scanning returns no findings. It requires an account of what constitutes the approved engineering state and how that account survived the incident.

I would compare the candidate with independently maintained change approvals, configuration baselines and relevant engineering records. A digest helps establish identity relative to a reference, but a digest stored beside a suspect file is not independent evidence that the file was authorized. If the reference itself is uncertain, record that uncertainty rather than dressing it up as an integrity pass.

The expected behavior must also come from somewhere other than the restored candidate. If a test script simply reads an alarm threshold from the restored project and confirms that the project uses that threshold, it may reproduce the same mistake twice. Use an approved requirement or independently reviewed engineering expectation for the acceptance value. Where no trustworthy expectation survives, the exercise has identified a reconstruction task, not a reason to lower the acceptance standard.

Match test fidelity to the failure you need to detect

A simulator is useful when it represents the properties relevant to the claim. It can be inadequate when the missing property is precisely the one that could cause the failure. I would choose the environment by writing down the suspected failure mechanism and the observation needed to distinguish acceptable from unacceptable behavior.

The DHS control-system patching practice recommends restoring an operational backup on a test bed or simulator to validate a usable restoration point. It also acknowledges that cost and space constrain fidelity and that different applications demand different representation (Tom et al., 2008, p. 19). This older guidance supports the testing principle; it is not current compatibility documentation for an installed controller.

Original testbed research makes the tradeoff more concrete. Mathur and Tippenhauer's (2016) SWaT paper describes a physical water-treatment testbed and contrasts operational experiments with simulation. It also discusses limitations arising from instrumentation and sensor placement (§§IV–V). The paper is not a backup-validation study. Its relevance here is that even a physical testbed has observable and unobservable properties; realism is not a binary attribute.

For a proposed restore exercise, I'd define a small set of functions with an input condition, required observation, tolerance where applicable, and source of the expected result. Candidate functions might include an operator display, alarm transition, sequence hold or communication-loss indication. The engineering owner must decide which are meaningful and safely representable. Completing many easy checks cannot compensate for omitting the one state transition on which the recovery decision depends.

NIST's process-control performance report separates manufacturing-process measures from network, computing, industrial-protocol and OPC data-exchange measures. Its process examples include startup time, throughput and equipment availability (Tang, 2017, §4 and table 1). I would use that distinction to prevent a responsive HMI or healthy network from becoming a substitute for functional evidence. The report's particular metrics and testbed do not establish thresholds for a different plant.

Every accepted result should carry its representation limits. If the test models sensor inputs but excludes actuator mechanics, say so. If it covers normal startup but not a degraded mode, retain that exclusion. The decision maker then sees which uncertainty has been reduced and which uncertainty still requires another form of evidence.

Test the recovery team and its missing dependencies

A technically sound backup can remain unusable if the organization cannot assemble the people, access and tooling needed to restore it. NIST's cybersecurity-event recovery guide treats playbooks as dependent on people, processes and technology; it emphasizes preparation, exercises and improvement. The guide primarily concerns IT, although it discusses potential relevance to OT (Bartock et al., 2016, §§1.2–2). I would adapt its organizational discipline without importing an IT restart sequence into a plant.

The exercise should start at the point the recovery team would actually encounter: an approved request to recover a named function under a stated failure scenario. If the scenario removes the normal engineering workstation, make the team identify the approved alternative rather than lending it the original laptop for convenience. If vendor help is assumed available, distinguish a contractual expectation from assistance actually demonstrated during the exercise.

Dependency failures should be introduced through approved test conditions, not by disrupting operational services. A tabletop branch can establish that a missing license has no documented recovery path. A later bench exercise can validate an alternative once the organization has one. Both observations are useful, provided the report distinguishes a discussion from an executed restoration.

NIST SP 800-53 distinguishes testing backup reliability and integrity, CP-9(1), from using sampled backup information to restore selected functions, CP-9(2) (Joint Task Force, 2020). That distinction supports a more honest coverage measure. I would report which critical functions have restoration evidence for an applicable configuration, rather than the percentage of backup jobs that completed.

Sampling still requires an explanation. Grouping devices by common software, firmware, hardware and recovery mechanism may reduce repeated work, but shared product branding alone is a weak basis. Identify exceptional devices and conditions that need separate testing. An estate-wide percentage without that denominator can give leadership a confident answer to the wrong question.

Measure the demonstrated interval without calling it the whole RTO

Recovery time objective and recovery point objective describe different constraints. NIST's contingency-planning guide defines RTO in terms of the tolerable unavailability of a system resource, while RPO concerns the point to which data can be recovered and the associated tolerance for data loss (Swanson et al., 2010, §3.2.1). Neither is a guarantee delivered by a backup product.

For OT, I would add a state-compatibility question alongside backup age. Can the candidate be reconciled with the physical equipment and operating condition that will exist at recovery? A very recent copy can be inappropriate if it captures an incomplete change. An older approved copy may be incompatible with equipment replaced since it was taken. Selecting a timestamp is therefore only part of selecting a recovery point.

Consider an explicitly hypothetical exercise with four sequential intervals: 18 minutes to obtain authorized media and access, 25 to establish the engineering environment, 40 to restore and inspect the specified controller, and 32 to complete the selected functional checks. The demonstrated bench interval would be 115 minutes. Against an invented 90-minute bench objective, it would miss by 25 minutes. These figures are illustrative, not measurements or industry benchmarks.

That calculation excludes fault diagnosis, equipment delivery, field verification, process stabilization and authorization to return to service. It cannot establish a 115-minute production RTO. Nor should the team add every task duration blindly if some work runs concurrently. Document start and end events, the actual dependency sequence, waiting time and exclusions so another reviewer can understand what the number represents.

For the wider sequence, the next question is which dependencies must recover first. Here, the useful output is narrower: the measured or proposed controller-restoration interval, the resources assumed available, the outstanding production steps and the conditions under which the timing evidence would cease to apply.

Use a worked decision to expose an attractive false pass

Imagine a fictional packaging line with two recovery candidates. Candidate A predates a documented sensor replacement. Candidate B was captured after that replacement, but its corresponding engineering-change approval cannot be located. Both files are readable. Both load onto the representative spare. Neither fact resolves which candidate is appropriate for production.

For A, the question is whether an approved reconciliation can account for the changed sensor and associated configuration. For B, the question is whether the unexplained difference can be traced to an authorized change and validated against the engineering requirement. A successful load is compatible with both a valid configuration and a wrong one. It cannot discriminate between them.

I would keep both candidates preserved and mark production suitability unresolved. Engineering can investigate the change history and establish the required state; the bench can then test the resulting approved candidate. Selecting B merely because it is newer would exchange an explicit uncertainty for an unsupported assumption. Selecting A merely because it once ran would ignore the subsequent physical change.

The following proposed cases would make the test's reasoning visible. They are expected observations, not executed results.

Proposed case	Evidence sought	Decision consequence
Normal controlled restore	Package identity, compatible environment and agreed functional observations	Accept only the tested scope
Missing support artifact	Procedure identifies the missing requirement and records its effect	Package completeness remains failed
Unexpected firmware or mode	Actual state compared with the approved expectation	Hold progression pending engineering review
Unexplained configuration difference	Independent change evidence and requirement comparison	Suitability remains unresolved
Normal identity service unavailable	Approved alternative access demonstrated or explicitly untested	Record the true access dependency
Represented input outside the selected normal range	Expected indication or transition observed within the approved test boundary	Accept that case, not all abnormal operation
Failed acceptance check	Team stops, preserves evidence and follows the approved disposition	No progression to production authorization

In this scenario, the main finding is not that backups failed technically. It is that technical loadability was being used to answer an engineering-authorization question. The remedy is better evidence about the intended state, followed by a relevant test. Repeating the same successful load ten times would not supply that missing evidence.

Keep the production decision separate, and make the test worth funding

An offline test is most valuable when it reduces uncertainty before a constrained production decision. I'd deliver a compact acceptance record naming the recovered function, candidate identity, tested environment, independent expectations, actual observations, exceptions and unresolved field conditions. Engineering, operations and the appropriate safety authority can then assess the production steps using their established procedures.

A common objection is that a representative bench costs too much. That can be true, particularly for obsolete or unusual equipment. The practical response is to prioritize the uncertainties that could defeat recovery: an unreadable archive, unavailable tooling, incompatible spare, unexplained state or untested critical transition. Start with evidence obtainable without production exposure, then justify more expensive representation against the remaining decision. Limited fidelity should narrow the claim, not make testing pointless.

Another objection is that the last real restoration already proved the procedure. It may provide strong evidence for the conditions that existed then. I would examine what changed afterward: equipment, firmware, access, tooling, process requirements or the people expected to execute the plan. Evidence should be reused where it remains applicable. It should not be treated as timeless merely because the earlier outcome was successful.

This framework has limits. It synthesizes guidance and selected technical documentation; it has not been experimentally validated across industrial sectors. The vendor examples are version-specific, and the cited research does not estimate how often offline tests predict successful production recovery. It does not replace functional-safety validation, equipment manuals or plant procedures. The general recovery-acceptance argument addresses the wider service decision; this paper concerns the bounded contribution of offline controller testing.

If you cannot show what your most important PLC backup contains, which replacement environment accepts it, and what remains unresolved before reconnection, request an OT recovery-readiness briefing. I'd focus the assessment on one critical control function, its recovery package and the evidence needed for the next engineering decision. The useful outcome is a defensible test scope and a prioritized list of recovery gaps—not another green backup dashboard.