For years, cyber security on board was treated as an office matter: something for the IT department ashore, a long way from the engine room. That era is over. Since the IMO required cyber risk to be addressed in the safety management system (SMS), and since IACS published Unified Requirements UR E26 and UR E27, cyber security has become both an ISM matter and a class matter. In other words: it is inspected, it is audited, and above all it has to be evidenced.
What these instruments ask for looks like what a well-run technical department already does: an up-to-date asset register, controlled software versions, traceable interventions, managed access, tested backups and a recovery plan. The difference is that the "equipment" to be listed now includes PLCs, HMIs, network gateways, integrated navigation systems and every connected device on board.
This article sets out the framework that actually applies — dates and scope — then moves to the operational level: what an owner or manager must document, how a maritime CMMS can carry that evidence day to day, and the questions to put to your software suppliers before signing.
1. The IMO framework: Resolution MSC.428(98) and the SMS
An ISM requirement since 2021
Resolution MSC.428(98), adopted by the Maritime Safety Committee on 16 June 2017, sets a simple principle: an approved safety management system should take cyber risk management into account, in line with the objectives and functional requirements of the ISM Code. The deadline was the first annual verification of the company's Document of Compliance after 1 January 2021.
The key point is that the IMO did not create a separate cyber code. It inserted cyber risk into an existing mechanism, the ISM Code. Cyber risk therefore becomes a risk like any other: identified, assessed and mitigated by safeguards. An auditor — or a port State control officer following up on an SMS deficiency — can legitimately ask for your cyber risk assessment, your procedures and your evidence of implementation, exactly as they ask for drill records or maintenance evidence.
The guidelines and their six functional elements
Practical guidance sits in circular MSC-FAL.1/Circ.3, "Guidelines on maritime cyber risk management", whose revision 3 is dated 4 April 2025. That latest version structures cyber risk management around six functional elements, carried out concurrently and continuously:
- Govern: establish and monitor the risk management strategy, expectations, policies, roles and responsibilities.
- Identify: know the systems, assets, data and dependencies that are critical to ship operations.
- Protect: access control, network segregation, training and contingency planning.
- Detect: be able to spot an incident in a timely manner.
- Respond: have response plans, practise them, restore functions.
- Recover: bring back on-board computer-based systems and the networks needed for operations.
A technical department already handles these six functions without naming them that way: identify is the equipment register; protect is permits and procedures; detect is the engine log and alarms; respond and recover are degraded modes and critical spares. Cyber security does not add a new discipline — it extends an existing one into the digital domain.
2. IACS UR E26 and UR E27: two complementary instruments
Where the IMO addresses the company and its SMS, IACS — the International Association of Classification Societies — addresses the ship and its suppliers. First published in April 2022 for application on 1 January 2024, the two Unified Requirements were withdrawn and reissued as Rev.1 (UR E27 in September 2023, UR E26 in November 2023) to clarify scope and harmonise the survey approach.
UR E26 — Cyber resilience of ships
UR E26 treats the ship as a whole system. It covers design, construction, commissioning and operation, and organises its requirements around identify, protect, detect, respond and recover. It addresses the inventory of computer-based systems (CBS), on-board network topology, access management, interface protection and logging, together with a ship cyber resilience test procedure to be run at construction, at commissioning and then at surveys.
UR E27 — Cyber resilience of on-board systems and equipment
UR E27 goes one level down and speaks to equipment makers and system integrators. A system delivered on board must come with a documentation package: CBS inventory and topology diagrams, description of security capabilities, secure configuration guidelines, secure development lifecycle evidence, a maintenance and verification plan, incident response and recovery information, management of change, and test reports. That package is what your technical team then has to keep alive for twenty years of service.
Scope and application date
Both requirements apply to new ships contracted for construction on or after 1 July 2024. The mandatory scope covers passenger ships on international voyages, cargo ships of 500 GT and above on international voyages, high-speed craft and mobile offshore drilling units of 500 GT and above, and certain self-propelled mobile offshore units used for construction work such as wind turbine installation. For other vessels, application remains possible on a voluntary basis at the owner's request.
Key takeaway: UR E26 and E27 do not make your existing ship "non-compliant" overnight — they target newbuildings contracted from 1 July 2024. Resolution MSC.428(98), by contrast, applies to every company under the ISM Code, which means your fleet in service today. For an operator, the immediate issue is not class notation. It is ISM evidence.
3. Why maintenance is on the front line
Technical departments often assume this is an IT topic. It is the opposite: most of the expected evidence is generated by maintenance, not by head office.
The OT and IT asset inventory
No cyber programme survives without an inventory. You need to know what is on board, what it is connected to and which version it runs: PLCs, HMIs, power management systems, drives, engine control systems, ECDIS, radars, VDR, ballast systems, GMDSS, level and metering sensors. In practice the cyber inventory is simply an extension of your equipment register, with three extra columns: software or firmware version, network segment, criticality.
Patching and software versions on control systems
This is the most delicate point in ship operation: a patch applied without testing to a propulsion control system can create a greater risk than the vulnerability it fixes. Treat every update as a maintenance job in its own right — assessed request, chosen window (port call, drydocking), configuration backup beforehand, testing afterwards, a rollback option, and a record of the version before and after.
Third-party access and removable media
The service engineer's USB stick remains one of the most common incident vectors — along with the commissioning laptop, remote access opened "just for five minutes", and the service account left active after the contractor leaves. The expected controls are simple but must be written down: prior authorisation, virus scanning of media on a dedicated station, supervised connection, remote access closed at the end of the job, signed report. The logic mirrors permits to work and isolation in the engine room.
Logging, response, recovery and testing
Without a time-stamped record, nothing can be demonstrated: you must be able to say who worked on which system, when, using what media, with what result. That is the role of a digital engine log. Then comes the response plan — who isolates, who informs the office, how you revert to manual control — followed by a recovery plan built on backups that can actually be restored. A backup that has never been tested is not a backup; it is a hope.
4. What an owner or manager must document
- A cyber policy embedded in the SMS, with clear roles (owner, DPA, master, chief engineer, cyber focal point).
- A cyber risk assessment per ship type, covering loss of propulsion, loss of machinery control, loss of navigation and loss of communications.
- A CBS inventory per ship, kept current, with software versions and a network diagram.
- A patch and software change procedure, with approval before application.
- A third-party access procedure covering attending technicians, remote maintenance and removable media.
- An account and privilege matrix, reviewed at every crew change and every change of contractor.
- An incident response plan and a recovery plan, with documented degraded modes.
- A crew awareness programme, with training and drill records.
- The drill and test reports, including dated backup restoration tests.
- The supplier documentation required by UR E27 for ships in scope.
5. What a CMMS contributes to the demonstration
A CMMS does not "make you compliant". It does something better: it produces, at no extra effort, dated proof that procedures are actually applied — precisely what an ISM auditor or a class surveyor is looking for.
A digital asset register with firmware versions
Every item in the equipment database can carry its cyber attributes: maker, model, serial number, software version in service, date of last update, network, criticality, responsible officer. The inventory stops being a spreadsheet refreshed twice a year and becomes live data.
Work orders for software updates
A firmware update is planned like an overhaul: a work order triggered by due date or by event, with the procedure attached, mandatory "version before / version after" fields, attachments (release notes, supplier report) and an officer's sign-off. The maintenance module keeps the full history, including deferred jobs and the reason for deferral — often the first thing an auditor looks at.
Contractor traceability and privilege management
Every external intervention becomes a named work order: company, technician, systems touched, media used, remote access time window, outcome. On the people side, crew certificates and authorisations are managed with validity dates and alerts, which lets you show that an account was withdrawn when the holder signed off.
Backups, contingency procedures and fleet oversight
Restoration testing of controller configurations can be created as a recurring preventive task — six-monthly, for example — with a mandatory report. Contingency procedures (manual control, operating without the network) are attached to the relevant equipment, and a fleet dashboard lets the superintendent track overdue updates and missed tests. One point often overlooked: a mobile application that works offline stays usable even when the ship's network is deliberately isolated after an incident.
6. Requirement, expected evidence, where to produce it
| Requirement | Expected evidence | Where to produce it |
|---|---|---|
| Inventory of on-board computer-based systems | Dated register: equipment, maker, model, software version, network, criticality | CMMS equipment module, network diagram annexed to the SMS |
| Patch and version management | One work order per update: version before/after, operator, tests, rollback option | Maintenance module, work order linked to the equipment |
| Access and account control | Named account list, privileges, periodic review, withdrawal at sign-off | Crew module / authorisation management |
| Third-party technicians | Signed record: company, technician, systems touched, media, remote access duration | Contractor work order with attachments |
| Removable media | Register of approved media and proof of virus scanning before connection | SMS procedure plus checklist attached to the work order |
| Logging of interventions | Time-stamped, non-editable history of technical actions | Digital engine log / CMMS history |
| Backup and recovery | Configuration backups and a dated restoration test report | Recurring preventive task in the maintenance plan |
| Incident response plan | Procedure, roles, contacts, degraded modes, annual drill report | SMS plus archived and referenced drill report |
| Cyber resilience testing (UR E26) | Test procedure and reports at construction, commissioning and survey | Ship file, due dates tracked in the certificates module |
| Supplier documentation (UR E27) | Security capabilities, secure configuration guidelines, verification plan, test reports | Equipment technical file in the CMMS |
| Crew awareness | Attendance sheets, training content, dates, refreshed at each crew change | Training register linked to crew records |
Use this table as an internal audit template: for each line, ask who produces the evidence and how long it takes to retrieve it. Beyond five minutes, the arrangement will not stand up to a surveyor.
7. Good practice on board
- Segregate networks: navigation, machinery control, business and crew welfare must not share the same segment.
- Ban shared accounts on critical systems. One account, one person.
- Change default passwords at commissioning, including on yard-supplied equipment.
- Prohibit uncontrolled removable media and provide a dedicated station to scan visitors' drives.
- Close remote maintenance sessions at the end of each job, and record it.
- Back up configurations before any change, and keep an offline copy on board.
- Document degraded modes: manual control, paper navigation, backup communications.
- Run one cyber drill a year, on the same footing as a fire drill, and archive the report.
- Brief joiners on arrival, with a one-page card posted in the engine control room and on the bridge.
- Act on physical warnings: exposed USB ports, unlocked controller cabinets, unattended bridge workstations.
8. Questions to ask your software suppliers
Your CMMS, crew planning tool, reporting platform and telemetry solution are part of your exposure. Before signing, these seven questions are worth more than any sales deck. They complement the usual criteria for selecting a CMMS.
- Hosting: where is the data physically stored, in which country, with which provider, under which legal regime?
- Encryption: is data encrypted in transit and at rest? Who holds the keys?
- Authentication: is multi-factor authentication available? How are roles managed, and is account revocation immediate?
- Logging: is there a customer-visible audit trail showing who changed what and when, and for how long is it retained?
- Data portability: can you export all of your data at any time in an open format, without fees or artificial delay?
- Continuity: what is the backup policy, the target recovery time, and how does the ship work offline?
- Incidents: within what timeframe are you notified of a breach, and what is the contractual notification process?
A serious vendor answers these seven points in writing, without hedging. They are exactly the questions your auditors and charterers will put to you next.
FAQ
Do UR E26 and E27 apply to my existing ship?
Not on a mandatory basis: they apply to new ships contracted for construction on or after 1 July 2024. An owner may request voluntary application, and several classification societies offer cyber notations for ships in service. Resolution MSC.428(98), however, does apply to your existing fleet through the SMS.
What is the difference between UR E26 and UR E27?
UR E26 deals with cyber resilience of the ship as a whole: network architecture, system inventory, protection, detection, response, recovery and testing. UR E27 deals with each on-board system and item of equipment, placing obligations on makers and integrators regarding documentation, security capabilities and the secure development lifecycle of the delivered product.
Is cyber risk checked during an ISM audit?
Yes. An auditor can ask for the risk assessment, the associated procedures and, above all, the evidence of implementation: current inventory, traceable interventions, drill reports, training records. In practice it is producing that evidence, not writing the procedures, that causes difficulty.
Does the ship need to be permanently connected to be compliant?
No — the opposite, in fact: reducing unnecessary connectivity is one of the expected protective measures. What matters is controlling the connections you do have and being able to keep working when the network is isolated. A maintenance tool that runs offline and synchronises in port fits that constraint well.
What about a controller the maker no longer patches?
Document the case rather than ignore it. Record the obsolescence in the inventory, assess the residual risk, then apply compensating measures: network isolation, restricted physical access, disabling unused ports, enhanced monitoring, a dedicated spares holding and planned replacement at the next drydocking.
Is a CMMS enough to be compliant?
No. Compliance rests first on organisation, procedures and trained people. But a CMMS turns those intentions into verifiable items: a live inventory, dated work orders, an unalterable history, tracked authorisations. Without it, the demonstration relies on spreadsheets and emails, which rarely survives an audit.
Conclusion
Maritime cyber regulation is not one more IT project: it is an extension of work your teams already do. The IMO has required cyber risk in your SMS since 2021; IACS requires, for ships contracted from 1 July 2024, a verifiable level of cyber resilience at ship level (UR E26) and at equipment level (UR E27); and industry guidance published by BIMCO with some twenty organisations — version 5 of The Guidelines on Cyber Security Onboard Ships, released on 14 November 2024 — provides the operational manual.
The limiting factor is never writing the procedures. It is being able to prove, a year later, that they were applied on every ship. An equipment register enriched with software versions, work orders for updates, contractor traceability and tested backups: that is what makes the difference on audit day.
Want to see what a digital asset register and a software update work order actually look like in a CMMS built by seafarers? Book a demo or start a 30-day free trial on one of your ships. More than 400 vessels already use Smart Sailors to keep their maintenance — and their evidence — up to date.
.png){kind=small}
