A robot backup is not a recovery plan

Trace the copy used in the exercise — method added 9 October 2026

An exercise result is hard to use if nobody can identify the backup copy that produced it. Keep the approved backup reference separate from the copy actually retrieved and tested. The archive's name alone may not establish its creation time, source configuration, content scope or relationship to the approved record. A later successful exercise should not silently overwrite an earlier failed result or the evidence for a different copy.

Start with the controlled backup record: source asset, creation time, backup type and scope, plus its approval or custody reference. Then record the exercise's retrieved copy and the evidence linking it to that record. Use references to the buyer's controlled records rather than putting backup files, credentials or sensitive storage locations into a public worksheet. If the link is missing or a comparison reports a mismatch, retain that exception for the responsible owner.

NIST SP 1339, final 17 June 2026, places backup testing and review within OT recovery exercises. It supports checking the recovery evidence, but its public abstract does not prescribe this six-field record. Universal Robots' PolyScope 5.22 instructions describe selecting a backup file for restoration and warn that a new SD-card image with a mismatched serial number can leave restoration incomplete. That product-specific constraint is a reason to record the actual target and applicable review, not a rule for every robot or permission to restore onto an arbitrary controller.

For a hypothetical replacement-controller exercise, the team might retrieve an older archive with a similar name to the approved copy. Record what was used, which comparison or integrity-check evidence was available, and any unresolved difference. Even if the controller starts, the result belongs to that retrieved copy, target and test boundary. It does not establish that the approved newer copy was exercised, that omitted dependencies were recovered or that production can resume.

Finish the trace with the dated exercise result, witness, exclusions and reviewer disposition. A complete record can say that the copy was rejected, that integrity remained unverified or that release was withheld. Keep those conclusions separate from milestone completion and from the change-impact review. The qualified owners decide which checks and methods apply; this article does not supply a restore procedure or select a verification algorithm.

The local recovery record now adds an exportable backup-copy trace with six independently checked fields. Blank references remain visible even when other milestones are filled. It is a record-completeness aid: it uploads no backup, reads no file, compares no checksum, tests no compatibility and approves no restart. Retain the controlled evidence in the buyer's own system and obtain the required operational, engineering, cyber and safety decisions before relying on a recovery result.

Review evidence after a configuration change — method added 4 October 2026

A recovery exercise belongs to the source, target and dependencies it tested. When one of those changes, preserve the earlier result with its original configuration reference. Do not erase a failed exercise, relabel an older result as a new test or assume that a successful restore transfers to a replacement controller. The next decision is which conclusions remain applicable and which need another review or exercise.

NIST SP 1339 links OT backups to change management, testing and recovery-exercise review. Universal Robots' PolyScope 5.22 instructions illustrate a specific compatibility boundary: when restoring with a new SD card, the serial number in the image must match, or restoration may be incomplete. Neither source establishes a universal list of robot changes that automatically invalidate every recovery result. The responsible specialists need to apply the actual product documentation and the site's change process.

Begin a change-impact record with the previous tested configuration and the changed configuration or approved change reference. Identify the affected evidence and dependent systems. Keep the reasoning traceable: which file, interface, calibration, licence or operating condition changed; which prior check depended on it; and what evidence supports retaining or reopening that check? A statement that nothing is affected needs a reviewed reason, not a blank field.

For a hypothetical vision-software update, a controller backup could remain readable while the previously tested camera interface or calibration no longer describes the installed system. Record the old restore result without promoting it into evidence for the new vision configuration. The review may require interface and process checks, a new recovery exercise or a restricted operating boundary. Those choices belong to the qualified owners; the worksheet cannot decide them from a version number alone.

Scope the next action precisely. Name the evidence to collect, the applicable configuration, the review owner and any restriction that remains while evidence is missing. A retest reference should identify what was actually exercised, including exceptions and dependencies left outside it. Closing one issue does not close an unrelated safety, cyber or production question. Keep release authority separate from the person who merely recorded a successful restore.

The local recovery record now exports a separate change-impact section alongside the existing milestone observations. It helps carry the old and new configuration references into a handover without transmitting entered answers. Its fields are a coordination aid, not automatic compatibility validation, a complete change-management system or permission to restart. Preserve the approved records in the buyer's own controlled system and obtain the required operational, engineering and safety decisions before relying on the changed service.

Keep a restore result separate from a release decision — method added 1 October 2026

A useful exercise record follows the service through distinct decisions. Record when the restore request was authorised, when target compatibility was reviewed, when controller restoration was observed, when dependent systems were checked and when the production owner decided whether to release. Give each milestone its own observed time, evidence reference, responsible owner and disposition. This is RobotAtom's coordination method, not a prescribed manufacturer sequence.

Do not start the clock at whichever event makes the result look quickest. Agree the start and endpoint before the exercise. Controller availability, restricted operation and accepted production output are different endpoints; label the measured one. Keep time spent finding a replacement, recovering a licence, resolving a warning or obtaining a review visible. This record does not calculate a recovery-time guarantee from incomplete entries.

Check the actual target against the approved source before relying on a restore. The PolyScope 5.22 instructions provide a concrete example: a new SD-card image must carry the matching serial number, or restoration may be incomplete. That is a product-specific constraint, not permission to copy an image onto any robot. Record the exact target, applicable documentation and unresolved mismatch rather than assuming that a readable archive establishes compatibility.

For a hypothetical controller replacement, the software could boot while a vision calibration or upstream handshake remains unverified. The controller milestone can be recorded as complete; the dependency milestone remains blocked. The release owner can withhold production or define a restricted boundary supported by the required qualified reviews. Do not silently convert either decision into an unrestricted restart because the screen looks normal.

