SOP: Control System Configuration Backup and Recovery (PLC, SCADA, DCS)

This is a ready-to-use SOP. It sits underneath the corporate backup and restore policy and applies that policy’s intent to the specific artifact that makes automation different: the thing being protected is an executable validated state, not a document. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, and route it through your normal document control, review, and approval. A worked filled specimen follows the template. Verify each cited regulation against the current source before you rely on it.

Document control header

1. Purpose

This procedure defines how <<FILL: COMPANY NAME>> backs up and restores validated PLC, SCADA, and DCS configurations, so a hardware failure or a corrupted file is recovered to a known, approved state, not a guess.

2. Scope

This procedure applies to all GMP-impacted PLCs, SCADA systems, and DCS platforms, their engineering project files, configuration databases, recipes, and the process historian. It covers routine scheduled backup, the backup taken immediately after every approved change, and the restore procedure used when a backup is recovered to replacement hardware or to correct a corruption. It does not cover general IT server backup, which is governed by <<FILL: SOP-ID for IT backup and restore>>, except where a control system’s backup also depends on that underlying infrastructure.

3. Responsibilities

4. Definitions

• Approved baseline: the version of a PLC program, SCADA project, or DCS configuration that was validated and released for production use, recorded with its version identifier or checksum at the last change control closure.
• Checksum / version comparison: a technical comparison (hash value, version number, or equivalent) used to confirm a restored configuration is identical to the approved baseline, rather than relying on the backup job’s “success” status alone.
• Restore test: a controlled exercise, not tied to an actual failure, that proves a backup can be recovered and functions correctly before it is needed in an emergency.
• Configuration drift: any difference between the live, running configuration and the approved baseline that was not put through change control.

5. Procedure

5.1 What to back up, by layer

5.2 When to back up

1. On the defined schedule for the system, set from its criticality per <<FILL: reference, e.g. the periodic review schedule>>, at minimum <<FILL: frequency>>.
2. Immediately after every approved change is implemented and confirmed working, before the change record is closed. This is the backup that becomes the new approved baseline.
3. Before any firmware update, major configuration change, or hardware replacement, as a rollback point distinct from the post-change backup.

5.3 Taking the backup

1. Use the validated backup method for the platform (vendor backup utility, project export, or configuration upload) specified in <<FILL: system-specific work instruction or vendor reference>>.
2. Label the backup with the system ID, date and time, the change control or event that triggered it, and the version identifier.
3. Store the backup in the designated repository per <<FILL: reference, e.g. the IT backup and restore SOP>>, with access restricted to authorized personnel.
4. Record the backup event, including the version identifier or checksum captured at the time, in the backup log (section 8).
5. Where the backup follows an approved change, update the approved baseline record so the new backup is recognized as the current reference point.

5.4 Restoring a backup

1. Confirm the reason for the restore (hardware failure, corruption, or a planned restore test) and, for an unplanned restore, open the applicable record per <<FILL: SOP-ID for deviations, if the restore follows an unplanned event>>.
2. Select the backup to restore: the most recent approved baseline, unless the investigation specifically calls for an earlier version.
3. Restore the backup to the target hardware or environment using the validated restore method for the platform.
4. Perform the checksum or version comparison of the restored configuration against the approved baseline recorded in the change control system. A mismatch is investigated before the system returns to production; it is not restored “close enough.”
5. For a PLC restored to replacement hardware, re-run a representative sample of the I/O loop checks from the original OQ (see the automation OQ protocol) to confirm the physical I/O maps correctly on the new hardware.
6. For a SCADA or DCS restore, confirm a sample of displays, alarm setpoints, and recipe content match the approved configuration.
7. Document the restore (section 8) and obtain the required approval before the system returns to routine production use.

5.5 Restore testing (proactive, not failure-driven)

1. Each GMP-impacted system has a documented restore test at the frequency set in <<FILL: reference, e.g. annually and after any major platform change>>, performed to a non-production target where feasible.
2. A restore test follows the same verification steps as section 5.4 and is documented as a restore test, not disguised as a live event.
3. A failed restore test is raised and investigated per <<FILL: SOP-ID for deviations>>, and the backup method is corrected and re-tested before being relied on again.

6. Acceptance criteria

A backup and restore cycle is acceptable when all of the following are true:

• The backup captured the full scope defined in section 5.1 for the system, not a partial subset.
• The backup is labeled, logged, and stored per section 5.3.
• Every restore includes a checksum or version comparison against the approved baseline, with any mismatch investigated and resolved before production use resumes.
• A representative function check (I/O loop sample for a PLC, display and recipe sample for SCADA/DCS) confirms the restored system actually works on the target hardware, not only that the file transferred.
• Restore testing occurs at the defined frequency independent of whether a real failure has occurred.

7. References

21 CFR 211.68, Automatic, mechanical, and electronic equipment (backup data exact, complete, and secure from alteration, erasure, or loss). EU GMP Annex 11, Computerised systems, section 7.2 (data backup) and Annex 11 general principles. MHRA “GXP” Data Integrity Guidance and Definitions, Revision 1 (March 2018), backup and archive expectations. ISPE GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems, Second Edition (2022).

Confirm the current version and clause numbers of each reference before issue.

8. Record generated: backup and restore log

9. Revision history

10. Approvals

Filled specimen

A PLC processor failure on a filling line, illustrative detail only.

In this example, the replacement processor was loaded from the backup taken after the most recent approved change. Before the line restarted, the checksum comparison confirmed the restored program matched the approved baseline recorded at the prior change control closure, not an earlier or an untracked interim version that might have been sitting in the backup folder under a similar file name. A sample of the fill-weight I/O loop checks was then repeated on the physical replacement hardware itself, because a checksum match on the program proves the logic is right but says nothing about whether the new processor’s terminals are wired and scaled the same way the old one was. Only after both checks passed did the line go back into production, and only then was the deviation closed. That sequence, not the fact that the backup file transferred without an error message, is what an inspector is actually asking about when they ask how you know the replacement works.

Common inspection findings this SOP prevents

• A backup exists and restores without error, but nobody compared the restored version against the approved baseline, so an earlier, unapproved configuration could run undetected.
• Backup scope captures the PLC program but not the engineering project file, the recipe set, or the historian configuration, so a full recovery is not actually possible.
• Backups are taken on a fixed schedule disconnected from the change control calendar, so the most recent approved change is not captured.
• No restore has ever been tested outside of an actual failure, so recoverability is assumed rather than proven.
• A restore following a hardware replacement skips the function check, confirming the file but not the physical I/O mapping on the new hardware.

How to adapt this SOP

1. Set your document number, owner, and effective date in the header.
2. Point section 5.2’s frequency and section 5.5’s restore-test interval to your actual periodic review schedule.
3. Name your real backup repository and retention reference in section 5.3.
4. Confirm the approved-baseline record referenced throughout is the same one your change control system maintains, not a separate, unreconciled list.
5. Confirm every regulation in section 7 against the current published version before issue.