IACS UR E26 and E27: The Cybersecurity Rules Singapore Ship Managers Are Quietly Getting Wrong

IACS UR E26 and E27 are mandatory cyber resilience requirements published by the International Association of Classification Societies. UR E26 covers the cyber resilience of ships as integrated platforms — design, integration, testing, recovery — while UR E27 covers individual onboard systems and equipment through a type-approval pathway. Both came into force on 1 July 2024 for new ships contracted on or after that date. For Singapore ship managers, the practical impact is not just on shipowners: because cyber risk management is part of the SMS under IMO MSC.428(98), the management company holding the Document of Compliance carries the operational responsibility class society surveyors press hardest during in-service audits.

Most ship managers in Singapore have not absorbed that last point. The rules were drafted in the language of ships and equipment; the audits are written in the language of management systems. Those two languages meet at the desk of the DPA — and that’s where the gaps are surfacing.

What IACS UR E26 and E27 actually require — in plain terms

IACS UR E26 (“Cyber Resilience of Ships”) and IACS UR E27 (“Cyber Resilience of On-Board Systems and Equipment”) translate IMO MSC.428(98)’s general cyber risk obligation into surveyable engineering standards. They split scope cleanly:

Both took effect on 1 July 2024. The first cohort of E26/E27 newbuilds entered service through 2024 and 2025, and by mid-2026 their first cyber-relevant surveys are starting. The class society community — DNV, Lloyd’s Register, ABS, Bureau Veritas, ClassNK, RINA — now operates with a shared cyber vocabulary that did not exist three years ago.

So what? If you took on management of any newbuild contracted from mid-2024 onwards, your first cyber-relevant in-service survey is imminent. The question is whether your SMS reflects what the ship actually does, and whether your software vendors can produce the evidence to prove it.

Where Singapore ship managers fit in — the DOC accountability nobody talks about

The Document of Compliance is the document the audit lives in. UR E26 names the ship; the SMS names the manager — and the two collide at the survey.

IMO MSC.428(98) has required cyber risk management in the safety management system since 1 January 2021. What is new is that IACS surveyors now walk onto the bridge with an E26-derived expectation of how cyber should be evidenced inside the SMS. They are not asking “do you have a policy?” They are asking, “show me the procedure that controls software changes on this vessel; show me the patch log; show me the last incident response drill report.”

Those questions land on the DPA and the technical superintendent. They do not land on the shipowner sitting in a different office in a different country, because the shipowner is not the entity holding the DOC.

The MPA Cybersecurity Code of Practice for Maritime sits underneath all of this as the local enforcement layer in Singapore. A Singapore ship manager controlling the SMS for a Singapore-flagged vessel sits at the intersection of three regulatory pressures — IMO, IACS, and MPA. The audit evidence has to satisfy all three.

So what? The question to ask in your next quarterly review is not “are our ships compliant with E26?” It is “is the SMS we hold the DOC for a credible reflection of the cyber posture of our managed fleet — and can we produce the artefacts to prove it?” If the answer is “we’d need to ask the owner,” the SMS is the wrong place for that answer to live.

The three quiet misunderstandings creeping into ship management practice

We see these in pre-survey reviews. They are common, they are reasonable, and they all produce findings.

“The vendor said it’s E26-compliant, so we’re covered.”

The most common misunderstanding, and the most dangerous. Type-approval under UR E27 covers the equipment as supplied — firmware version, network interface, security baseline at month zero. After delivery, three things happen outside the certificate: the system gets integrated into the ship’s broader network (E26 scope, integrator’s job to evidence); it gets configured for the operator’s workflows (passwords set, ports opened, accounts provisioned, rarely documented); and it gets patched, or doesn’t, over the months that follow.

The patch state at month 18 is what the surveyor sees, not the type-approval state at month zero. E26 is what your management company has to demonstrate. No single vendor can do that for you, no matter what the contract says.

“It only applies to newbuilds.”

Strictly true — E26 and E27 apply only to ships contracted from 1 July 2024 onwards. But existing ships remain fully in scope of IMO MSC.428(98), and the language surveyors now use to describe what good looks like under that resolution is the E26/E27 vocabulary. A surveyor visiting an older bulk carrier asks for “the network segmentation diagram” or “the recovery test record” and treats their absence as a finding under MSC.428(98). Treating the rules as “newbuild only” produces an internally inconsistent SMS, which is itself a finding waiting to happen.

“Our IT team handles cyber, the technical team handles class.”

The whole point of E26 is that this division is the problem. When cyber sits with IT and class sits with technical, the surveyor finds two filing cabinets that don’t match — the IT cabinet has last month’s vulnerability scan, the technical cabinet has maintenance records and SMS procedures, and neither has what the surveyor is actually asking for: a single integrated record of how cyber risk was identified, mitigated, monitored, and tested for this vessel over this audit period. The DPA owns the SMS, which makes the DPA the natural-person line of accountability for E26 alignment regardless of where the technical work physically sits.

So what? If your SMS section on cyber risk management is shorter than your section on planned maintenance, the gap is structural. Surveyors notice the asymmetry, and they read it as a signal that cyber has not been internalised by the management system.

The vendor responsibility matrix — who is on the hook for what

Print this. Bring it to your next vendor review meeting. The matrix below is opinionated — it is what we use in pre-survey reviews to map accountability under E26/E27 and to surface where contracts disagree with operational reality.

Two patterns stand out when ship managers walk through this with us. The SBOM and CVE log cells in the manager column are almost always empty, because nobody ever told them they were supposed to maintain a consolidated log across vendors. And the patch latency SLA is almost never in the contract — the vendor is not refusing to patch, they are simply not committed to a defined response time. A surveyor reading the contract sees that immediately.

