Smart Marine Consultant (3/4): What I See. What I Solve. What Stays Broken.
The Gap Nobody Talks About
In Part 2, I mapped the five stages of a smart ship project — from contract signing to delivery. That map is the theory.
This is the field record.
Every project I've worked on has a gap between what the documentation says and what actually exists on the vessel. Sometimes it's small. Sometimes it's wide enough to fail a survey. Always, it's the result of decisions made under pressure, at speed, without someone whose job it was to catch the drift.
What follows is a categorized account of what I actually encounter — the patterns, the fixes, and the problems that don't get fixed. Names and vessel details are anonymized. The patterns are real.
What I See
The Computer-Based System inventory is the foundation of IACS UR E26 compliance. It lists every system in scope, its classification, its zone, its interfaces, and its supplier documentation status.
In theory, it's a living document maintained throughout the project.
In practice, I find CBS inventories that were created during detailed design and never updated. Systems added during construction — a remote monitoring terminal here, a fleet management gateway there — that appear nowhere in the document. Software versions that changed after the inventory was locked.
The inventory describes the ship that was planned. The ship that was built is different.
Every project. Without exception.
The security zone diagram is one of the core IACS UR E26 deliverables. It defines how onboard systems are segmented — which systems can talk to each other, which are isolated, which have controlled interfaces to external networks.
What I find on the actual network: cables that cross zone boundaries without documented justification. Switches configured for convenience, not security. Remote access paths that were added by equipment suppliers during commissioning and never formally documented or approved.
The zone diagram shows a clean segmented architecture. The network shows a flat topology with exceptions layered on top of exceptions.
Equipment manufacturers who require network access for remote diagnostics or warranty support, and who install that access without going through the change management process. Nobody stopped them because nobody was watching.
IACS UR E27 requires each Computer-Based System to be supported by cybersecurity documentation — software version records, patch management procedures, remote access controls, secure development lifecycle evidence.
What I find: PDF documents labeled "Cybersecurity Declaration" that contain one page of general statements and no specific technical content. Patch management procedures that describe a process the supplier has never actually run. Remote access policies that reference a VPN that doesn't exist.
The documentation was created to satisfy a procurement checklist. It was not created to describe how the system actually works.
Suppliers who are asked for cybersecurity documentation for the first time, with no guidance on what it should contain, under a deadline that makes real analysis impossible.
The Vessel Cyber Security Plan is the master document — the shipowner's operating manual for cybersecurity on the vessel. It covers security policies, incident response procedures, crew responsibilities, and the maintenance regime for all CBS.
What I find: VCSPs written during detailed design, submitted to the class society, approved — and then never updated as the ship changed around them. The VCSP references systems that were removed. It doesn't mention systems that were added. The incident response procedure names a shore-side contact who left the company.
The document was written for compliance. It was not written for use.
The VCSP is treated as a design deliverable, not an operational document. Once approved, nobody owns it.
This one is not a documentation problem. It's a human problem.
The crew operating the vessel — the Master, the Chief Engineer, the officers responsible for IT and OT systems — are often unaware that the VCSP exists, let alone what it requires of them. Cybersecurity training completed during onboarding was generic IT security awareness, not vessel-specific operational procedure.
When I ask a Chief Engineer what the procedure is for a suspected cyber incident on the ship, the answer is usually: call the company. Which company? The IT department ashore. What's the number? Uncertain.
Cybersecurity is treated as a shore-side compliance function. The vessel is the place where compliance is documented — not the place where security actually needs to work.
What I Solve
Not everything stays broken. These are the problems I can fix — and how.
When the inventory doesn't match reality, the only solution is a physical walkthrough. Every compartment. Every panel. Every network connection. Cross-referenced against the design documentation, the as-built drawings, and the installed equipment list.
It takes time. On a complex vessel, it takes days. But the result is a CBS inventory that reflects what the ship actually is — which is the only inventory worth having.
Updated CBS inventory with a documented delta between the original design and the as-built condition, with each change assessed for E26 compliance impact.
A zone diagram is a drawing. The network is reality. The only way to validate one against the other is to map the live network — what is connected to what, what traffic flows between segments, what remote access paths exist.
This requires network scanning tools appropriate for OT environments — passive where possible, to avoid disrupting safety-critical systems. It requires understanding the difference between a legitimate cross-zone interface with a documented firewall rule and an undocumented bridge that exists because a technician needed it once.
Validated zone diagram that reflects the live network, with a nonconformity register for items that require remediation or formal justification.
Forty suppliers. Forty documentation packages of varying quality. Three months to delivery.
The only workable approach is triage: classify each supplier's documentation as compliant, conditionally compliant (gap identified, remediation plan agreed), or noncompliant (requires escalation). Focus remediation effort on the systems with the highest risk classification and the widest documentation gaps.
Some gaps can be closed by the supplier with guidance. Some require formal acceptance by the shipowner and class society as a documented risk. Some require renegotiating the supplier contract.
Supplier documentation status register, a prioritized remediation plan, and a formal risk acceptance record for items that cannot be fully remediated before delivery.
A VCSP that nobody reads is not a security plan. It's a compliance artifact.
Making it operational means: stripping out the boilerplate, rewriting the procedures in language that a watch officer can follow at 0200 in a storm, adding vessel-specific contact lists that are actually current, and embedding the document into the crew onboarding process so that every new officer knows it exists and knows their role in it.
It also means building a review cycle — a scheduled annual update process tied to the vessel's ISM audit — so the document stays current as the ship and the crew change.
Operational VCSP that the crew has been trained on, with a documented review and update process.
What Stays Broken
Not everything can be fixed. These are the problems I walk away from.
Maritime cybersecurity sits between functions that don't naturally talk to each other. The shipyard owns design compliance. The shipowner owns operational compliance. The equipment supplier owns system compliance. The CRSI is supposed to integrate all three — but the CRSI role ends at delivery.
After delivery, nobody has a mandate to maintain the full picture. The DPA owns the SMS. The IT department owns the network. The technical superintendent owns the equipment. The VCSP is in a folder somewhere.
Until the industry develops clear ownership models for in-service vessel cybersecurity — with named roles, defined responsibilities, and audit accountability — this gap will remain. Regulation can define what must be documented. It cannot, by itself, define who is responsible for keeping it true.
IACS UR E26 and E27 apply to newbuilds contracted from July 2024. The existing fleet — thousands of vessels currently operating — has no mandatory retrofit requirement.
Those vessels have OT systems that were designed before cybersecurity was a consideration. They have network topologies that were never mapped. They have remote access paths that have accumulated over years of maintenance visits.
Some shipowners are addressing this voluntarily. Most are not, because the commercial case is unclear and the regulatory pressure is absent. The result is a global fleet where the attack surface is large, the visibility is low, and the incident response capability is minimal. This is not a problem a Smart Marine Consultant can solve on one vessel. It requires regulatory movement, insurance pressure, and industry-wide commitment that does not yet exist at scale.
Technology can be documented. Procedures can be written. Training can be delivered.
What cannot be engineered away is the human tendency to prioritize operational continuity over security hygiene. The officer who disables a firewall rule because a critical system is throwing alerts. The technician who plugs a personal laptop into the OT network because it's faster than using the designated maintenance terminal. The superintendent who approves a software update from a USB drive because the vendor's remote access portal is down.
Every one of these decisions is understandable in its context. Every one of them creates a vulnerability that the most carefully written VCSP cannot prevent.
The only answer is a security culture — a shared understanding across the vessel and the shore organization that security is everyone's job, not a function of the compliance team. Building that culture takes years. It cannot be installed at commissioning.
Documentation that describes intention, not reality. The gap between design and as-built is normal in shipbuilding. In cybersecurity, that gap is a compliance and operational risk that must be actively managed.
A supply chain that is not ready. Equipment suppliers are at very different levels of E27 maturity. The weakest link in the CBS inventory is the weakest link in the vessel's security posture.
An ownership model that ends at delivery. The work done to achieve commissioning survey compliance does not automatically translate into in-service security. Someone needs to own that transition — and right now, that ownership is usually unclear.
A human layer that no document can replace. Procedures are necessary. They are not sufficient. Security depends on people understanding why the procedures exist and having the authority to follow them even when it is inconvenient.
Comments
Post a Comment