A cyber incident rarely arrives with a clear label. It usually looks like an ordinary fault: a mailbox rule nobody created, a VPN session outside a support window, a workstation that suddenly becomes slow, or files that no longer open.
From the technical side, the first challenge is not naming the malware. It is working out what the affected system can reach and what might be lost if we isolate or restart it. On a yacht, that judgement matters. The same network may support crew administration, guest services, SatCom, CCTV, bridge data, alarm displays, or engineering systems. A response that is correct for a crew laptop can be unsafe for an OT workstation.
The method below gives the onboard team a repeatable sequence. It is based on recognised cyber-response frameworks, but it is written for the decisions an ETO, AV/IT officer, engineer, Captain, and management team actually need to make.
No single framework is a complete yacht incident procedure. They operate at different levels.
Framework / How it helps onboard
- NIST Cybersecurity Framework 2.0
- Provides the overall cycle: Govern, Identify, Protect, Detect, Respond, and Recover. It makes incident response a continuing management responsibility rather than an emergency IT task.
- NIST SP 800-61 Rev.3
- Turns incident response into risk-management outcomes across that cycle. It connects preparation, detection, response, recovery, communication, and improvement.
- ISO/IEC 27035-1:2023
- Provides a structured incident-management process covering preparation, detection, reporting, assessment, response, and lessons learned.
- IMO MSC-FAL.1/Circ.3/Rev.3
- Adds the maritime priority: cyber decisions must support safe, secure, and operationally resilient shipping.
- NIST SP 800-82 Rev.3 and ISA/IEC 62443
- Add the OT constraint. Safety, availability, equipment behaviour, and recovery capability must be considered before applying ordinary IT containment methods.
NIST CSF 2.0 is not a numbered emergency checklist. Its six functions are concurrent and continuous. For onboard use, the practical response sequence below draws mainly from Detect, Respond, and Recover, while Govern, Identify, and Protect provide the authority, asset knowledge, segmentation, logs, backups, and contacts that make a response possible.
The first hour goes badly when nobody knows who can disable an account, isolate a VLAN, contact a vendor, or approve degraded operation. The response plan should settle those questions before an incident.
At minimum, keep:
- A current network and system map showing trust zones and critical dependencies.
- Named incident, management, vendor, insurer, and regulatory contacts.
- A clean administrative access method that does not depend on the affected network.
- Known-good backups for configurations, servers, cloud data, and critical workstations.
- Sufficient log retention for firewalls, VPNs, identity, endpoints, cloud services, and remote support.
- The rapid notification and full incident report forms available offline.
These are the Govern, Identify, and Protect parts of the NIST model. Without them, Detect and Respond become guesswork.
Treat a credible warning as an incident until it is assessed. Do not wait for proof of a sophisticated attack.
First establish whether the vessel remains safe to operate. Check navigation, propulsion, steering, power, communications, alarms, access control, and emergency functions. If any of these may be affected, bring in the Captain and responsible engineer immediately.
Name one incident lead and start a UTC timeline. Record who reported the issue, what they observed, which system was involved, and what was happening onboard. Stop unrelated changes and ask crew not to reboot, update, or “fix” affected equipment independently.
The initial declaration can be simple: “Suspected cyber incident affecting the crew file service. No known bridge or engineering impact. Containment and scope checks are in progress.”
Confirm that the signal is real, then classify the incident by consequence rather than by technical label.
Ask:
- Which account, device, service, or network first showed abnormal behaviour?
- What can it communicate with?
- Is information being viewed, changed, encrypted, deleted, or exported?
- Could the event affect vessel operation, safety, privacy, security, or guest service?
- Is the activity still happening?
One failed login may be a user mistake. A failed login followed by a new MFA method, a mailbox forwarding rule, and an overseas session is an account compromise. A network outage may be failed hardware, a loop, hostile traffic, or a deliberate isolation by another responder. Classification should remain “suspected” until evidence supports a stronger conclusion.
Before making a disruptive change, capture what will disappear.
Start with the screen in front of you: alerts, error messages, ransom notes, usernames, device names, IP addresses, and visible timestamps. Export short-retention records such as firewall sessions, VPN activity, identity sign-ins, cloud audit logs, endpoint alerts, remote-support history, and relevant switch events.
Keep one incident timeline and label findings as confirmed, suspected, or ruled out. Record every containment action, including who authorised it and why. Preserve original files where practical and restrict access to the evidence, which may itself contain credentials, personal data, owner information, or sensitive network details.
Do not wipe, reinstall, or casually reboot the first affected device. Volatile evidence may be lost, and a later forensic review may need the original system. Where OT or bridge-adjacent equipment is involved, evidence collection must not interfere with the system's safe operation.
Containment should stop further harm without creating a larger operational problem.
Start narrowly where possible:
- Suspend one compromised account rather than the whole identity service.
- Terminate one unauthorised VPN session rather than disconnecting every WAN path.
- Quarantine one endpoint or VLAN rather than shutting down the core network.
- Block a malicious domain, address, token, or application where the evidence supports it.
If ransomware is spreading, wider network isolation may be necessary. If an OT, bridge, power, alarm, propulsion, or safety-related system is involved, do not scan, patch, reboot, or disconnect it blindly. Agree the operational fallback with the Captain, Chief Engineer, system owner, and competent vendor before changing its state.
Containment is temporary control, not proof that the threat has gone.
The investigation must answer five questions:
- How did access begin?
- Which identities and systems were reached?
- What changed?
- Was data viewed or removed?
- What would allow the activity to return?
Follow identity and movement. Review sign-in history, MFA changes, email rules, remote-access records, endpoint detections, privileged-account use, configuration changes, and traffic between network zones. Compare the timeline with approved maintenance, refit, and vendor-support activity.
Removal should address the root cause, not just the visible symptom. A compromised cloud account may require malicious MFA methods, delegated applications, forwarding rules, active sessions, and recovery details to be removed. An infected server may need a clean rebuild. A supplier compromise may require replacement credentials, certificates, API tokens, or remote-access methods across more than one system.
If specialist forensics, an insurer, law enforcement, flag, class, or a privacy adviser may become involved, agree the evidence and remediation approach before destroying useful artefacts.
Recovery is a controlled return to service, not a race to make the screen green.
Restore from a trusted point in time only after the original entry path and persistence have been addressed. Bring services back in priority order. Start with a limited group or isolated segment, test normal and fallback operation, then widen access while monitoring for recurrence.
Before approval, confirm:
- The affected scope and initial access path are understood.
- Malicious access and persistence have been removed.
- Exposed passwords, tokens, keys, and certificates have been replaced.
- Restored data and configurations came from a trusted source.
- Required vessel functions have been tested.
- Logging, alerting, and backup protection are active.
- Residual risk and operating limitations are recorded.
For OT and bridge-adjacent systems, manufacturer, class, flag, or survey involvement may be required. Record who approved the return to service.
Use the rapid notification form for the first operational picture. It should state what is known, what is affected, whether the vessel is safe, what containment has been applied, and what help or decision is needed. Do not delay it while waiting for a perfect root-cause conclusion.
Use the full incident report to build the final timeline, evidence record, technical findings, recovery tests, notifications, and corrective actions. The UK NCSC advises keeping incident management connected to business continuity, disaster recovery, and crisis management. ISO/IEC 27035 also treats lessons learned as part of the incident process, not an optional meeting after the technical work.
External reporting depends on jurisdiction and impact. Flag, class, coastal or port authorities, insurers, law enforcement, data-protection authorities, affected individuals, and suppliers may need to be involved. Where UK data-protection law applies, a reportable personal-data breach generally has a 72-hour notification window from awareness. The onboard forms support this work; they do not replace the applicable reporting route or legal advice.
Close the incident only when corrective actions have owners and due dates. Update the risk assessment, system records, network design, backup approach, vendor access, monitoring, and training where the evidence shows a weakness.
Incident pattern / Response difference
- Phishing or business email compromise
- Preserve the original message and headers. From a clean device, suspend the account, revoke sessions, inspect MFA and mailbox rules, and verify payment or supplier changes through a known contact route.
- Ransomware or destructive malware
- Isolate affected IT endpoints and segments quickly, protect clean backups, retain ransom notes and affected files, and scope lateral movement before rebuilding. Follow the CISA StopRansomware response checklist alongside the vessel plan.
- Unknown vendor or VPN access
- Terminate the specific session or account where safe. Preserve firewall, identity, and supplier logs. Confirm the work through a known contact, not through details supplied in the suspicious session.
- Cloud or SaaS compromise
- Use a clean administrator identity to block access and preserve audit logs. Review tokens, applications, sharing links, forwarding, recovery methods, and other tenants or services connected to the account.
- Lost or stolen device
- Revoke active sessions, assess encryption and locally stored data, use approved remote lock or wipe capability, and start the privacy and operational impact assessment.
- Bridge-adjacent or OT concern
- Prioritise safe operation and approved degraded modes. Coordinate changes with the operational owner and competent vendor. Avoid indiscriminate scanning, patching, rebooting, or network isolation.
The firewall shows a support account connected to the yacht outside an approved window. At the same time, a crew file server begins generating unusual write activity.
The ETO first checks whether that remote-access path can reach bridge or engineering networks. It cannot, and those systems remain normal. The Captain is informed, an incident is declared, and the VPN session details and current firewall logs are exported.
The specific vendor account is disabled. The affected file server VLAN is isolated, while guest internet and operational networks remain available. The server is left powered until the evidence approach is agreed.
The investigation links the session to a reused supplier credential. Logs show access to the crew server but no route into OT. The account is replaced, other supplier identities are reviewed, the exposed service is rebuilt from a trusted image, and files are restored from a protected backup. Access is returned first to a limited test group.
The important result is not only that the files work again. The yacht can show the access path, affected scope, containment decision, clean recovery point, return-to-service tests, and the change that prevents the same support account being used without approval.
This method applies broadly to yacht IT, cloud, SatCom, remote support, AV/IT, security, bridge-adjacent, and OT incidents. Exact authority, notification, evidence, and recovery requirements depend on the affected system, flag, class, company SMS, operating area, contracts, insurance, and privacy law.