Ship Cybersecurity Management: IMO Guidelines for Fleets

The IMO Cyber Mandate and the Fleet Operator

IMO Resolution MSC.428(98), adopted in 2017 and operative from 1 January 2021, requires every company subject to the ISM Code to ensure that cyber risks are appropriately addressed in the Safety Management System. The resolution is short and high-level. It does not prescribe controls, tools or architectures. It simply makes cyber risk a safety matter that the SMS must manage, with the same enforcement teeth (Document of Compliance at company level, Safety Management Certificate per vessel) that the ISM Code already carries.

For an operator of a single vessel, compliance is a contained exercise. For a fleet operator running tens or hundreds of vessels across multiple flags, multiple classification societies, multiple equipment generations and multiple management offices, the problem changes shape entirely. The requirement is identical per vessel, but achieving consistent, demonstrable, auditable cyber management across a diverse fleet is an operational and document-control challenge before it is a technical one.

The companion operational guidance, MSC-FAL.1/Circ.3 (Guidelines on Maritime Cyber Risk Management), frames the work around five functional elements borrowed from established cyber risk frameworks: identify, protect, detect, respond and recover. The fleet operator's job is to translate these five functions into a repeatable cyber security management plan that every vessel can run and every auditor can verify.

What a Ship Cyber Security Management Plan Contains

The cyber security management plan is the document that operationalises the IMO requirement on each vessel. It is not a policy statement and it is not a standalone binder bolted onto the SMS. It is a structured plan, referenced from the relevant SMS sections, that a master, chief officer and chief engineer can actually use. A good plan has a stable structure that repeats across the fleet so that a superintendent moving between vessels finds the same headings in the same order.

At a minimum the plan should cover the following elements, each written in the same style and structure as the rest of the SMS:

• Scope and roles: which systems are covered, who is accountable ashore (the company cyber lead, the DPA), who is accountable on board (master, chief engineer, ETO)
• Asset inventory: bridge, engine, cargo, communications and crew systems with vendor, version, network location and criticality rating
• Risk assessment: threats, vulnerabilities, likelihood and impact, residual risk after controls, per vessel class with vessel-specific deltas
• Protective controls: segmentation, account management, removable media handling, vendor remote access, patching and exceptions
• Detection: what is monitored on board and ashore, integrity checks on safety-critical systems, log handling
• Response and recovery: cyber contingencies integrated into existing emergency procedures, vessel-to-shore notification, manual fallback for OT systems
• Training and drills: who is trained, on what, at what cadence, with records
• Management of change: how new systems, software upgrades and vendor changes are assessed before they alter the cyber posture

Integrating Cyber Into the Safety Management System

The defining feature of the IMO approach is integration. Cyber risk is to be managed inside the existing SMS, not maintained as a parallel system. This is where most fleet operators stumble. A standalone cyber policy, however well written, does not satisfy the requirement if the SMS itself does not reference cyber and does not treat cyber failures as safety hazards.

Practical integration means the existing SMS sections absorb cyber content. The shipboard inspection routine gains a cyber walkthrough item. The emergency response procedures gain cyber-specific actions: isolate the suspect system, revert to manual or paper operation, conduct a loss-of-communications drill. The master's review gains a periodic cyber posture summary. The internal audit programme gains cyber control verification. The familiarisation checklist for joining crew gains cyber items. The plan does not live in a separate place that the crew never opens. It lives inside the operating documents the bridge and engine room already use.

For a fleet, the integration approach must be templated. The company writes the cyber additions into a master SMS template, then each vessel inherits the template with vessel-specific parameters (the actual asset list, the actual network diagram, the actual vendor list). This is what makes the fleet auditable: every vessel's SMS handles cyber the same way, differing only in the specifics that genuinely differ.

Achieving Fleet-Wide Consistency

The single biggest difference between a one-vessel operator and a fleet operator is the need for consistency at scale. An auditor sampling three vessels from a fleet of forty expects to see the same plan, the same procedures, the same training, the same evidence structure, with only the legitimate vessel-specific variations. When each vessel has its own bespoke approach, the audit becomes a series of surprises and the company cannot defend a coherent posture.

The mechanism for consistency is a tiered plan: a fleet-level cyber policy and standard, a class-level cyber security management plan per vessel type (because a bulk carrier, a product tanker and a container vessel have genuinely different OT environments), and a vessel-level annex that captures only what is unique to that hull. The fleet level rarely changes. The class level changes when equipment standards change. The vessel annex changes when that vessel changes. This structure keeps the documentation maintainable as the fleet grows and ages.

Consistency also applies to evidence. A fleet operator should be able to produce, on demand, a fleet-wide training compliance view, a fleet-wide drill log, a fleet-wide asset inventory and a fleet-wide open-findings register. If these can only be assembled by emailing forty masters, the programme is not operational. Centralising the evidence (in a fleet management platform or a structured shared repository) is the difference between a programme that survives audit and one that scrambles before it.

Adding Technical Depth with IEC 62443

MSC-FAL.1/Circ.3 is deliberately technology-neutral. It tells the operator what functions to manage but not how to engineer the controls. To give the plan real technical depth, fleet operators increasingly anchor the protect and detect functions to IEC 62443, the international standard for industrial automation and control system security, applied to the vessel as an operational technology environment.

IEC 62443 contributes a zones-and-conduits model that maps cleanly onto a vessel. Bridge OT, engine OT, cargo OT, vessel IT and the crew network become distinct security zones; the connections between them become conduits with explicit policy and monitoring. The standard's security levels (SL-1 through SL-4) give a vocabulary for stating how strongly each zone must be protected, which is useful when a fleet has both modern IEC-aware vessels and older flat-network ships that need a remediation roadmap.

For a fleet, the value of IEC 62443 is that it gives engineers a defensible technical baseline that does not change with the auditor's preferences. The cyber security management plan can state, for each vessel class, the target zone model and security levels, and then each vessel's annex records how close it is and what the remediation gap looks like. This turns a vague obligation into an engineering programme with measurable progress.

Running the Plan as a Living Document

A cyber security management plan that is written once and filed is worse than useless, because it gives a false sense of compliance that collapses at the first serious audit. The plan must run on a defined lifecycle with named owners and scheduled reviews. The asset inventory is updated whenever equipment changes. The risk assessment is reviewed at least annually and after any significant change. Training is delivered on a cadence with records. Drills are run and documented. The management-of-change process gates every new system, upgrade or vendor before it can alter the posture.

For a fleet, the lifecycle is best run as a calendar. Each quarter has defined cyber activities: a training cohort, a drill scenario, an internal audit sample, a vendor review. The company cyber lead tracks completion across the fleet and escalates gaps. This rhythm is what an auditor recognises as a living programme. A fleet that can show twelve months of dated, named, scenario-specific evidence is in a fundamentally stronger position than one with a polished but static document set.

Codesecure supports fleet operators by building the tiered plan template, running the initial fleet-wide gap assessment, delivering the crew training, facilitating the tabletop drills, and standing alongside the DPA during flag state and class cyber audits. The objective is a plan the crew uses and the auditor trusts, not a document that exists only to be shown.