So what? If two cells in your equivalent matrix are empty or undefined, you have your remediation list for the next quarter. They are not optional under E26.

What to ask your software vendors before the next survey

These questions map directly to the audit evidence E26 expects. The way a vendor answers — or dodges — tells you what your evidence pack will look like when the surveyor arrives.

1. Can you produce a written CVE log for the system as deployed on our vessels in the last 12 months, with patch dates, severity ratings, and per-vessel deployment status?
2. What is your committed patch latency for critical-severity vulnerabilities, in hours? Is that commitment in our contract, or only in marketing?
3. Do you maintain a current SBOM for the components delivered to us, including third-party libraries and open-source dependencies?
4. Who is your designated incident response point of contact, what is their response SLA, and when did we last run a joint incident response drill?
5. Have your systems been independently penetration tested in the last 12 months, and can we see the executive summary?
6. Is the software you supply developed in an ISO 27001-certified environment, and can you produce the certification documentation?
7. When you ship a new release to our vessels, what configuration changes are made, who authorises them, and how is the SMS change procedure invoked on our side?

A vendor who needs a week to produce the CVE log for the last quarter has just told you what your audit evidence will look like under pressure.

So what? Two of these produce the cleanest separation between vendors who are E26-ready and vendors who are E26-marketing: the patch latency SLA (question 2) and the joint incident response drill (question 4). If you can only ask two in a 30-minute review, ask those.

What this looks like in practice — a Singapore ship manager’s pre-survey discovery

A Singapore-based ship management company managing 30+ vessels engaged us late last year to prepare for a class survey on a 2024-built vessel. The DPA wanted a second pair of eyes on the software evidence pack.

What we found across three estates is illustrative rather than exceptional. The crew management vendor had no incident response plan and no out-of-hours point of contact; the contract referenced support hours but no security incident SLA. The planned maintenance system showed version skew across the fleet — half on release 4.2.1, a quarter on 4.1.7, the rest on 4.2.0, with two vessels still on 3.9. The bridge integrated navigation system held a type-approval certificate three firmware versions out of date; the integrator had updated firmware twice without re-issuing it, and nobody on the management side had noticed.

Resolution: re-baseline the SMS cyber annex against E26, produce a consolidated vendor evidence pack with a current CVE log and SBOM per system, align patch management to a single fleet release cadence, and re-coordinate with the integrator. MLTech Soft’s ISO 27001:2022-certified maintenance practice covered the patch logging, SBOM consolidation, and incident response artefacts; the SMS rewrite stayed with the DPA, because that is where it has to live. The survey passed without findings on the cyber annex.

None of these gaps would have shown up in a normal vendor management review. They surfaced because someone walked the evidence pack with a class auditor’s lens. That walk-through is the work.

FAQ: IACS UR E26 and E27 questions answered

Do IACS UR E26 and E27 apply to existing ships?

No, not directly. UR E26 and E27 apply to ships contracted on or after 1 July 2024. Existing ships remain in scope of IMO MSC.428(98), in force since January 2021. In practice, class surveyors are increasingly applying E26/E27 vocabulary during in-service surveys on older vessels — treating the absence of an E26-style artefact as a finding under MSC.428(98). For Singapore ship managers with mixed fleets, the practical bar is converging across newbuilds and existing ships.

What evidence does a class surveyor expect for E26 compliance?

Evidence that the SMS operates a cyber risk management process, not just a cyber policy. Typically: a current network architecture diagram with segmentation, an SBOM per system, a CVE log with patch status, a documented change management procedure for software updates onboard, a written incident response procedure with a tested point of contact, recovery test records, and audit trail entries showing the SMS has actively reviewed cyber risk over the audit period. Depth scales with the vessel’s risk profile.

Who is responsible for cyber compliance — the shipowner or the ship manager?

Both, but the audit evidence presses hardest on the ship manager. The shipowner bears the commercial consequence of a finding, but the management company holding the DOC operates the SMS — and the SMS is where cyber risk management lives under IMO MSC.428(98). The DPA carries the operational accountability when the surveyor walks aboard. Software vendors carry their slice through type-approval evidence, SBOMs, and patch SLAs, but they do not own the SMS.

How does Singapore’s MPA Cybersecurity Code of Practice for Maritime interact with IACS E26?

The MPA Code is the local enforcement layer underneath IMO and IACS expectations for vessels connected to Singapore’s maritime infrastructure. An SMS that satisfies E26’s evidence expectations will largely satisfy the MPA Code, because the MPA framework was designed to be coherent with IMO and IACS guidance. The exception is locally-specific obligations — incident reporting timelines to MPA, integration with Singapore’s national cyber response framework — which sit on top of the international baseline.

What to do this quarter

E26 and E27 are not abstract regulations any more. The first generation of vessels built under them is in service, surveyors are asking the new questions, and evidence expectations on existing vessels under MSC.428(98) are climbing in parallel.

The work this quarter is unglamorous and concrete: walk the vendor responsibility matrix; ask the seven questions of every software vendor running on a managed vessel; map the gaps to specific SMS clauses; and decide which gaps close in 90 days versus which sit on a remediation roadmap. The patch latency SLA usually closes fastest — it’s a contract change, not a technical one. Incident response takes longest, because it has to be tested, not just written.

If you’d like a second pair of eyes on the evidence pack before your next survey — particularly on a vessel built or contracted after mid-2024 — MLTech Soft offers a free 1-hour pre-survey software review. We work through your SMS cyber annex, the vendor SBOMs and patch logs, and the questions a class surveyor is most likely to ask, and produce a written gap list you can close before the surveyor arrives. Book your pre-survey review →