[IACS UR E26/E27 Audits] What Classification Societies Actually Verify — And Why Projects Get Delayed
What Classification Societies Actually Verify in IACS UR E26/E27 Audits — And Why Projects Get Delayed
Class doesn't just check documents. It validates the structural logic behind your entire cyber architecture — and most projects aren't ready for that.
- LinkedIn : https://www.linkedin.com/in/shipjobs/
Collaborator : Lew, Julius, Jin, Morgan, Yeon
A common belief in the shipbuilding industry is that classification societies only check submitted documents. In reality, IACS UR E26 and UR E27 audits go far beyond document review — they validate the structural logic of the entire vessel's cyber architecture. This article explains exactly what Class verifies at each stage, and why most project delays are caused by document inconsistency and the absence of a systems integrator, not by Class itself.
Ⅰ. The Biggest Misconception: "Class Only Checks the Forms"
Many shipyards and suppliers say the same thing: "Isn't Class just checking the documents we submit?" or "Doesn't E26/E27 just require the right format?"
In practice, the Class review process is a structural validation that goes well beyond document review. Class is not simply reading documents — it is verifying:
- System architecture and interface definitions
- Network flow and zone-to-zone traffic paths
- Risk impact flow (Impact Flow) across the vessel
- Cross-document consistency between E26, E27, ZCD, and SCARP
- Resilience architecture for operational continuity
E26/E27 is not a form to fill in. It is a model to build. Class is verifying whether your model is coherent — not whether your spreadsheet is complete.
Ⅱ. What Class Checks First: Boundary Definition
The first and most critical step in every Class review is the Boundary definition. Without a clearly defined boundary, every other document loses its foundation.
Boundary is the reference baseline for all of the following:
Ⅲ. What Class Checks Second: Logical Consistency of Zone & Conduit Design (ZCD)
Class scrutinizes the Zone & Conduit Design (ZCD) with particular attention. The ZCD is the architectural map that visually represents the vessel's entire cyber structure — and it must be internally consistent and match every other document in the package.
The most commonly flagged ZCD problems during Class review:
ZCD is not a document to fill in — it is a design to be engineered. Very few organizations are capable of designing it correctly. This is precisely where the need for a Cyber Resilience System Integrator (CRSI) becomes critical.
Ⅳ. What Class Checks Third: The Impact Logic of RA/RM
Class does not view Risk Assessment and Risk Management (RA/RM) as a table to be populated. What they are actually looking for is the flow of risk impact across the vessel.
- Where does the risk originate? (Origin)
- Which zones does it travel through? (Propagation)
- Which conduits enable its spread? (Vector)
- What is the ultimate impact? (Impact Sink)
- How does it affect ship safety or the environment?
When suppliers produce RA/RM in isolation, Class flags it almost 100% of the time. The reason is simple:
Suppliers cannot know the overall system architecture and zone model — so their impact flow analysis is necessarily incomplete.
Ⅴ. What Class Checks Fourth: E27 and SCARP Consistency
The single most common comment in Class audits is: "E27 and SCARP are not consistent."
Specific inconsistencies Class identifies:
The root cause is simple: suppliers (E27) and shipyards (design) produce documents independently, and they are simply combined without a CRSI to integrate them. SCARP must be constructed by integrating supplier E27 documentation with shipyard design — and most projects have no one performing that integration role.
Ⅵ. What Class Checks Fifth: Operational Maintainability
Class also asks a forward-looking question: "Will this actually work during vessel operations?" Documents that cannot be maintained or executed in an operational context are not accepted as compliant.
Is a practical patch management process defined and executable?
Can logs actually be collected and reviewed during operations?
Can access controls be changed when needed?
Are backup and recovery procedures realistically executable?
Is the Management of Change process realistic for operations?
Is the incident response process actually executable at sea?
E26/E27 documentation is not a submission artefact — it must be sustainable through the entire operational lifecycle. Neither supplier nor shipyard documents alone can achieve this.
Ⅶ. Three Things Class Will Always Reject
Across all Class societies reviewing IACS UR E26/E27 compliance, three situations consistently result in immediate rejection or re-submission:
Nearly 100% comment rate. If the Boundary defined in E26 does not match the ZCD architecture diagram, the entire document package is questioned.
Class treats this as "Inconsistency." SCARP must integrate and synthesize E27 content within the vessel-level architecture — not simply aggregate it.
Immediately rejected as "No justification." Risk assessments must trace actual impact flows through zones and conduits — not describe risks in abstract terms.
Ⅷ. Why Class Approval Gets Delayed: The Four Root Causes
Project delays in UR E26/E27 approval are almost always attributable to four root causes — none of which are caused by Class itself.
Supplier-produced E27 documents are not reconciled with the shipyard's network and zone architecture
The three core documents describe different architectures — each produced independently without cross-validation
The system scope is incorrectly defined from the start, causing cascading errors in all downstream documents
MOC (Management of Change) events during construction are not updated in cybersecurity documentation
Delays are not caused by Class being strict. They are caused by absent document integration and the absence of a CRSI role to maintain consistency across stakeholders.
Conclusion: Class Is Not a Document Checker — It Is a Structure Validator
UR E26/E27 approval is not a document submission process. It is a verification of the entire vessel's cyber architecture — and it requires three things to pass quickly, accurately, and reliably:
Owner Policy + CRSI + Consistent SCARP = Fast, reliable Class approval
No integrator + fragmented documents = Repeated comments, project delays, cost overruns
Key Takeaways
Not just documents — Class verifies architecture consistency, impact logic, and operational feasibility across the entire vessel
Zone & Conduit Design is not a form to fill in — it is the architectural map of the vessel's cyber structure and must be engineered
Boundary → ZCD → RA/RM → E27 → SCARP must form a single coherent model — any break in the chain results in rejection
Most approval delays trace back to the absence of a CRSI — not to Class being strict or documentation being complex
Maritime professional focused on the intersection of vessel operations, classification society regulations, and OT/IT cybersecurity. Writing for engineers, consultants, and operators navigating Maritime 4.0 together.
🌐 More Articles ↗
Comments
Post a Comment