IACS UR E26/E27: Two Years of Survey Practice — A Class Surveyor's Inside View
Class survey is shifting its centre of gravity from verifying physical objects to verifying system behaviour.
※ This article reflects the author's personal experience and views, and does not represent the official position of any classification society. All examples have been generalized and reconstructed so that no specific project can be identified.
Introduction — "Who Actually Reviews This Diagram?"
In the second half of 2024, just after IACS UR E26/E27 entered into force, this was the question I heard most often from shipyard design engineers: "We are told to submit a Zones and Conduits Diagram — but who at the classification society reviews it, and against what criteria?"
To be honest, at the time we were still building the answer ourselves. The URs, first published in April 2022 and later superseded by revised versions incorporating industry feedback, apply to ships contracted for construction on or after 1 July 2024. Two years have now passed. This article is not another clause-by-clause explainer. Instead, it looks at how survey practice inside classification societies has actually changed over those two years, from a surveyor's point of view. There is no shortage of guidance addressed to equipment suppliers and shipyards. What the "reviewing side" has gone through — and what has genuinely settled into routine — is far less visible.
 |
1. A New Shelf in the Plan Approval Office
The first place to change — and the quietest — was Plan Approval.
Before UR E26/E27, class plan approval revolved around physical systems: hull, machinery, electrical. Today, every newbuilding project arrives with a set of cyber deliverables on the formal submission list: the Zones and Conduits Diagram, the Vessel Asset Inventory, the Cyber Security Design Description (CSDD), and the Ship Cyber Resilience Test Procedure. Documents that were initially treated as "reference material" have become critical-path deliverables — nothing moves forward without their approval.
The change in review practice is even more telling. In the early months, review was essentially a check that the documents existed. Two years on, it looks quite different:
- Zone boundaries are cross-checked against the actual network configuration — switches, firewalls, serial-to-Ethernet conversion points — using wiring diagrams and system drawings.
- The Vessel Asset Inventory is reconciled against the UR E27 Type Approval status of listed equipment and against the shipyard's purchasing specifications. Mismatches here are still far from rare.
- For every security capability stated in the CSDD, reviewers now ask whether it is a "manufacturer's catalogue phrase" or an "actually configured setting" — and raise comments accordingly.
2. The Competency Map of the Surveyor Profession Is Being Redrawn
The second change is about people.
The traditional class surveyor comes from naval architecture, marine engineering, or navigation. UR E26/E27, however, brought the language of cybersecurity — security capabilities, access control, network segmentation, patch management — onto the survey scene. In the first months, this showed most clearly in Plan Approval: cyber deliverables were a document type the review desks had simply never handled, and early reviews were, frankly, slow and difficult.
That bottleneck has largely been cleared. Societies invested in internal training and — just as importantly — recruited and reinforced dedicated cybersecurity specialists within their plan approval organizations. Two years on, reviewing UR E26 deliverables and UR E27 Type Approval documentation is no longer a struggle; it has become a routine, properly staffed function, and plan approval itself now proceeds without particular difficulty.
The honest remaining concern sits elsewhere: on board. Attending surveyors — whose professional formation is hull, machinery, and electrical — still find it demanding to verify cyber items at the quay and during trials: reading a network diagram against the physical installation, or judging whether a witnessed test genuinely demonstrates what the procedure claims. This is the part of the transition that is still under way. But the direction is clear — OT network fundamentals have entered the surveyor training curriculum, standardized checklists and test procedures are maturing, and experience is accumulating survey by survey. The gap on board is real, but it is closing; I see it as a matter of time rather than a structural flaw.
3. FAT and Commissioning — From Document Checks to Demonstrated Testing
The third change is in the act of surveying itself.
UR E26 requires a Cyber Resilience Test Procedure spanning construction, commissioning, and the vessel's operational life. In the early days, the cyber items at FAT (Factory Acceptance Test) witnessing were, frankly, a formality — little more than signing the relevant page of the test procedure.
Not anymore. A few examples of what is actually performed at recent witness surveys:
- Verifying on the physical equipment that unused ports — physical and logical — are deactivated as stated in the procedure.
- Confirming that default credentials have been changed and that role-based access separation exists as configured settings, not just as text.
- Witnessing scenario tests of fail-safe behaviour: whether essential functions are maintained under network failure or abnormal traffic conditions.
- Requiring a live demonstration that backup and restore procedures actually work, rather than accepting them on paper.
There is one situation surveyors encounter over and over: the case where "the documents are perfect, but the ship is different." A temporary bridge connection that does not appear on the approved Zones and Conduits Diagram; a remote access path left open for commissioning convenience; an undocumented laptop connection point. These come not from malice but from the inertia of the construction site. This is why recent practice has converged on a simple habit: not "document review here, physical inspection there," but walking on board with the approved diagram in hand.
4. UR E27 Type Approval — From Bottleneck to Market Order
For UR E27, the past two years can be summarized in two words: congestion, then relief.
Immediately after entry into force, Type Approved equipment was scarce. Shipyards could not find approved products, suppliers did not know what to prepare, and Type Approval queues built up at class review desks. In that first year, the recurring problem was rarely technical capability — it was documentation. Security capabilities were often genuinely implemented, but the test reports to demonstrate them did not exist; secure development lifecycle (SDLC) practices existed on the shop floor but had never been written down.
5. Divergent Interpretations Between Societies — and Convergence
One of the hardest things for shipyards and owners in the early period was that requirement levels differed subtly from one classification society to another. The same UR, yet one society demanded a particular template while another accepted alternative supporting evidence in lieu. For this reason, even stranger is the fact that some equipment manufacturers hold both an exemption statement and an E27 type approval certificate.
I would call this less an embarrassment than an inevitable rite of passage for any new regulation. Over two years, as question-and-answer cases accumulated and IACS-level clarifications and individual societies' guideline revisions followed, the spread has clearly narrowed. The change I feel most directly: in meetings with shipyard engineers, we now spend less time arguing "is this really a requirement" and more time discussing "how will you demonstrate it." That is what a maturing regulation sounds like.
6. Blind Spots Emerging at Delivery — Owner-Supplied CBS and the Interface Grey Zone
As of 2026, the first generation of UR E26 ships is only now beginning to be delivered. And as delivery surveys get underway, a problem that was invisible at the plan approval stage is surfacing at the quay: the boundary of applicability — specifically, the grey zone around owner-supplied Computer Based Systems (CBS).
A newbuilding carries a fair number of systems procured directly by the owner, outside the shipbuilding contract: performance monitoring systems, fleet management solutions, communication and satellite equipment, cargo-specific systems. The problem is that these systems occupy an awkward position in the UR E26 deliverable structure. On survey, we repeatedly find them either excluded from the shipyard's Vessel Asset Inventory and Zones and Conduits Diagram altogether, or dismissed with a single annotation: "Owner's Scope."
If these systems stood alone, the issue would be simple. They do not. Owner-supplied systems ultimately interface with the shipboard network — pulling navigation data, collecting machinery data, sometimes touching control systems. The moment they connect, the approved zone boundaries and security architecture are disturbed. And the contract contains no answer to who designs, and who demonstrates, the cyber resilience of that connection point.
At delivery surveys, this plays out as a classic three-way standoff. The shipyard says: "outside our supply scope, therefore outside our deliverables and our test scope." The owner says: "integration is the shipyard's job." And the classification society is not a party to either contract — it must verify the cyber resilience of the ship as a whole. A structural mismatch — the regulation is written per ship, while responsibility is split per contract — and this is precisely the part that currently remains unresolved between class and shipyard on multiple projects, often surfacing only just before delivery and being patched over under schedule pressure, sometimes ending in outstanding items or conditional arrangements.
What I can say as a surveyor is this: the grey zone will not be closed by regulatory interpretation. It will be closed only when integration, documentation, and testing responsibility for owner-supplied CBS is explicitly allocated at the contract stage. A project whose shipbuilding contract and owner-supply purchase specifications contain no UR E26/E27 responsibility clauses is very likely to relive this same conflict at delivery.
7. When the System Integrator Is the Shipyard — Concerns Over an Expertise Gap
Intertwined with the grey zone is another structural issue. The UR E26 framework presupposes a System Integrator (SI) — a role responsible for designing and demonstrating the cyber resilience of the ship as a whole. In practice, on a majority of newbuilding projects, this role is taken not by a specialist integration firm but by the shipyard itself.
Shipyard design and production organizations are world-class shipbuilding engineering organizations — but they are not cybersecurity organizations. The gap shows up in two places: the deliverables, and the test floor.
First, document quality. The CSDD and the integrated test procedures the shipyard must produce as SI too often amount to a compilation of the documents submitted by individual equipment suppliers. Each system-level document stands on its own — but the ship-level security architecture that should run through them, such as how inter-zone communication is governed overall or how trust relationships between systems are designed, is described nowhere. The reviewer is handed a document in which the sum of the parts never becomes a whole.
Second, inexperienced test execution. Integration-level cyber resilience testing requires personnel who understand the purpose of each test item and can design and run the scenarios. What we encounter at witness surveys instead: test setups not prepared, leaving the attendance idle; test operators following the procedure text keystroke by keystroke without being able to explain what the result means; failed items simply retested repeatedly with no root-cause analysis in between. This is not a failing of individuals. It is the failing of a structure that assigns the SI role without the specialist staffing and organization the role demands.
To be fair, not every shipyard fits this description. Some have stood up dedicated teams and brought in external specialists, raising their game quickly. Across the industry as a whole, however, the gap between the customary arrangement of "SI = shipyard" and the cyber expertise the SI role actually requires has not yet been closed — and there is growing concern that this gap will translate into variance in delivery quality. Whether shipyards internalize this capability or establish a working collaboration model with specialist SIs is one of the key things to watch in the newbuilding market over the next two to three years.
8. Remaining Homework — A Surveyor's List
Beyond the grey zone and the SI capability gap discussed above, several unresolved items remain visible from the field.
First, boundary questions. Projects sitting at the edge of the applicable ship types and sizes, and practical enquiries around the contract-date criterion, keep coming. How far the new requirements should reach in conversions and retrofits of existing ships is a question we will face more and more often.
Second, people. Across the entire industry, professionals who understand both OT and cybersecurity are in short supply. This bottleneck belongs to shipyards, equipment suppliers, and shipowners as much as to class — and, paradoxically, it is the single clearest opportunity for engineers looking to enter the maritime sector today.
Closing — The Nature of the Survey Itself Is Changing
If the past two years had to be compressed into one sentence, it would be this: class survey is shifting its centre of gravity from verifying physical objects to verifying system behaviour.
Steel plate thickness is settled the moment it is measured. Cyber resilience is not a property fixed at delivery — it is a state that must be maintained across the vessel's entire life. UR E26/E27 was the first attempt to translate that state into something surveyable, and the past two years have been about making that translation actually work — in the plan approval office, on the quay, and in the engine room.
We are not at the finished form yet. With the first generation of ships having Cyber Resilience as per IACS UR E26/27 only now being delivered, the grey zone around owner-supplied systems and the SI expertise gap remaining homework to be solved on the quay, not in regulatory text. And yet: an industry that two years ago asked "who actually reviews this diagram?" now trades a far sharper question — "under which contract does the integration responsibility for this system sit?" The questions have levelled up. As a surveyor, I believe that is the biggest change of the past two years.
One further thought to close. Technology is advancing day by day, and it is reasonable to expect that UR E26 and E27 themselves will be revised again to keep pace with it. But writing a regulation is never the end of the story. Only when every stakeholder — classification society, shipyard, equipment supplier, and shipowner — cooperates with one another and works together to eliminate the blind spots between them will the true cyber resilience of the ship actually be achieved. That, I believe, is the real work now ahead of all of us.
Grateful for the time and attention you've given this article.
18+ years in ship electrical engineering, spanning shipyard design and classification society plan approval, testing, and type approval — including two years reviewing IACS UR E26/E27 cyber resilience deliverables from inside a classification society.
⚓ Join the ShipPaulJobs Community
Join →
As someone working in the maritime industry, I found this to be a particularly insightful perspective from a professional
ReplyDeleteFor those of us involved in CRSI, both companies and practitioners, these kinds of first-hand insights are extremely meaningful. They help us understand not only what IACS UR E26/E27 requires, but also how those requirements are actually being reviewed and interpreted in practice.
The shift from checking whether documents exist to looking at their consistency and the actual behaviour of systems is especially important.
I believe insights like this can help raise the practical quality of maritime cyber resilience across the industry.
First, I would like to express my sincere appreciation to Mr. Kyu-Oh Choi for openly sharing how classification review and onboard survey practices have evolved since IACS UR E26/E27 entered into force. While many publications explain how shipyards and equipment suppliers should respond to these requirements, opportunities to hear directly from those who review the submitted designs and evidence remain rare. This makes the article particularly valuable.
ReplyDeleteAs a CRSI consultant who has encountered and considered many of these challenges in practice, three points resonated with me in particular.
First, the focus of classification review is shifting from the mere existence of documents to consistency between the documents and the actual systems. Producing a Vessel Asset Inventory, Zones and Conduits Diagram, CSDD, and Test Procedure as separate, well-prepared deliverables is no longer sufficient. The equipment actually purchased and installed, its security configurations, and the test results must all align to demonstrate the vessel’s cyber resilience.
Second, owner-supplied CBSs are becoming a significant gap in responsibility. Even if a system is contractually within the owner’s scope of supply, it affects the vessel’s overall security architecture as soon as it connects to the onboard network. Unless responsibility for integration design, documentation, security configuration, and testing is defined at the contract and procurement-specification stages, the issue may emerge shortly before delivery as a dispute among the shipyard, shipowner, and classification society.
Third, there remains a gap between the practical assumption that the shipyard acts as the System Integrator and the cybersecurity integration capabilities that this role actually requires. Simply compiling documents submitted by multiple equipment suppliers does not create a ship-level CSDD. The security capabilities of individual systems must be connected to inter-zone communication controls, remote access, account management, incident response, and recovery arrangements—and then explained and tested as an integrated vessel-level security architecture.
These are also issues I have continued to consider through my own work. Ultimately, the CRSI’s role should extend beyond preparing deliverables or organizing supplier documentation. A CRSI must maintain consistency and traceability across requirements, design, procurement, installation, configuration, and testing, while identifying gaps in responsibility among the shipyard, shipowner, and equipment suppliers at an early stage.
This article allowed me to reconfirm, from a classification society’s perspective, the direction I have been pursuing in practice. I believe a capable CRSI consultant is not simply someone who prepares documents to avoid class comments. Rather, the CRSI should help ensure that the cyber resilience the classification society seeks to verify is genuinely implemented and demonstrable on the actual vessel. Once again, I sincerely appreciate the author for sharing such valuable experience and insight.