Article 1 : The Cyber Resilience System Integrator and the Six Core Ship-Level Deliverables
The Cyber Resilience System Integrator and the Six Core Ship-Level Deliverables
Building a verified baseline for vessel delivery, operational maintenance and the survey cycle
IACS UR E26 requires more than the collection of individual equipment certificates. Ship-level cyber resilience depends on coordinated scope determination, supplier integration, security architecture, controlled change, as-built verification and a handover baseline that the Shipowner can maintain throughout the vessel's operational life.
Vessel delivery is a responsibility transition point, not the end of cyber-resilience management. The Systems Integrator establishes and verifies the pre-delivery baseline; the Shipowner/Company maintains that baseline and demonstrates continued implementation during the operational survey cycle.
IACS UR E26 uses the defined term Systems Integrator. In this series, Cyber Resilience System Integrator, or CRSI, refers to a specialist organization appointed to perform the cyber-resilience aspects of the IACS Systems Integrator function and, where separately assigned by the Shipowner, to support lifecycle assurance after vessel delivery.
CRSI is not presented as a separate IACS stakeholder category, certification or mandatory service provider. Formal responsibilities remain subject to the applicable IACS Unified Requirements, the Rules and instructions of the relevant Classification Society, the project specification, the contractual relationship with the Society and any express appointment by the Shipyard or Shipowner.
1. Why a Lifecycle-Oriented Systems Integrator Is Needed
IACS UR E26 addresses the ship as a collective entity for cyber resilience, while IACS UR E27 establishes minimum cyber-resilience requirements for individual on-board systems and equipment. For vessels within its scope, UR E26 Rev.1 is uniformly applicable to ships contracted for construction on or after 1 July 2024.
Compliance therefore cannot be demonstrated only by confirming that individual items of equipment possess suitable security capabilities. The vessel must also have a coherent and controlled ship-level architecture addressing:
- the Computer Based Systems, or CBSs, within the UR E26 scope;
- the integration of supplier systems into the vessel;
- the hardware, software and network baseline;
- security-zone allocation and conduit design;
- communication within and between zones;
- connections to untrusted networks;
- missing security capabilities and compensating measures;
- exclusions and their risk basis;
- verification of the final installed configuration; and
- maintenance of the approved baseline after delivery.
No individual CBS Supplier normally has complete visibility of the vessel-wide architecture. Each Supplier can describe its own system, interfaces, software, security capabilities and limitations. Those inputs must be reconciled into one integrated ship-level design. That integration function is assigned to the Systems Integrator.
A CRSI performs the cyber-resilience scope of this integration. Its purpose is not merely to assemble supplier files or prepare drawings for Class submission. It converts supplier-level information into a complete, consistent, verifiable and maintainable vessel cyber-resilience baseline.
This lifecycle perspective is consistent with IACS Recommendation 166, which frames the design and construction objective as the delivery of cyber-resilient ships whose resilience can be maintained throughout their lifecycle.
2. The IACS Systems Integrator and the CRSI Role
2.1 The IACS-Defined Systems Integrator
IACS UR E26 defines the Systems Integrator as the person or organization responsible for integrating systems and products supplied by multiple Suppliers into the system required by the ship specification and for providing the integrated system. Unless another organization has been specifically contracted or assigned, the Shipyard performs this role until vessel delivery.
IACS UR E22 provides a broader lifecycle definition. It describes the Systems Integrator as the organization or person coordinating interaction among system and subsystem Suppliers throughout the lifecycle of computer-based systems, integrating them into a verified vessel-wide system of systems and supporting proper operation and maintenance. UR E22 also identifies the Shipyard as the default Systems Integrator during design and delivery and the Owner as the default Systems Integrator during operation.
2.2 The CRSI as the Cyber-Resilience Integration Function
A CRSI may be the formally appointed Systems Integrator, or it may operate under the governance of the Shipyard acting as Systems Integrator. The role should be expressly defined because technical analysis or document preparation does not, by itself, transfer formal Systems Integrator responsibility.
At project commencement, the following matters should be established:
- which organization is the formal Systems Integrator;
- whether the CRSI acts as the Systems Integrator or as its specialist adviser;
- who has authority to make vessel-level design decisions;
- who is responsible for Supplier engagement and information closure;
- who submits documents to the Classification Society and responds to comments;
- who approves zone, conduit, exclusion and compensating-measure decisions;
- who controls construction changes; and
- who signs off the final as-built baseline.
IACS UR E26 identifies the Shipowner/Company, Systems Integrator, Supplier and Classification Society as the principal stakeholders. For the purposes of UR E26, responsibility to fulfil the requirements lies with the stakeholder that has contracted with the Classification Society.
A CRSI acting as a consultant or subcontractor therefore supports compliance within its assigned scope. It does not automatically replace the regulatory or contractual responsibility of the Shipyard, Shipowner or other party contracted with the Society.
3. Three Layers of CRSI Responsibility
The CRSI role is best understood through three distinct layers.
| Responsibility Layer | Basis | CRSI Role |
|---|---|---|
| IACS-mandated pre-delivery responsibility | IACS UR E26 and applicable Class Rules | Perform or support scope determination, ship-level integration, document preparation, as-built closure and commissioning verification under the Systems Integrator function. |
| Lifecycle-readiness responsibility | Engineering and compliance implementation principle | Structure the approved baseline so that it can be maintained, updated and demonstrated by the Shipowner after delivery. |
| Post-delivery support | Express Owner appointment or contractual agreement | Support change-impact assessment, document maintenance, Supplier coordination, vulnerability-related updates and survey preparation within the assigned scope. |
The direct post-delivery operational and survey obligations under IACS UR E26 rest with the Shipowner/Company. The newbuilding CRSI does not automatically become the party responsible for the First Annual Survey or subsequent surveys. Nevertheless, the CRSI's pre-delivery work determines whether the Shipowner can effectively perform those duties.
The CRSI's central pre-delivery responsibility is to establish, verify and hand over an as-built cyber-resilience baseline that remains understandable, traceable and maintainable throughout the vessel's operational life.
4. Principal Duties of a CRSI before Vessel Delivery
4.1 Determining the Applicable Scope
As part of the Systems Integrator function, the CRSI should identify and document the CBSs, network devices, security devices and interfaces within the scope of IACS UR E26. The determination should not rely solely on equipment names, purchase specifications or Supplier product classifications. It should consider the system's actual function, safety impact, interfaces, dependencies and final installed configuration.
The scope review should address, as applicable:
- on-board OT systems controlling or monitoring physical processes;
- statutory navigation systems;
- required internal and external communication systems;
- IP-based interfaces from in-scope CBSs to other systems;
- connections to administrative, crew welfare or other networks;
- remote-access and wireless functions;
- removable-media and maintenance interfaces;
- network and security devices supporting in-scope CBSs; and
- Owner-supplied equipment installed or connected during construction.
Scope determination should begin early. Late identification of an applicable system can result in missing UR E27 evidence, unsuitable equipment, incomplete network architecture, additional boundary-control requirements or delayed commissioning. ClassNK's implementation guidance therefore recommends early development of the preliminary Vessel Asset Inventory, Zones and Conduit Diagram and, where applicable, exclusion assessment.
4.2 Coordinating Supplier Documentation under UR E27
Depending on the system and approval route, CBS Suppliers provide system-level information including:
- CBS Asset Inventory;
- physical and logical topology diagrams;
- description of security capabilities;
- security configuration guidelines;
- security-capability test procedures and evidence;
- secure development lifecycle documentation;
- maintenance and verification information;
- Management of Change information; and
- incident-response and recovery support information.
The CRSI should review these inputs as part of the vessel design rather than retain them as isolated Supplier files. Supplier CBS Asset Inventories feed the Vessel Asset Inventory; topology diagrams support zone and conduit design; interfaces and protocols are reconciled with the ZCD and CSDD; security-capability limitations are assessed for compensating countermeasures; and approval conditions are incorporated into commissioning verification.
A Type Approval Certificate may reduce certain vessel-specific approval or test activities, subject to the Society's acceptance. It does not remove the need to integrate the approved CBS correctly into the actual vessel architecture.
4.3 Establishing the Vessel-Wide Security Architecture
The CRSI should convert the vessel's system-of-systems architecture into a controlled security architecture. This includes defining security zones, asset allocation, network segments, conduits, zone boundary devices, permitted communication, untrusted-network interfaces, remote-access paths, physical locations, local control, safe-state functions and recovery dependencies.
These decisions must be represented consistently across the Vessel Asset Inventory, ZCD, CSDD and Ship Cyber Resilience Test Procedure. Controlled identifiers for assets, interfaces, zones, conduits and boundary devices provide the traceability required to connect design decisions, the installed configuration and verification evidence.
4.4 Controlling Changes during Construction
IACS UR E26 requires design modifications during the design and construction phases to be carried out in accordance with the Management of Change requirements in UR E22.
Typical change triggers include:
- replacement of an equipment model;
- firmware, operating-system or application version changes;
- addition or removal of a physical interface;
- changes to network segments, VLANs or IP subnets;
- routing, firewall or access-control-list changes;
- introduction of remote access or wireless connectivity;
- equipment relocation;
- new inter-zone communication;
- new connections to an untrusted network; and
- changes to an exclusion or compensating measure.
The CRSI should assess each change against the complete baseline. Updating one drawing or spreadsheet is not sufficient when the same change affects asset information, permitted communication, an exclusion assessment, a compensating measure or a test case.
4.5 Completing the As-Built Baseline and Commissioning Verification
Before final commissioning, IACS UR E26 requires the Systems Integrator to:
- submit as-built versions of the design documents;
- submit the Ship Cyber Resilience Test Procedure; and
- carry out testing witnessed by the Society in accordance with the approved procedure.
The test procedure must reflect the latest CBS and network configurations and contain sufficient detail to verify the final integrated vessel. The tested configuration, the as-built documents and the delivery baseline must describe the same vessel condition.
5. The Six Core Ship-Level Deliverables
For the purposes of this series, the five ship-level document categories identified in IACS UR E26 Section 5.1 and the Ship Cyber Resilience Test Procedure identified in Section 5.2.1 are collectively referred to as the six core ship-level deliverables. This is a practical grouping for the series; IACS does not formally title the group "the six deliverables."
| No. | Deliverable | Applicability | Primary Purpose |
|---|---|---|---|
| 1 | Zones and Conduit Diagram | Core deliverable | Defines how in-scope CBSs are grouped into security zones and how communication within, between and outside those zones is represented. |
| 2 | Cyber Security Design Description | Core deliverable | Explains the vessel security design, communication purposes, protocols, data flows, boundary controls and implemented safeguards. |
| 3 | Vessel Asset Inventory | Core deliverable | Establishes the authoritative hardware, software and network baseline for in-scope CBSs. |
| 4 | Risk Assessment for the Exclusion of CBSs | Where exclusion is claimed | Demonstrates why excluding a particular in-scope CBS from relevant requirements does not result in unacceptable risk. |
| 5 | Description of Compensating Countermeasures | Where compensating measures are used | Explains how a missing inherent security capability is addressed by an alternative measure. |
| 6 | Ship Cyber Resilience Test Procedure | Core commissioning deliverable | Defines how the final integrated vessel configuration will be verified by testing or analytic evaluation. |
5.1 Zones and Conduit Diagram
The ZCD provides the architectural representation of the vessel's security zones and communication relationships.
The ZCD will be addressed in detail in Article 2.
5.2 Cyber Security Design Description
The CSDD provides the design explanation behind the architecture shown in the ZCD.
The CSDD will be addressed in Article 3.
5.3 Vessel Asset Inventory
The Vessel Asset Inventory identifies the hardware, software, networks, interfaces and related lifecycle information within the UR E26 scope.
IACS Recommendation 190 provides practical guidance, a template and a sample for preparing and maintaining the inventory. It is implementation guidance rather than a separate Unified Requirement.
The Vessel Asset Inventory will be addressed in Article 4.
5.4 Risk Assessment for the Exclusion of CBSs
This assessment is required only where a CBS within the UR E26 scope is proposed for exclusion from relevant requirements.
The assessment must be based on the actual installed configuration, interfaces, dependencies, access conditions, threats, vulnerabilities and potential consequences. A statement that a system is "stand-alone" or "not connected to the Internet" is not, by itself, sufficient evidence.
The exclusion assessment will be addressed in Article 5.
5.5 Description of Compensating Countermeasures
This document applies where a required inherent CBS security capability is unavailable and an alternative measure is used to provide equivalent protection.
The compensating-countermeasure document will be addressed in Article 6.
5.6 Ship Cyber Resilience Test Procedure
The test procedure defines how the approved cyber-resilience design will be demonstrated on the final integrated vessel.
The procedure should remain maintainable after delivery because applicable portions may be used again during the operational lifecycle, including at the Special Survey or following relevant modifications.
The Ship Cyber Resilience Test Procedure will be addressed in Article 7.
6. Documents and Evidence outside the Six-Deliverable Group
The six core deliverables are not the complete compliance package.
The Ship Cyber Security and Resilience Program is not one of the six Systems Integrator deliverables. It is an operation-phase document prepared by the Shipowner/Company and submitted to the Society in due time before the First Annual Survey.
7. The Six Deliverables Must Operate as One Evidence System
The six documents should not be developed as unrelated work products. They must describe the same CBS population, hardware and software baseline, interfaces, security zones, conduits, boundary devices, communication purposes, security measures, exclusions, compensating countermeasures and final commissioned configuration.
↓
Vessel Asset Inventory
↓
Zones and Conduit Diagram
↓
Cyber Security Design Description
↓
Exclusion and compensating-measure decisions
↓
Ship Cyber Resilience Test Procedure
↓
Test records
↓
As-built handover
The relationship is iterative rather than purely linear. A Supplier limitation may require a compensating countermeasure. That measure may alter the ZCD or CSDD, introduce a new network device, add an asset to the inventory and create an additional commissioning test.
Typical inconsistencies include:
- a CBS listed in the inventory but omitted from the ZCD;
- a conduit shown in the ZCD but not described in the CSDD;
- a protocol listed by a Supplier but absent from the vessel communication baseline;
- a compensating countermeasure without an identified implementing asset;
- an exclusion without a defined evidence basis;
- a boundary control without an associated verification activity; and
- test results referring to a software version different from the as-built inventory.
A CRSI should maintain cross-document traceability through controlled identifiers and references. Each detailed data element should also have an identified master source to avoid duplication and conflicting updates.
8. Preparing for the Operational Survey Cycle before Delivery
8.1 Responsibility after Delivery
IACS UR E26 assigns the direct operation-phase responsibilities to the Shipowner/Company. After delivery, the Shipowner manages technical and organizational security countermeasures, maintains CBS documentation through Management of Change, keeps the Ship Cyber Resilience Test Procedure aligned with the installed configuration, retains test results onboard and makes current documentation available to the Society.
| Survey Stage | Direct IACS Responsibility | Principal Demonstration |
|---|---|---|
| First Annual Survey | Shipowner/Company | Demonstrate implementation of the approved Ship Cyber Security and Resilience Program through records or other documented evidence. |
| Subsequent Annual Surveys | Shipowner/Company | Demonstrate continued implementation upon request by the Society. |
| Special Survey | Shipowner/Company | Perform applicable testing witnessed by the Society in accordance with the maintained Ship Cyber Resilience Test Procedure. |
8.2 Why Survey-Cycle Readiness Begins during Newbuilding
Although the Shipowner carries the direct post-delivery obligation, the ability to satisfy that obligation depends on the quality of the baseline delivered by the CRSI. The Shipowner cannot reliably demonstrate Management of Change if the delivery configuration is unclear, show that the Vessel Asset Inventory has been maintained if the original inventory is incomplete, or repeat an applicable test if the procedure does not identify the tested configuration and acceptance criteria.
Survey-cycle readiness must be engineered before delivery. It cannot be reconstructed reliably after the vessel has entered service.
A lifecycle-ready handover should allow the Shipowner to determine:
- what was approved;
- what was installed;
- what was tested;
- what limitations were accepted;
- what must be maintained;
- what changes trigger document review;
- what evidence must be retained;
- what tests may need to be repeated; and
- which Suppliers must be contacted for support.
8.3 Minimum Lifecycle-Ready Handover
A CRSI should prepare a handover package containing, as applicable:
- approved and as-built versions of the six core deliverables;
- approved Supplier documentation under UR E27;
- controlled source files where contractually permitted;
- asset, interface, zone, conduit and boundary-device identifiers;
- document revision and approval histories;
- commissioning test records and finding-closure evidence;
- hardware, software and configuration baselines;
- conditions of approval and unresolved operational limitations;
- Management of Change triggers and document dependencies;
- re-verification and regression-test criteria;
- Supplier support and escalation contacts;
- recovery and configuration references;
- an evidence-retention index; and
- a mapping of newbuilding information to the Ship Cyber Security and Resilience Program.
This does not transfer the Shipowner's regulatory responsibility to the CRSI. It makes the vessel lifecycle-ready and survey-ready by design.
8.4 Post-Delivery CRSI Support
Where expressly appointed by the Shipowner, the CRSI's role may continue after delivery. The assigned scope may include change-impact assessment, updates to the Vessel Asset Inventory, ZCD and CSDD, review of remote-access or wireless changes, Supplier vulnerability and patch coordination, reassessment of exclusions, maintenance of compensating-countermeasure records, update of the test procedure and technical support during Annual or Special Surveys.
Such services must be contractually defined. They do not remove the duties assigned by IACS UR E26 to the Shipowner/Company.
9. Classification Society Implementation Perspective
The IACS Unified Requirements provide the common baseline. Individual Classification Societies implement that baseline through their own Rules, guidance, submission categories and survey practices.
ClassNK and Lloyd's Register are referenced in this series as implementation examples. The applicable Rules, submission categories, approval practices and project-specific instructions of the vessel's Classification Society remain governing.
10. Series Roadmap
This seven-part series follows the document order in IACS UR E26 Sections 5.1 and 5.2. The publication order follows the regulatory document structure; the actual engineering process remains iterative.
11. Conclusion
A Cyber Resilience System Integrator is not merely an organization that prepares six documents for Class approval. The CRSI integrates the applicable CBS scope, Supplier documentation under UR E27, the vessel-wide security architecture, hardware and software baselines, security capabilities, exclusions, compensating measures, Management of Change, commissioning verification and the transition from newbuilding compliance to operational assurance.
The six core ship-level deliverables provide the structure for this work:
- Zones and Conduit Diagram;
- Cyber Security Design Description;
- Vessel Asset Inventory;
- Risk Assessment for the Exclusion of CBSs, where applicable;
- Description of Compensating Countermeasures, where applicable; and
- Ship Cyber Resilience Test Procedure.
The success of an IACS UR E26 project should not be measured by whether six files have been submitted. It should be measured by whether those documents describe the same vessel, the same CBSs, the same interfaces, the same approved security architecture, the same exception decisions, the same tested configuration and the same as-built baseline.
The direct operation-phase and survey obligations remain with the Shipowner/Company. Nevertheless, their technical foundation is created during design, construction and commissioning. The CRSI's role is to ensure that this foundation is complete, verified, traceable and maintainable from the outset.
The Zones and Conduit Diagram — its regulatory purpose, required content, physical and logical representations, development methodology and relationship with the Vessel Asset Inventory and CSDD.
References
- International Association of Classification Societies, UR E26 Rev.1: Cyber Resilience of Ships, November 2023.
- International Association of Classification Societies, UR E27 Rev.1: Cyber Resilience of On-board Systems and Equipment, September 2023.
- International Association of Classification Societies, UR E22 Rev.3 Corr.1: Computer-based Systems, September 2025.
- International Association of Classification Societies, Recommendation No.190: Recommendation for Vessel Asset Inventory for Computer-based Systems, June 2025.
- International Association of Classification Societies, Recommendation No.166: Recommendation on Cyber Resilience, Corr.2, April 2022.
- ClassNK, Guidelines for Cyber Resilience of Ships, Edition 1.1, 29 August 2025.
- Lloyd's Register, Rules and Regulations for the Classification of Ships, July 2025, Part 6, Chapter 1.
Disclaimer. This article provides general technical guidance on the implementation of IACS cyber-resilience requirements. It does not replace the applicable IACS Unified Requirements, statutory and Flag requirements, the Rules and instructions of the relevant Classification Society, approved project documentation, contractual requirements or ship-specific decisions made by the Society.
About the Author
Woojin Lee specializes in maritime and IoT security with expertise spanning multiple ISO standards and compliance frameworks, including IACS UR E26/E27, ISO 27001, ISO 27701, ISO 42001, and ISMS-P. Woojin brings technical depth in automation cybersecurity engineering and privacy advisory services, holding an M.S. in Computer Software Engineering from Korea University and a B.S. in Software Engineering from Lancaster University (Upper Second Class Honours). Recognitions include the Outstanding Paper Award at the Korea Blockchain Academic Conference (2021) and the Grand Prize at the Korea Financial Security Institute (2022).
GitHub: https://github.com/lwjace
Meet Woojin and the ShipJobs Crew: https://www.shippauljobs.com/p/202601-crew-behind-shipjobs-ship-ai.html
⚓ Join the ShipPaulJobs Community
Join →
This is an excellent start to the series. The article clearly illustrates that compliance is shifting from document-based verification to architecture-based cyber resilience.
ReplyDeleteThe MASS Code and IACS UR E26 are converging on the same message: secure-by-design, resilient communications, and system-level integration are becoming essential engineering requirements for next-generation vessels.
I believe this series will become a valuable reference for shipyards, class societies, and system suppliers.