Part of the RESPOND Playbook ← Return to Hub
Phase: Respond All vessels
Satisfies: E26IMO MSC-FAL.1BIMCO v5

Regulatory & Shore-Side Reporting

This guide covers the external reporting obligations triggered by a cyber incident — who to notify, by when, using what channel, and what information to include. A delayed or incomplete report can result in Port State Control detention, Class findings, or insurance complications. The DPA coordinates external reporting — the ETO provides the technical content.

When the vessel is under cyber attack, the shore-side office acts as your extended technical team. However, they can only help if the information you provide is structured and timely. The Master is responsible for external notifications — the ETO’s role is to provide accurate technical input for each report and to support the DPA in assembling the evidence package.

What constitutes a reportable incident

Not every cyber anomaly requires external notification. The reporting obligation is triggered by specific criteria — primarily whether essential services were affected or whether there is a safety, environmental, or statutory compliance consequence.

✓ Reportable — external notification required
  • Any incident affecting propulsion, steering, ECDIS, or PMS
  • Any confirmed ransomware or malware on Cat II or III CBS
  • Any incident requiring MRC declaration or manual fallback activation
  • Any incident resulting in loss of GMDSS communications
  • Any incident where vessel safety or crew safety was at risk
  • Any confirmed data breach involving personal crew data
⚠ Internal only — log and monitor, no external notification
  • Suspected virus isolated to crew Wi-Fi with no OT spread
  • Single non-critical workstation failure with no safety impact
  • Rogue device detected and removed before network access
  • Failed authentication attempts with no successful breach
  • Level 1 technical faults assessed and closed within 24 hours

Reporting obligations by authority

The following table defines who must be notified, within what timeframe, and the regulatory basis for each obligation. All notifications are coordinated by the DPA — the Master authorises, the ETO provides technical input.

Authority Trigger Timeline Channel Basis
Company DPA / CSO Any Level 2 or Level 3 incident Within 15 minutes of Level 3 declaration Out-of-band — Iridium or personal mobile ISM Code §8 · SCSRP §6.1
Class Society Any incident affecting Cat II or III CBS · MRC declared · recovery from Golden Image Per SCSRP §6.1.4 — typically within 24 hours Written report via DPA to Class surveyor IACS UR E26 §4.4.1 · Class rules
Flag State Incident resulted in partial or total loss of essential services · MRC declared · SOLAS reportable event As soon as practicable — within 24 hours where possible Written report via company to flag state maritime authority ISM Code §8 · SOLAS I/21
Port State Control Incident affects safe navigation within port limits · vessel arriving in port with unresolved cyber event Before arrival at port — notify VTS if within traffic separation scheme Pre-arrival notification via DPA to PSC authority ISM Code §8 · SOLAS IX · MSC.428(98)
Equipment vendors (OEM) Any confirmed compromise of an OEM-supplied CBS · emergency patch required · remote diagnostic support needed As needed — ETO contacts OEM directly with DPA awareness OEM emergency hotline — stored in SCSRP Appendix IACS UR E27 §4.6 · vendor SLA
P&I Club / Insurer Any incident with potential third-party liability · cargo damage · pollution risk · personal injury As soon as practicable — DPA notifies club Written notification via company to P&I correspondent Club rules · policy conditions

The incident data package

Prepare the evidence package for the DPA and shore-side SOC. Transmit via a clean connection — Master’s Iridium phone, personal 4G hotspot, or any channel confirmed not affected by the incident. Never transmit evidence packages via a network you suspect is compromised.

Mandatory evidence checklist REQUIRED FOR DPA / CLASS
Incident timestamp (UTC)Exact date and time the anomaly was first detected — not when it was reported
Affected systems listName, criticality category, and current status of every CBS affected — distinguishing confirmed compromised from suspected
Patient Zero identificationDevice name, IP address, MAC address, and physical location of the first device to show symptoms
Syslog / firewall log exportLast 60 minutes of logs from the centralised syslog server showing the malicious activity — exported to clean USB before isolation
Visual evidencePhotographs of ransom notes, BSOD screens, Task Manager showing malicious processes, and any unusual console output
Actions taken logChronological record of every technical action taken since detection — isolation steps, shutdowns, notifications — with timestamps
Vessel safety statusCurrent state of ECDIS, propulsion, steering, and PMS — whether on automated CBS or local manual control — and current voyage phase

Initial notification template — DPA to Class Society

This template gives the DPA a starting point for the formal Class notification. The ETO provides the technical fields — the DPA completes the regulatory and company sections.

Subject: Cyber Security Incident Notification — [Vessel Name] — [Date UTC]

To: [Class Society Surveyor / Fleet Department]

This notification is submitted in accordance with IACS UR E26 §4.4.1 and [Class Society] rules for cyber incident reporting.

Vessel: [Name] | IMO Number: [Number] | Flag: [Flag State]

Incident detected: [Date] [Time] UTC | Position at time of detection: [Lat/Long or port name]

Incident severity level: Level [1/2/3] — [Low/Medium/Critical]

Systems affected: [List affected CBS with criticality category]

Essential services status: [Propulsion / Steering / Navigation — normal / on manual fallback / impaired]

Actions taken: [Summary of isolation and containment steps]

Current vessel status: [Proceeding to destination / at anchor / diverting to port of refuge]

Evidence package: [Attached / to follow within 24 hours]

A detailed written report will follow within [24/48] hours. We request guidance on survey attendance requirements and any Class-specific reporting obligations.

Legal protection note

Under UR E26 §4.5.1, the ETO must not attempt to wipe or rebuild a system until shore-side teams confirm they have sufficient forensic data. Prematurely wiping a system may constitute a failure in regulatory compliance and could affect insurance and legal outcomes. Always obtain explicit DPA sign-off before any irreversible recovery action.

Next Section

Respond Phase: Summary & Audit Readiness

Respond Phase: Summary & Audit Readiness Phase Objective The Respond Phase is about Effective Containment. We ensure...

Scroll to Top