CYBER RESILIENCE AND BACKUP STANDARD

Recovery Tiers · Backup Protection · Restoration Testing · Regulated Overlays · BCP Interface

Table of Contents

1. Purpose and Scope
2. Boundary: Cyber Resilience vs. Enterprise BCP
3. Recovery Tiers and RTO/RPO Model
4. Backup Protection and Immutability
5. Restoration Testing
6. Cloud and SaaS Recovery
7. OT Recovery and CIP-009
8. CUI Recovery
9. SOX Availability Evidence
10. Roles and BCP Interface
11. Recovery Plan Template
12. Document Control

1. Purpose and Scope

The policy, IT standard, OT standard, CUI standard, compliance matrix, and RMF all require documented and tested recovery plans, backup protection, and restoration evidence. Until this standard, those obligations had no shared executable definition, RTO/RPO tiers, immutability requirements, restoration evidence formats, and the boundary with enterprise BCP were left for each subordinate document to imply.

This standard closes that gap. It applies to every in-scope asset that has data, configuration, or workload state worth recovering.

Cyber Resilience Is Not BCP

Business continuity owns the business recovery: order processing keeps moving, customers are notified, alternate sites stand up. CERG owns the cyber recovery: the systems and data are restored from clean, immutable backups onto known-good baselines, with identity and detection re-enabled. The two programs coordinate; they do not substitute for each other.

2. Boundary: Cyber Resilience vs. Enterprise BCP

CERG produces inputs to Enterprise BCP: tested cyber recovery plans, RTO/RPO actuals, and clean-restore preconditions. Enterprise BCP produces inputs to CERG: business criticality tiering, alternate-site cyber dependencies, and recovery priority calls during an event.

3. Recovery Tiers and RTO/RPO Model

Every in-scope asset has a CERG recovery tier. The tier drives RTO/RPO targets, backup frequency, immutability requirements, and restoration test cadence. Tiering is owned by Engineering in partnership with the business and Enterprise BCP, the business sets criticality, CERG sets the cyber tier consistent with criticality.

The RTO Number Is Honest or It Is Useless

A T1 RTO of 4 hours that has never been demonstrated by a real restoration is a number on a slide. CERG only certifies an asset to a tier after a restoration test demonstrates the RTO/RPO. Until then the asset is classified Tier “Aspirational” and tracked in the resilience register as a Planned control.

4. Backup Protection and Immutability

Every backup of an in-scope asset meets the following requirements at minimum. Tier-specific tightening is named where it applies.

4.1 The Backup Protection Checklist

4.2 The Air-Gap and Immutability Rationale

Ransomware tooling routinely attacks backup systems before triggering encryption. The immutability and credential separation requirements above exist specifically because production-attached, production-credentialled backups are not a defense.

If the Backup Lives on Production, It’s Not a Backup

A snapshot taken on the same storage system as production, accessible by the same credentials, is a convenience feature. It is not a cyber backup. The cyber backup lives somewhere a compromised production-domain identity cannot reach.

5. Restoration Testing

A backup that has never been restored is a hope, not a control. Restoration tests produce evidence per CERG-GOV-CB-001 control-to-evidence mapping.

5.1 Cadence

5.2 Restoration Test Procedure

Each full restoration test follows the procedure below and produces the evidence artifact in Section 5.3.

1. Pre-test brief, scope, success criteria, RTO/RPO targets, dependencies, business / OT owner notified.
2. Isolate the recovery environment from production where applicable (no risk of overwriting production).
3. Restore from immutable copy onto a clean baseline (DISH profile per CERG-STD-CFG-001).
4. Bring up identity, logging, detection, and monitoring before declaring the system available.
5. Validate data integrity against last known-good (hash, checksum, sample query).
6. Measure RTO actual and RPO actual against targets. Document deltas.
7. Tear down or promote per scope.
8. Lessons learned captured into the resilience register and, where applicable, the risk register.

5.3 Restoration Test Evidence

6. Cloud and SaaS Recovery

Cloud and SaaS recovery is shaped by the shared-responsibility model. CERG does not assume provider recovery covers customer-side obligations.

6.1 Cloud-Native Workloads (IaaS / PaaS)

• IaC reconstruction: production environments rebuildable from version-controlled IaC plus data backups.
• Account / subscription / project failure modes: tested at the in-scope cadence, including region failure, account compromise, and IAM root account loss.
• Provider-side recovery contacts and escalation paths: documented in the Recovery Plan; verified annually.
• Cross-region or cross-cloud failover: where required by Tier, tested and evidenced.

6.2 Tier 1 SaaS

