Efficient Way to Classify System Types in IACS UR E26/E27

As a Cyber Resilience System Integrator (CRSI), I work in close collaboration with shipowners and shipyards to ensure that newly built vessels comply with both IACS UR E26 requirements and the shipowners’ cybersecurity policies throughout the newbuilding process.

In this article, I aim to share the practical challenges I have repeatedly encountered while performing the role of a CRSI during the actual design and construction phases, as well as the hands-on insights I have gained and distilled through that process.

I hope that this content can serve as a small but useful reference for professionals who are preparing to address IACS UR E26/E27 requirements.

Who Should Read This

• Are responsible for implementing cybersecurity on ships
• Are uncertain whether IACS UR E26 or UR E27 applies to their vessels or projects
  
• Are directly involved in ensuring compliance with UR E26 and UR E27
  
• Are more familiar with UR E27 but less experienced with UR E26, or the other way around

TL;DR

1.      IACS UR E26 and UR E27 both aim to enhance the cyber resilience of ships. While UR E27 focuses on requirements at the individual system level, UR E26 takes a holistic approach at the ship-wide level.

2.        During the UR E26 design phase, the submission of various documents centered around the Computer Bases Systems (CBS) is required, making close collaboration between shipyards and equipment suppliers essential.

3.      Multiple documents must be submitted for CBS-related systems, and the scope of required documentation varies depending on the system classification, such as Non-CBS, Out-of-Scope, Exclusion, or Target.

4.      In actual shipbuilding projects, system classifications are often not finalized at the time of document submission, which frequently leads to schedule delays.

5.       To mitigate this risk, it is effective to apply Risk Assessment in a phased manner, enabling early system classification and alignment with supplier system design, manufacturing, and FAT activities.

 

1. Differences in Scope and Perspective Between IACS UR E26 and UR E27

IACS UR E26 and UR E27 are applicable to all stakeholders involved in the construction and operation of ships, including shipowners, shipyards, classification societies, and equipment suppliers. Both regulations share a common objective: ensuring the cyber resilience of ships.

That said, the two requirements differ clearly in their scope and perspective.

• UR E26 requires cyber resilience to be addressed from an integrated, ship-wide perspective, covering the vessel as a whole, including the systems that fall under the scope of UR E27.
• UR E27, on the other hand, focuses on individual systems onboard, defining detailed cybersecurity requirements that each applicable system must meet and be assessed against.

In other words, UR E26 deals with the overall cybersecurity architecture and management framework at the ship level, while UR E27 addresses cybersecurity requirements at the system level.

NOTE: This article does not aim to explain the detailed technical requirements of UR E26 and UR E27 themselves. Instead, it focuses on how systems can be efficiently classified from a practical, real-world perspective during actual ship design and construction projects. For detailed regulatory interpretations, readers are encouraged to refer to the relevant official documentation and guidance materials.

 

2. What Documents Are Required During the Design Phase?

 "The systems integrator shall demonstrate compliance by submitting documents in the following subsections to the Society for assessment." — IACS UR E26 sec. 5.1

According to IACS UR E26 Section 5.1, the Cyber Resilience System Integrator (CRSI) is required to submit the following documents.

1.      Vessel asset inventory: The vessel asset inventory shall incorporate the asset inventories of all individual CBSs falling under the scope of this UR.

2.      Zones and conduit diagram: The Zones and conduit diagram shall illustrate the CBSs in the scope of applicability of this UR, how they are grouped into security zones, and include the following information

3.      Cyber security design description (CSDD): The content of this document is specified in subsections “Design phase” for each requirement in section 4.; In practice, this includes system-level descriptions demonstrating how each CBS complies with the relevant UR E27 requirements.

4.      Risk assessment for the exclusion of CBSs: Risk assessment for exclusion of CBS from the application of requirements

5.      Description of compensating countermeasures: This document shall specify the respective CBS, the lacking security capability, as well as provide a detailed description of the compensating countermeasures.

  

3. Ultimately, the Core Is the “System”, Specifically the CBS

When the documents required during the design phase are reviewed as a whole, it becomes clear that all of them are centered around systems, and more specifically, Computer Based Systems (CBSs).

To prepare and submit these documents effectively, close collaboration between the shipyard and the equipment suppliers is essential.

• The shipyard provides ship-wide information required to develop the Zones and Conduits Diagram from an overall vessel perspective.
• The suppliers provide detailed system-level information required for preparing the Vessel Asset Inventory, CSDD, Risk Assessment, and descriptions of Compensating Countermeasures.

Only through such collaboration can a consistent and integrated set of cybersecurity documents, reflecting a ship-wide perspective, be completed.

 

NOTE: While detailed procedures may vary depending on the Classification Society, in general, suppliers submit the relevant documents for an initial review prior to shipbuilding contract (S/C) signing to confirm regulatory compliance. The review results are then shared with the CRSI and the shipyard, and subsequently submitted for formal approval by the Classification Society.

 

4. How Document Submission and Scope Vary by System Type

