Backup and Recovery in OT: PLC Golden Images and Industrial Disaster Recovery

The question that matters: how long until you restart?

Most OT security investment aims to prevent and detect attacks. That is right, but incomplete. Sooner or later something goes wrong: ransomware that crosses the IT-OT boundary, a controller that fails, a maintenance job gone bad, corrupted firmware. At that moment one metric matters above all: how long it takes to get back to producing.

In IT the answer is almost trivial: you restore a backup. In OT the same question opens a different and harder problem, because it is not about recovering files, it is about rebuilding the operation of a physical plant.

Why OT is different

An OT backup that is genuinely useful must capture far more than data.

Configurations and control logic. The value of a PLC is not in a document file, it is in the program it runs: ladder logic, process parameters, thresholds, recipes. Losing this means having to reprogram, often without up-to-date documentation.

Firmware and versions. A configuration must be applied on the correct firmware version. A backup disconnected from its firmware version can be unusable or, worse, dangerous if applied on the wrong firmware.

Heterogeneity. A plant has PLCs from different vendors, HMIs, SCADA servers, historians, managed switches. Each with its own format, its own export tools, its own dependencies. There is no single backup button.

Physical dependencies. Restoring a controller is not enough if the state of the process it managed is also lost. The plan must account for the restart order and the interdependencies between systems.

The golden image as a known-good state

The central concept is the golden image: a certified, versioned and safeguarded copy of the complete state of every critical device. Program, parameters, firmware, network configuration. It is the known-good state to return to.

The golden image serves three scenarios: hardware failure (you replace the device and load the image onto it), tampering (a comparison against the golden image reveals what changed), and post-incident recovery (you bring the plant back to a trustworthy state).

For it to work, three disciplines are required:

• Versioning: every golden image is tied to a precise version, with a history of changes.
• Change alignment: the image is updated after every authorized change, hooked to the change management process, not on an arbitrary schedule.
• Periodic verification: a backup that is never tested is a hope, not a plan.

Safekeeping: offline and isolated

There is a lesson ransomware has taught the hard way: backups reachable from the network get encrypted along with everything else. A capable attacker seeks out and destroys backups before striking, precisely to remove the escape route.

For this reason, critical OT backups must be kept offline or on media isolated from the operational network, with off-site copies. Recovery must be able to proceed even assuming the entire IT infrastructure and management systems are unavailable or compromised. If restoring a PLC requires a system that might be infected, the plan has a flaw.

Defining recovery objectives

An OT disaster recovery plan is measured against two parameters, to be defined for each system according to its criticality:

• RTO (Recovery Time Objective): how much time is acceptable to get back to operations. For a critical line it may be hours, for an ancillary system days.
• RPO (Recovery Point Objective): how much loss of recent configuration is tolerable. In OT, where configurations change seldom, the RPO ties directly to the discipline of post-change backups.

These objectives are not abstract numbers: they guide where to invest. Systems with the tightest RTO deserve ready golden images, spare hardware and proven procedures; the others can tolerate a slower path.

From backup to resilience

OT backup is not an IT activity to be extended to the plant, it is an industrial discipline in its own right. Capture the logic and not just the data, tie it to the firmware, keep it offline, test it, size it against the recovery objectives. Done well, it turns an incident from a catastrophe into a manageable interruption. It is the difference between stopping for a day and stopping for a month.

The MON5 angle

MON5 does not provide backup, recovery or disaster recovery: those require the dedicated tools described above. MON5 does not replace backup tools, it provides the up-to-date map the plan rests on.

A golden image strategy presupposes an answer that many plants do not have: the complete list of devices to protect, with model and firmware version. The continuous inventory of MON5's ANALYZE phase keeps this map up to date, including the firmware versions detected from traffic, so the backup plan covers what is genuinely in production and not what is on paper.

MON5 also enables the plan after it has been defined: an unauthorized change to a PLC configuration, detected by passive traffic monitoring, is the signal that the golden image may no longer reflect the real state and must be updated with the backup tools. To build the accurate inventory on which to base the recovery plan, start with an OT assessment.

Analysis and commentary by MON5 based on public-domain research and data from the OT/ICS sector.