Provider native restore is the first line; CERG-managed SaaS backup is added where provider native restore is insufficient or where regulator requires customer-controlled backup.

7. OT Recovery and CIP-009

OT recovery is uniquely prescriptive. CERG implements CIP-009 fully and extends it where multiple operating segments demand more.

7.1 OT Artifacts That Must Be Backed Up

CIP-009 R1 specifies recovery plans; CERG requires that the following OT artifacts are explicitly in backup scope:

• Configuration files (SCADA, HMI, historian, jump server, network device, firewall)
• Firmware images and versions in service (RTU, relay, OT switch, controller)
• Software installers for the in-service OS, application, and engineering tool versions
• Logic files (PLC ladder logic, RTU configuration, relay setting groups)
• Historian data sets at the retention required for operational and regulatory needs
• Relay setting groups with version, date, and operator metadata
• Engineering tool images and licensing artifacts
• Jump server images / known-good baselines
• Documentation: as-built diagrams, ESP/EAP topology, vendor compatibility matrices

7.2 CIP-009 R1 / R2 / R3 Implementation

• R1, Recovery Plan Specifications: documented per asset class; reviewed annually; includes roles, processes for backup management, and methods to preserve data essential for restoration.
• R2, Recovery Plan Implementation and Testing: tested at least once every 15 months; one full operational exercise every 36 months (per CIP-009 R2.2).
• R3, Lessons Learned and Plan Updates: documented within 90 days of any plan implementation or test.

7.3 OT Restoration Cautions

OT Recovery Has Safety Implications

Restoring a misconfigured relay setting group from backup can shed load or trip a substation. OT restoration is supervised by an operator with substation-engineering authority, never by Cyber alone. The Recovery Plan names the operator role explicitly.

8. CUI Recovery

CUI recovery aligns with NIST 800-171r3 3.8 (Media Protection, backups) and 3.6 (Incident Response, recovery from incident affecting CUI).

• Backup encryption uses FIPS-validated cryptography per CERG-STD-CR-001.
• Backup storage stays within the CUI enclave or its provider-equivalent boundary; no cross-spillage to non-CUI environments.
• Restoration test validates that CUI labeling, access control, and logging are intact after recovery.
• Post-incident updates to SSP and POA&M per CERG-PLN-CUI-001.
• Incident-driven recovery: if a CUI system is recovered following an incident, the recovery itself is documented as POA&M follow-up.

9. SOX Availability Evidence

SOX-relevant systems (per CERG-PLN-SOX-001 SOX-Relevant System Register) require evidence of backup, restoration, and availability controls reusable in the SOX cycle.

SOX evidence reuses these artifacts; no duplicate “SOX-only” restoration test is performed.

10. Roles and BCP Interface

11. Recovery Plan Template

Every in-scope asset (or asset cluster) has a Recovery Plan in the format below.

RECOVERY PLAN - <System / Cluster Name>           PLAN-RES-YYYY-NNNN

1. ASSET CONTEXT
   System ID(s)              :
   Tier                      :  (T1–T5)
   Business Owner            :
   Engineering Owner         :
   OT Operator (if OT)       :
   Regulatory Scope          :  CUI / BES / SOX / None
   Dependencies              :  (named upstream/downstream systems)

2. TARGETS
   RTO (cyber)               :
   RPO                       :
   Last Demonstrated RTO     :
   Last Demonstrated RPO     :
   Test Cadence              :

3. BACKUP CONFIGURATION
   Backup System(s)          :
   Frequency                 :
   Immutability Mechanism    :
   Retention                 :
   Backup Credentials/Owner  :  (separately credentialled)
   Encryption / Key Source   :  (CMK ref per [CERG-STD-CR-001](CERG-STD-CR-001_Cryptography_and_Key_Management_Standard.md))

4. RESTORATION PROCEDURE
   Pre-test brief            :  (process / template)
   Restore steps             :  (ordered; reference runbooks)
   Identity / logging / detection re-enable steps
   Validation steps          :
   Tear-down / promotion     :

5. CIP-009 NOTES (if BES)
   R1 / R2 / R3 references   :
   Operator role with restore authority :

6. CUI NOTES (if CUI)
   FIPS crypto evidence      :
   POA&M update path         :

7. SOX NOTES (if SOX in-scope)
   Evidence reuse mapping    :  (per Section 9)

8. INTERFACE TO ENTERPRISE BCP
   BCP Plan reference        :
   Hand-off triggers         :

9. CHANGE LOG

A populated example is maintained in the resilience program library; the template is reused without modification.

12. Document Control

Source: standards/CERG-STD-RES-001_Cyber_Resilience_and_Backup_Standard.md · Download .md · View on GitHub