Fortunately, under UR E26, it is not necessary to submit all of the previously mentioned documents for every system installed onboard. The key point is that the documents required during the design phase vary depending on the system type.

To properly understand this, it is first necessary to classify each system according to its applicable type. Based on this understanding, we categorize systems using the common terminology defined under UR E26, as summarized in the table below.

The table provides an at-a-glance overview of which documents are required for each system type. However, it is important to note that the classification outcome for the same system may differ depending on the Classification Society. For this reason, early review and preliminary classification of system types during the initial design phase is critical.

 

Type	Description	Document Required
Non-CBS	This system is not considered a Computer-Based System (CBS) in accordance with the criteria defined in UR E26.	Not Required; however, supporting documentation demonstrating that the system is Non-CBS must be submitted.
Out-of-Scope	This system is a CBS but is not included within the scope of applicability in accordance with UR E26 Section 1.3.2 (Systems in Scope).   NOTE: Even for the same system, the classification result may vary depending on the classification society.	Not Required; however, supporting documentation demonstrating that the system is Out-of-Scope must be submitted.
Exclusion	This system is a CBS, but it is excluded from the application of UR E26 requirements in accordance with UR E26 Section 6.4 (Acceptance Criteria).   NOTE: Even for the same system, the classification result may vary depending on the classification society.	Not Required; however, supporting documentation demonstrating that the system is Exclusion must be submitted.
Target	This system is a CBS that does not fall into any of the categories above and is therefore subject to the requirements of UR E26.	Required

 

5. Practical Risks Caused by Undecided Makers and Unconfirmed Classifications

One of the most challenging situations during CRSI activities is having to submit documents to the classification society before all system makers have been finalized. This is particularly common for systems that fall under OFE, where vendor selection often happens relatively late in the project.

Another frequent issue is that, at the time of document submission, it is not always clear whether a system should be classified as Out-of-Scope or Exclusion. In many cases, the final classification is determined later due to factors such as regulatory compliance decisions during ship construction or specific contractual conditions. As a result, the system type may remain undecided until a later stage.

Adding to the complexity, the same system can be classified differently depending on the classification society. This is because each society may apply its own definitions, interpretations, and criteria when determining system scope and applicability under UR E26.

 

To summarize the practical situation, it typically looks like this:

• In theory, documents such as the Vessel Asset Inventory and Zones and Conduit Diagrams are only required for systems classified as Target.
• In practice, however, there are many cases where the system type has not yet been finalized even after the S/C key event. This uncertainty can quickly turn into a major risk, as it may lead to delays in the overall shipbuilding schedule.
• To mitigate this risk, we often recommend preparing the full set of documents in advance. From a mid- to long-term perspective, this approach also supports system suppliers in strengthening their cybersecurity readiness, improving market competitiveness, and potentially facilitating compliance with IACS UR E27 certification.

 

However, supplier readiness is still limited in many cases. To compensate for this, we have established an internal three-step risk assessment policy. This allows us to better control schedule risks while steadily building practical experience and policies for emerging ship cybersecurity regulations.

 

6. Risk Assessment Process

• RA Phase1: RA Phase 1 aims to identify the system type as early as possible, starting from the maker selection stage. To support this, classification‑society‑specific guidelines are provided to suppliers, and one‑to‑one, on‑site meetings are conducted. During these meetings, the first phase of the risk assessment is carried out, including initial system categorization.
• RA Phase2: Based on the system type identified in RA Phase 1, potential cyber threat risks are assessed by consolidating system‑specific asset information, submitted drawings, and wiring data. This phase focuses on understanding how each system may be exposed to cyber threats.
• RA Phase3: RA Phase 3 considers the actual operational environment of each system. The assessment focuses on the system’s response capabilities and control levels against known cyber threats, rather than evaluating risks at a purely theoretical level.

In practice, our supplier support activities focus primarily on RA Phases 1 and 2. This process begins by classifying onboard systems into Non‑CBS, Out‑of‑Scope, Exclusion, and Target types and can be considered the first practical step toward improving the cyber threats identified during the assessment.

In this article, we focus specifically on RA Phase 1. The detailed risk assessment activities performed during RA Phase 1 are outlined below.

 

Conclusion

On the surface, IACS UR E26 and E27 may look clear enough when you read through the requirements. But once you step into the actual design and construction phase, the reality feels quite different. Unfinalized system classifications, delayed supplier selection, and varying interpretations among classification societies are issues we frequently encounter. These uncertainties may seem minor at first, but they can easily grow into real risks, especially when project schedules are at stake.

From my perspective, the role of a CRSI is not limited to interpreting regulations or passing on requirements. What really matters is recognizing these uncertainties early on and finding realistic ways to deal with them. The phased risk assessment approach described in this article came from that exact mindset, an effort to move system classification decisions forward and reduce downstream surprises.

I hope this article offers some practical direction or useful reference for those preparing for UR E26 and E27 compliance. As ship cybersecurity regulations continue to evolve, I plan to keep sharing lessons learned and practical insights from real projects. Hopefully, these experiences can be helpful to others facing similar challenges along the way.