NIST's June 2026 OT backup guidance calls for testing and review during recovery exercises. A retained record should therefore show what was exercised, what was excluded and what changed after the review. Neither an exported worksheet nor a signed milestone alone establishes machinery safety, cybersecurity assurance or production acceptance. Use the local recovery milestone record to preserve the evidence and next action; obtain the actual release decision from the responsible operations, engineering and safety owners.

A completed archive answers only one question

A robot controller can report that a backup completed without proving that the production application can be recovered. The archive may omit external systems, depend on a particular controller identity or software version, require unavailable licences or credentials, or restore successfully while leaving calibration, interfaces, safety functions or process output unverified.

Define recovery as an operational outcome: an agreed service is restored to an approved state within stated data-loss and elapsed-time limits. Backup creation is one input to that outcome, not evidence of the whole result.

Define the service and its recovery objectives

NIST SP 1339, published in June 2026, treats operational-technology backup as part of recovery and change management. Its public abstract calls for regular backup, testing and review during recovery exercises. That is general authoritative guidance, not verification of a robot product or a prescription for one universal recovery target.

• Name the required endpoint: controller available, restricted cell operation, validated production output or another explicit state.
• Set the maximum acceptable loss of programs, configuration, recipes, logs or other data, including the event from which that loss is measured.
• Define elapsed-time milestones and their start and finish events rather than using one ambiguous recovery-time number.
• Prioritize cells and dependencies by operational, safety and business consequence, and name who authorizes each recovery and release step.
• Cover relevant causes such as media failure, accidental deletion, a failed update, replacement hardware and cyber compromise; they may require different procedures.

Draw the whole-cell recovery boundary

NIST SP 800-82 Revision 3 recommends a backup inventory that includes items such as installation media, licence keys and configuration information, with integrity checks, secondary storage and restoration testing. This is cross-OT guidance, not a robot recovery specification or proof that a controller archive covers a complete cell.

• Robot software, options, programs, system and safety configuration, calibration, mastering, payload, centre-of-gravity and tool-centre-point data.
• PLC and safety-PLC code, HMI, drives, vision models and calibration, end-effector controllers, process recipes and quality parameters.
• Fleet or orchestration services, maps, databases, interface configuration and upstream or downstream system dependencies.
• Installers, exact versions, licences, certificates, keys and secrets, with their protected custody and recovery access.
• Replacement hardware, network settings, drawings, mechanical references, procedures, supplier contacts and responsible owners.

Know what each vendor backup actually contains

ABB's 2026 RobotStudio Revision BB operating manual says a system backup contains installed software and option information, the system home directory, programs, configuration and calibration data. It also documents a product-specific exclusion for PIB-board contents on an IRC5P paint-controller system. ABB's restore interfaces expose selectable content, settings, permissions and system or template mismatches. These are first-party behaviours for documented ABB products, not independent proof that a complete cell can be recovered.

Universal Robots documents a full PolyScope 5 system copy for restoration after disk corruption or accidental deletion and warns that restoration to a new SD-card image can be incomplete when the robot serial number does not match. UR also documents separate Magic Files for program and installation files, configuration and logs. These are manufacturer instructions for named versions; they do not establish coverage of external cell assets or universal cross-version compatibility.

Protect a known-good, compatible recovery set

CISA's current StopRansomware guidance recommends offline encrypted backups, regular testing in a disaster-recovery scenario, maintained golden images and separately stored software and licence material. This is general cybersecurity guidance, not a robot restore manual or evidence that any restored machinery is safe to run.

• Identify the source asset, serial or system identifiers, software version, backup type, creation time, owner and known exclusions.
• Keep approved copies beyond the same device, account, network or site event, using appropriate offline, immutable and encrypted arrangements.
• Preserve the last known-good state; verify readability, integrity, retention and custody instead of relying on a copy job's success message.
• Predefine compatible replacement controllers, hardware, software and options, plus installation media and licence recovery.
• For cyber recovery, define how a clean target is established and how restored assets are prevented from reinfecting it.

Exercise the complete restore path

An exercise produces useful evidence only when the frozen source, target, method, conditions and observed results are preserved. A controller restart alone does not establish the recoverability of the integrated production service.

• Document authority, credentials, safe shutdown and energy control, isolation, restore order, supplier escalation and communications.
• Use a representative replacement target or justified test environment and record every identity, version or compatibility warning.
• Restore dependent systems in a controlled order and prohibit undocumented bypasses or silently ignored mismatches.
• Measure the agreed milestones and retain failures, unavailable dependencies, manual actions, interventions and deviations.
• Repeat after material controller, software, safety, PLC, vision, tool, licence, network or architecture changes and after a real recovery.

Validate before production resumes

RobotAtom can record recovery requirements, source and version boundaries, archive scope, exclusions, procedure, exercise evidence and open actions. It does not certify a backup, cybersecurity control, safety function, production recovery or regulatory compliance. The responsible buyer, integrator, operations owner and qualified specialists must decide what applies and whether the evidence is sufficient.

• Reconcile software, licences, users, ordinary and safety configurations, calibration, mastering, tools, payload data, programs and interfaces with the approved baseline.
• Run the safety, motion, process, quality, communications and recovery checks required for the affected configuration.
• Preserve restore logs, versions, results, deviations, witnesses, approvals and any operating restrictions.
• Require the named production and safety owners to approve return to service; do not treat successful boot as production acceptance.