The First 15 Minutes
This guide defines the immediate actions to take in the first fifteen minutes of a detected cyber incident — before any systems are shut down or isolated — to preserve evidence and prevent escalation. Under IACS UR E26 §4.4.1, the vessel must have documented incident response procedures. This playbook is that procedure for the first response window.
When an alarm sounds or a critical system behaves erratically, the ETO must resist the urge to immediately reboot hardware. Rebooting wipes the RAM, which contains the only forensic evidence of how the attack started and what it has touched. Follow this sequence instead — in order, without skipping steps.
The 15-Minute Triage Sequence
- Check Bridge consoles — is ECDIS displaying correctly? Is steering responsive?
- Check ECR consoles — are propulsion and PMS displays normal?
- If DP, steering, or propulsion is affected: inform the Master immediately and stand by to activate local manual control
- If vessel operations appear stable: note the time, the first symptom observed, and the system showing it — this is your incident start timestamp
- Do not touch the affected system yet — observe only
- Open the centralised syslog server or IDS dashboard — which device generated the first alert?
- Check the firewall log — are there outbound connections to unknown external IPs?
- Identify which VLAN the affected device is on — this determines the blast radius
- Check for lateral movement indicators: multiple devices showing similar symptoms simultaneously indicates active spread
- Note the Patient Zero: device name, IP address, VLAN, physical location on the vessel
- Do not disconnect anything yet — disconnecting before evidence capture destroys forensic value
- Photograph all affected screens — error messages, pop-ups, ransom notes, and unusual activity visible on the display
- On any responsive Windows CBS workstation, open Task Manager (Ctrl+Shift+Esc) and photograph the Processes tab — this shows running malware processes before a reboot wipes them
- Export the last 30–60 minutes of syslog data to a clean USB drive not connected to the affected VLAN
- Note the current time precisely — this becomes the official incident start time in the Incident Log (TAG-OT-LOG entry)
- If the syslog server is inaccessible: note which devices you cannot reach — that list is itself evidence of the scope
- Do not power off — volatile RAM evidence is lost on power down and cannot be recovered
Communications tree — who to notify and when
Notifications must happen in parallel with evidence capture — not after. Use out-of-band communication (phone, VHF, or personal device on a separate network) if the vessel network is suspected to be compromised.
The “Do Not Do” list
To comply with UR E26 §4.4.1 (Incident Response) and §4.5.1.2 (evidence preservation), the ETO must avoid the following during the first 15 minutes:
| DO NOT reboot — Modern malware resides in RAM. A reboot destroys forensic evidence and may trigger a logic bomb that prevents the system from restarting. | |
| DO NOT delete or “clean” files — Manually deleting a suspected malware file can trigger immediate encryption of all accessible drives as a defensive mechanism. | |
| DO NOT use the compromised network to report — If the vessel’s business network is affected, do not send reports via ship email. Use Iridium, personal mobile, or VHF to shore. | |
| DO NOT isolate before evidence capture — Disconnecting a device before photographing screens and exporting logs destroys the only record of what the attack looked like in progress. | |
| DO NOT attempt technical recovery alone — The first 15 minutes is assess and preserve, not fix. Attempting to remediate without notifying the Master and DPA violates the command structure required by the SCSRP. |
Minute 15 — the decision point
At the end of the 15-minute window the ETO must present a clear assessment to the Master. Three possible outcomes:
The “When in Doubt” rule: If you cannot definitively confirm Outcome A within 15 minutes, escalate to Outcome C. A false alarm costs an hour of investigation. A missed incident costs the vessel.
Master’s key action
If the assessment confirms a Level 3 Incident, the ETO presents findings to the Master to authorise Pillar B: Containment (Network Isolation). The ETO has technical authority to diagnose — the Master has operational authority to act.
The Master’s decision must be logged with a timestamp. This log entry is the primary evidence that the command structure defined in the SCSRP was followed correctly — it will be reviewed by Class at the next survey.
Minimum incident log entry — first 15 minutes
The following must be recorded in the Incident Log before leaving the 15-minute window. This entry forms the opening record of the incident response and will be referenced throughout recovery and debrief.
| Field | What to record |
|---|---|
| Incident date/time | Exact UTC time the first symptom was observed — not when it was reported |
| Patient Zero | Device name, IP address, VLAN, physical location on vessel |
| Symptom description | Exactly what was observed — error message text, unusual process names, ransom note content if applicable |
| Vessel safety impact | State of ECDIS, propulsion, steering, and PMS at time of detection |
| Evidence captured | Photos taken, logs exported, USB drive used (label/serial), Task Manager screenshot if taken |
| Notifications made | Master notified at [time], Chief Engineer at [time], DPA at [time] via [channel] |
| Incident level declared | Level 1 (technical fault) / Level 2 (suspicious event) / Level 3 (confirmed incident) — and who authorised the declaration |
The specific regulatory requirements this playbook satisfies. Use these references when preparing for Class survey or responding to a surveyor's checklist.
