Writing a Ship Cyber Security Management Plan That Satisfies the ISM Code

Why isn't there a standalone "cyber security management plan"?#

There is a persistent misconception that MSC.428(98) created a new, separate document. It did not. The resolution links cyber risk to the ISM Code rather than inventing a parallel regime. Companies must address cyber risks in the same way as any other risk on board, assess risks arising from the use of IT and OT on board ships, establish appropriate safeguards against cyber incidents, and incorporate their cyber risk management plans and procedures into existing company safety management systems.

IMO closed the door on a parallel system explicitly. At its 101st session, the Maritime Safety Committee agreed that aspects of cyber risk management, including physical security aspects, should be addressed in Ship Security Plans under the ISPS Code, but that this should not be considered as requiring a company to establish a separate cyber security management system operating in parallel with the SMS.

So the practical answer is a split. Physical security aspects of cyber security, such as procedures for physical access to areas with IT and OT systems, sit in the Ship Security Plan under the ISPS Code; the SMS carries a reference to those procedures; and the remaining cyber risk management procedures live in the SMS itself.

What does the ISM Code actually require me to prove?#

The ISM Code is mandatory through SOLAS Chapter IX. Made mandatory since 1998, it requires companies to implement a documented Safety Management System, and it applies to passenger ships and cargo ships of 500 GT and above on international voyages. Compliance is evidenced by two certificates. The Document of Compliance is issued to the company after verifying its shore-side SMS meets ISM Code requirements; the Safety Management Certificate is issued to each ship after verifying that the SMS is effectively implemented onboard.

That word — effectively — is the whole game. Audits are not a documentation check. The purpose of the audits is to verify the effective functioning of the safety management system. A binder full of policy that crew have never seen fails. Objective evidence that procedures are used, drilled and reviewed passes.

What was the deadline, and has it passed?#

Yes, comprehensively. Cyber risks were to be addressed in company safety management systems no later than the first annual verification of the company's Document of Compliance after 1 January 2021. That milestone is now years behind us, which means cyber is not an emerging topic for auditors — it is baseline DOC and SMC scope, and gaps are cited like any other non-conformity.

Which framework do I build the plan around?#

The functional backbone comes from the IMO guidelines. The current version matters: IMO published MSC-FAL.1/Circ.3/Rev.3 on 4 April 2025, and with its release, Rev.2 was withdrawn. Verify you are working from Rev.3 before quoting any clause, because trade-press summaries still circulate against older revisions.

The guidelines are deliberately non-prescriptive. They are expressed in broad terms for widespread application: ships with limited digital systems may find a simple application sufficient, while ships with complex digital systems may require greater care and should seek additional resources. And they are recommendations, not law — these Guidelines are recommendatory. The mandatory force comes from the ISM Code obligation to control risk; the guidelines just tell you how.

The five functional elements are the ones most operators already recognise from NIST. Section 3 of the guidelines provides the elements of effective cyber risk management — identify, protect, detect, respond and recover — and these elements apply regardless of whether a cyber incident is malicious or an unintended consequence. Rev.3 also modernised the references. The amendments include additional key definitions, expanded elements of cyber risk management, and information on standards and best practices, including a section on IACS UR E26 and E27 and the NIST 2.0 Framework.

What goes in the SMS to satisfy an auditor?#

Map your work to the five functions, and for each, produce a document and a record. The document states the procedure; the record proves it happened.

The risk assessment is the foundation. Rev.3 frames the Identify function as determining current cyber risk and assessing the impact of an incident on safety, availability and integrity — identify cyber-related threats; identify vulnerabilities to systems, services, assets, data and capabilities; and keep records of cyber incidents. A ship security assessment approach can seed this. When incorporating cyber risk management into the company SMS, consideration should be given to whether, in addition to a generic risk assessment of the ships operated, a particular ship needs a specific risk assessment.

Two governance points auditors weight heavily. First, ownership must be senior, not delegated to the IT desk. Effective cyber risk management should start at the senior management level. It should involve senior management on an ongoing basis, instead of, for example, only the ship security officer or the IT manager. Second, roles must be explicit. Effective cyber risk management relies on a clear allocation of responsibilities and tasks within the company, and in some companies some tasks are outsourced to third parties — so where you rely on Marlink, a class society or a managed provider, name them and document the boundary.

Where do the ISPS Code and IACS class rules fit?#

Keep the boundaries clear so you do not duplicate or contradict documents. Physical protection of cyber assets — locked comms rooms, controlled access to the bridge and machinery spaces — belongs in the SSP. The ISPS Code is focused on external threats, malicious actions and physical security, and in that respect provides an incomplete framework for effective cyber risk management. Note the practical friction: changes to the approved ship security plan require approval by the Administration, whereas SMS procedures can be revised more responsively — a reason to keep the dynamic cyber procedures in the SMS and only cross-reference the SSP.

Instrument	What it governs	Applies to	Change control
ISM Code / MSC.428(98)	Cyber risk procedures, roles, drills	All SOLAS/ISM operators	Company-controlled SMS revision
ISPS Code / SSP	Physical access to IT/OT spaces	ISPS-applicable ships	Administration approval required
IACS UR E26 / E27	Ship and equipment cyber resilience by design	New builds from 1 Jul 2024	Classification society

On class rules, do not misapply them to your existing fleet. IACS published UR E26 "Cyber Resilience of Ships" and UR E27 "Cyber Resilience of On-Board Systems and Equipment", and the revised requirements apply to new ships contracted for construction on and after 1 July 2024. The originals were never enforced: to avoid confusion, the original versions, along with their previous application date of 1 January 2024, have been withdrawn. UR E26 also builds surveys into the ship's life. The UR requires a Cyber Resilience Test Procedure covering testing during construction and commissioning as well as during the annual surveys over the operational life of the vessel. For existing Gulf-flagged tonnage, E26/E27 is a voluntary benchmark, not an obligation — verify applicability with your class society before committing budget.

What does this mean for operators in the Gulf?#

If you run SOLAS tonnage out of Jebel Ali, Fujairah, Hamad or Dammam, treat cyber as live audit scope today, not a project for next year. The failure mode Gulf DPAs see most is a well-written policy set with no records behind it — no drill logs, no incident register, no evidence of management review. That is what generates non-conformities, because the auditor's job is to test effectiveness, not to admire the binder.

Before your next annual DOC verification, run a gap check against the five functions, confirm you are drafting against Rev.3, and make sure ownership sits with your DPA and senior management rather than a single IT contact. Where third parties — connectivity providers, class, managed OT vendors — carry part of the load, put the boundary in writing.

If you want a structured pre-audit gap assessment mapped to MSC.428(98) and Rev.3, book a consultation with Solas Security.