[IACS UR E26] Respond – 11 Incident Response Plan

IACS UR E26 - Incident Response Plan

 

**What happens when a cyber incident takes down the very system where you stored your cyber incident response plan?**

 

This isn't a theoretical edge case. It's exactly why IACS UR E26 §4.4.1 mandates a hard copy of the Incident Response Plan onboard — and it reveals just how differently maritime cyber resilience must be engineered.

 

**What UR E26 §4.4.1 Actually Requires**

Shipowners must prepare a documented IRP that covers every in-scope Computer-Based System (CBS) — specifying system breakpoints for isolation, event indicators, expected consequences of cyber incidents, and response options. Critically, this plan must be ready before the first annual survey and kept current throughout the ship's life. It isn't a one-time deliverable; it's a living document tied to the vessel's maintenance cycle.

 

**Why This Is Uniquely Maritime**

Ships operate in environments where both physical isolation and operational continuity are non-negotiable. E26 is explicit: response options must prioritize maintaining safe operation over security-motivated shutdown. Transferring to local or manual control is a last resort, not a default. A crew 400 nautical miles offshore cannot call a help desk. Pre-defined breakpoints — which compromised CBS segments can be isolated without triggering a safety-critical failure — must be decided ashore, documented clearly, and understood by crew before they're ever needed.

 

**IEC 62443 Technical Depth**

IEC 62443-2-1 §4.3.4.5 requires documented incident response procedures, communication plans, and evidence preservation — forming the procedural backbone that E26 builds on. The pre-defined breakpoint requirement maps directly to IEC 62443's zone and conduit isolation procedures. But E26 adds a maritime operational layer: the prioritization hierarchy explicitly reflects the IACS principle that **availability for safety outranks security-motivated shutdown** — a posture that differs meaningfully from enterprise IT frameworks where taking a system offline is often the first response.

 

**The E27 Connection 🔗**

The IRP doesn't emerge from nothing. E27 §3.1.8 requires suppliers to document CBS-specific information — known failure modes, recovery sequences, safe states — that feeds directly into the vessel-level plan. The systems integrator aggregates this supplier data, and the shipowner assembles the final IRP. This is a deliberate three-tier chain: supplier → integrator → shipowner. E26 §4.4.1.4.1 even requires the Cyber Safety Data Dossier (CSDD) to reference this E27 §3.1.8 documentation explicitly.

 

**Implementation Insight ⚠️**

The hardest part isn't writing the IRP — it's obtaining meaningful CBS-specific consequence data from suppliers. Generic templates won't satisfy class surveyors. Shipowners should contractually require E27 §3.1.8 compliance from equipment suppliers at the procurement stage, not after delivery.

 

**Question for the community:** Have you seen shipyards or owners successfully integrate E27 supplier data into vessel-level IRPs at newbuild? Where does that handoff most commonly break down?

 

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

IACS UR E26