[IACS UR E26] Recovery – 15 Recovery Plan

IACS UR E26 - Recovery Plan

 

# 🛟 What happens when your ship's recovery plan is stored on the same server the attacker just encrypted?

 

That's not a hypothetical. It's the exact scenario UR E26 §4.5.1 was written to prevent.

 

**What UR E26 §4.5.1 Requires**

Shipowners must prepare a recovery plan that restores Computer-Based Systems (CBS) to operational state following a cyber incident. The plan must define Recovery Time Objective (RTO) — how long restoration of communication and processing capability may take — and Recovery Point Objective (RPO) — the maximum acceptable period of data loss — for each relevant CBS type. Critically, hard copies must be maintained both onboard and ashore, accessible without any electronic system.

 

**Why This Is Uniquely Maritime**

A vessel 500 nautical miles offshore has no IT helpdesk, no on-call incident response team, and potentially no functioning network. If a ransomware event encrypts every digital asset onboard, the crew must still be able to recover essential systems — with paper in hand. This requirement acknowledges that maritime OT recovery is a human and operational problem before it is a technical one. The plan must be understandable by crew and external personnel without specialist training, not just by the CISO back at headquarters.

 

**IEC 62443 Technical Depth**

IEC 62443-2-1 §4.3.4.5 establishes the foundation: documented recovery procedures, tested processes, and defined escalation paths for industrial cybersecurity. E26 goes further by mandating explicit RTO and RPO values per CBS type — importing enterprise business continuity discipline into maritime OT for the first time. Critically, E26 also addresses the forensics-versus-recovery tension: preserving evidence for post-incident investigation while simultaneously restoring operations. The recommendation to engage external incident response support where possible aligns with IEC 62443's escalation path requirements, adapted for vessels that cannot always act on that recommendation in real time.

 

**UR E27 Connection**

Recovery planning follows a deliberate three-tier structure. Under E27 §3.1.8, equipment suppliers must provide CBS-level recovery documentation — rollback procedures, restoration sequences, and vendor contact details. Systems integrators aggregate these into a coherent vessel-level architecture. Shipowners then assemble the final ship-level recovery plan from those inputs, with the CSDD referencing E27 §3.1.8 supplier documentation per E26 §4.5.1.4.1. The plan is only as complete as the supplier data feeding it.

 

**Implementation Insight**

The hard copy requirement is frequently underestimated. A complete logical network diagram and vendor contact list must survive the incident itself — meaning version control, print schedules, and secure storage locations need to be defined before first annual survey, when auditors will check crew access to plans and backup availability.

 

**For the community:** Have you seen recovery plans in maritime OT that meaningfully define RTO and RPO at the individual CBS level — or does this remain a gap in most implementations?

 

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