A fleet manager in Fort Lauderdale called me on a Saturday morning last September. Two of his managed yachts had the same problem: encrypted booking systems, a ransom note on the bridge laptop, and no clear idea how the malware got in. The onshore IT vendor's first instinct was to remote into the vessels via the VSAT link to run a scan. I told him to stop. If the VSAT connection was the entry point (and in two of the three maritime ransomware cases I have worked in the past eighteen months, it was), remoting in through that same link is not incident response. It is extending the attack surface.
That conversation lasted forty-five minutes. The legal and insurance aftermath lasted five months. The fleet manager's biggest regret was not the ransomware itself. It was that his incident response plan was a twelve-page document written for a shore-side office, and nobody had thought about what happens when the "call the SOC" step assumes connectivity that does not exist.
This post is the playbook I wish that fleet manager had before the call.
Why Vessel Ransomware Demands Its Own Playbook
The numbers are no longer ambiguous. CYTUR's annual maritime cybersecurity report documented 828 cyber incidents across the shipping and maritime sector in 2025, a 103% increase from 408 the year before. Ransomware accounted for 372 of those incidents, more than double the 156 recorded in 2024. Cydome's parallel analysis found a 150% surge in attacks targeting maritime operational technology, with 87% of those OT attacks driven by ransomware. The average cost per maritime cyber attack now exceeds $550,000, and that figure does not include the legal tail.
These are not abstract statistics. Maersk's 2017 NotPetya incident destroyed 4,000 servers and 45,000 PCs across its global infrastructure, halted operations for ten days, and cost between $250 million and $300 million to resolve. In January 2023, ransomware hit DNV's ShipManager platform and affected approximately 1,000 vessels operated by 70 customers. Full service restoration took two months. In September 2020, CMA CGM took its booking systems offline after a Ragnar Locker ransomware infection spread through its Chinese offices. And ransomware has already reached engine rooms and ballast systems, crossing the IT/OT boundary that most operators still treat as a firewall.
Every one of those organizations had incident response plans. Every one of those plans assumed something that vessel operators cannot assume: that when the crisis arrives, you will have reliable, high-bandwidth connectivity to your security team, your forensics tools, and your backup infrastructure. On a yacht in the middle of a Mediterranean crossing, or a cruise ship two days from the nearest port, that assumption fails. A maritime IR playbook has to work when the satellite link is part of the problem, not part of the solution.
The Regulatory Framework for Vessel Cyber Response
If you operate a vessel that falls under U.S. jurisdiction, you are now legally required to have a plan. The Coast Guard's maritime cybersecurity rule (33 CFR Part 101, Subpart F), which took effect on July 16, 2025, requires every MTSA-regulated vessel to designate a Cybersecurity Officer, conduct a cybersecurity assessment, and maintain a Cyber Incident Response Plan. Reportable cyber incidents (defined as those causing or potentially causing substantial loss of confidentiality, integrity, or availability) must be reported to the National Response Center immediately upon discovery.
The IMO updated its maritime cyber risk management guidelines (MSC-FAL.1/Circ.3/Rev.3) in April 2025, aligning them with the NIST Cybersecurity Framework's five functions: identify, protect, detect, respond, and recover. NIST itself overhauled SP 800-61 in April 2025 with Revision 3, dropping the old four-phase incident response lifecycle in favor of mapping IR activities directly to CSF 2.0's six functions (adding Govern to the original five).
For newbuilds contracted after July 2024, IACS Unified Requirements E26 and E27 mandate ship-level and system-level cyber resilience, with specific requirements for detection, response, and recovery, not just prevention.
The regulatory convergence is clear: every major framework now requires you to have a documented, practiced response capability. If your CMMC or NIST 800-171 compliance program does not include a maritime-specific IR annex, it has a gap.
Phase 1: Preparation Before the Ransom Note
The most important phase of incident response happens before anything goes wrong. On a vessel, preparation has constraints that shore-side plans rarely account for.
The offline IR kit. Your incident response procedures need to exist in a format that does not require the systems they describe. That means printed runbooks, physical copies of network diagrams, contact lists on paper, and a USB drive with forensic imaging tools (write-blocked, tested quarterly). If your IR plan lives on a SharePoint site accessible only via the VSAT link, it is not a plan. It is a liability.
Designated Cybersecurity Officer. The USCG rule requires one. More importantly, this person needs to be someone who is physically on the vessel, not a shore-side consultant reachable by satellite phone. Train the CySO to execute the first four hours of the playbook without outside help. Those four hours determine whether the incident stays contained or spreads to OT systems.
Network segmentation. If you have implemented zero-trust architecture with proper VLAN segmentation, containment is a matter of isolating the affected zone. If you have not, containment means pulling cables and hoping you pull the right ones. Segmentation is the single most effective preparation step for ransomware resilience.
Air-gapped backups. Your backup infrastructure must include offline copies that ransomware cannot reach. A NAS device on the vessel network is not air-gapped. A backup that is reachable from the same network segment as the infected system is not a backup. It is the next target. Store cold backups on encrypted external drives, rotated monthly, physically locked in a compartment that is not the server room.
Sovereign compute. This is where the knowledge-ark model earns its keep. A vessel running its own AI stack (models, knowledge bases, diagnostic tools) on local hardware does not lose its IR-support capability when the satellite link goes down or gets severed during containment. If your threat detection, log analysis, and crew communication tools all depend on cloud services, cutting the satellite link (which may be necessary for containment) also cuts your ability to respond. On-vessel AI that runs entirely behind the hull is the only architecture that does not force you to choose between containment and capability.
Phase 2: Detection and Containment at Sea
Detection on a vessel looks different from detection in an enterprise SOC. You do not have a team of analysts watching dashboards around the clock. You have a CySO with other duties, a small crew, and monitoring tools that need to work without phoning home.
What to watch for. Anomalous outbound traffic from OT VLANs. Unexpected DNS queries. File system changes on critical servers. Lateral movement between network zones. If your segmentation is properly instrumented, cross-zone traffic that violates policy is a high-fidelity signal. Log aggregation should happen on-vessel, not in a cloud SIEM you cannot reach when the link is down.
The VSAT decision. This is the hardest call in maritime IR, and most plans dodge it. If the attacker entered through the satellite link (a compromised vendor VPN, a malicious update, a credential-stuffed remote access tool), the VSAT connection is the attack path. Leaving it open risks exfiltration and command-and-control traffic. Cutting it stops the attacker but also stops your ability to call for help, download patches, or communicate with shore-side counsel.
The answer is not binary. Isolate the VSAT terminal to a quarantine VLAN that permits only voice and pre-approved IP addresses (your insurer's IR hotline, coast guard reporting endpoints, legal counsel). Kill all other traffic. This requires pre-configuration. If you are making firewall rules for the first time during an active incident, you have already lost time you cannot afford.
Evidence preservation. Take forensic images of affected systems before you remediate. Capture volatile memory if possible (tools like winpmem or AVML on a prepared USB). Photograph ransom notes. Record timestamps. Log every action taken and by whom. Insurance claims, regulatory reports, and potential law enforcement referrals all depend on evidence you preserve now, not evidence you reconstruct later.
Phase 3: Eradication and Recovery Without Shore-Side Help
In a shore-side environment, eradication typically involves your MSSP remotely scanning every endpoint, rebuilding compromised servers from cloud-hosted golden images, and restoring data from offsite backups. At sea, you have none of that.
Rebuild from local resources. If you have followed the preparation steps, you have air-gapped backups and bootable recovery media on the vessel. Rebuild affected systems from known-good images. Do not trust any system that was on the same network segment as the compromised machines until it has been reimaged or verified clean.
The DNV lesson. When ransomware hit DNV's ShipManager platform in January 2023, the 1,000 affected vessels could still use the offline functionality of the software. Operations continued, degraded but functional, because the software was designed to work without a persistent shore-side connection. That is the architecture pattern that matters for recovery at sea: systems that degrade gracefully when connectivity is lost, rather than systems that fail completely. The vessels that weathered the DNV incident best were the ones whose crews had trained on offline procedures. The ones that struggled were the ones that had never operated without the cloud link.
Prioritize by operational impact. Navigation. Communication. Safety systems. Engine monitoring. These come back first. Guest entertainment, booking systems, and crew Wi-Fi can wait. Define the recovery sequence in your plan, not during the incident. Every minute spent debating priorities during an active recovery is a minute of additional downtime.
Verify before reconnecting. Before you bring restored systems back onto the vessel network, verify they are clean. Before you re-enable the VSAT link, confirm the entry point is patched or mitigated. Reconnecting prematurely is how single incidents become double incidents.
Phase 4: Reporting, Legal, and the Insurance Clock
Most vessel operators get the post-incident sequence wrong. They fix the technical problem and then discover the legal obligations they were supposed to have started in parallel.
Regulatory reporting. Under the USCG rule, reportable cyber incidents must be reported to the National Response Center immediately upon discovery. Not after eradication. Not after you have spoken to counsel. Immediately. Flag state authorities may have separate notification requirements depending on registry. If the vessel was in EU waters or processing EU citizen data, GDPR's 72-hour notification clock started when you became aware of the breach, not when you confirmed data was exfiltrated.
Insurance notification. Marine cyber insurance is a maturing but still volatile market. Most policies require notification within 24 to 72 hours of discovery. Some policies require you to use a specific panel of IR firms. If you bring in your own forensics team without insurer approval, you may be paying out of pocket. Know your policy's notification procedures and approved panel firms before the incident, and keep that information in your offline IR kit.
Legal counsel. Engage maritime cyber counsel early, not after you have made decisions about ransom payment, data disclosure, or public communication. The jurisdictional complexity of a maritime cyber incident (flag state, port state, owner nationality, guest nationalities, data processing locations) makes this fundamentally different from a shore-side breach. Your corporate attorney may not have the answers. Maritime cyber law is a specialty, and the number of firms that practice it competently is still small.
Post-incident review. NIST SP 800-61 Rev 3 and the IMO guidelines both call for root cause analysis and lessons learned. Do it. Write it down. Update the playbook. The fleet manager who called me in September has now run three tabletop exercises with his crews. His plan no longer assumes a shore-side IT team will solve the problem remotely.
The Architecture That Survives the Incident
Every section of this playbook returns to the same architectural question: does your vessel's technology stack still function when the link to shore disappears?
Cloud-dependent AI fails at sea under normal operating conditions. Under ransomware conditions, when you may need to sever the satellite link entirely as a containment measure, it fails catastrophically. The sovereign, on-vessel approach (what we call the knowledge ark) is not just a resilience strategy. It is an incident response strategy. Local AI means your threat detection keeps running during the incident. Local backups mean your recovery does not depend on download speeds through a degraded VSAT pipe. Local knowledge bases mean your crew can access IR procedures, regulatory checklists, and communication templates without reaching the cloud.
The vessel that can contain, investigate, and recover without calling home is the vessel that turns a ransomware incident into a bad week instead of a six-month crisis.
If your fleet's incident response plan still assumes the satellite link is the solution, we should talk.