[IACS UR E26] Recovery – 16 Backup & Restore Capability

IACS UR E26 - Backup & Restore Capability

 

# Can Your Ship Recover from a Ransomware Attack at Sea? ⚓

 

Most maritime professionals think "backup" means copying files. UR E26 §4.5.2 sets a fundamentally higher bar — your ship must be restorable to a **safe navigational and operational state**, not just a recoverable data state.

 

**What UR E26 §4.5.2 Actually Requires**

Shipowners and system integrators must implement backup and restore capabilities for all Cyber-Based Systems (CBS) that enable full operational recovery after a cyber incident. Backup plans must explicitly define five parameters: scope, mode, frequency, storage medium, and retention period. Critically, restoration must be performed from a **verified secure copy or image** — never from a potentially compromised system. Annual survey evidence must demonstrate backups are being taken per policy and that restore procedures are documented and available.

 

**Why This Matters Uniquely for Ships**

A vessel mid-voyage cannot call IT support. If ECDIS, propulsion control, or cargo management systems are encrypted by ransomware, the crew must execute recovery independently — often under operational pressure, in degraded conditions, with limited connectivity. This is precisely why E26 explicitly names ransomware as a relevant threat and recommends **offline backups**: a connected backup system can be encrypted alongside the primary system, rendering recovery impossible. The requirement to restore to **navigational state** — not merely to a working OS — reflects a maritime safety imperative that goes beyond standard IT recovery objectives.

 

**IEC 62443 Technical Depth**

E26 §4.5.2 aligns with IEC 62443-3-3 **SR 7.3 (System Backup)**, which requires backup capability without impacting normal operations. At SL-2, secure backup procedures are expected; at SL-3, backup integrity verification becomes mandatory. E26's offline backup recommendation directly exceeds the IEC 62443 baseline — acknowledging that ransomware and network-propagating worms represent documented, real-world threats to shipping companies, port operators, and maritime logistics providers.

 

**UR E27 Connection**

E27 §4.1 maps two requirements to this area: item 26 (SR 7.3, System Backup) and item 27 (SR 7.4, System Recovery and Reconstitution). SR 7.4 introduces a stronger target than E26 alone: recovery to a **"known secure state"** — meaning security controls must be verified intact post-recovery, not just services running. The layered relationship matters: E26 defines the vessel-level capability requirement; E27 drives suppliers to build the component-level mechanisms that make vessel-level recovery actually achievable.

 

**Implementation Insight** 🛡️

One persistent challenge: backup schedules designed for IT environments don't account for OT operational windows. Backup processes that interrupt SCADA polling cycles or introduce latency on control networks can cause nuisance alarms — or worse, missed sensor readings. Offline backup rotation procedures also need to be crew-executable, with clear labeling, physical storage locations defined in the ship's cyber management plan, and restore manuals written for operator-level competency, not IT specialist knowledge.

 

**For maritime cyber practitioners: have you seen backup restore procedures actually tested under simulated incident conditions — not just verified as "backed up"? What did you find?**

 

📌 Post 16/17 in my IACS UR E26 series — breaking down all 17 requirements across the Identify → Protect → Detect → Respond → Recover framework