Chapter 7. Role of Shipyard and Supplier

💡 Insight Series 7 / 9 IACS UR E26/E27 Shipyard & Supplier System Engineering

Chapter 7. Role of Shipyard and Supplier

Why Maritime Cybersecurity Became a System Engineering Issue (7/9)

Blue Horizonist (Lew)
Blue Horizonist (Lew)
Maritime & Cyber Security Consultant · ISP Consultant
📚 Blue Horizonist Series — Why Maritime Cybersecurity Became a System Engineering Issue

In the previous chapter, we explored why Engineering Evidence is becoming increasingly important in modern Maritime Cybersecurity. We also discussed how Explainable Design is built upon the ability to clearly communicate design intent, operational assumptions, and verification results, and how Engineering Evidence provides the structured information needed to support that objective.

This naturally leads to the next question:

🔍 Key Question

"Who is responsible for preparing this Engineering Evidence?"

Many people tend to answer this question rather simply:

  • The shipyard is responsible for E26.
  • The equipment supplier is responsible for E27.
While this distinction is generally correct, the reality of a project is far more collaborative. Modern ship systems have become too complex for a single organization to design, explain, and validate every aspect of Cybersecurity on its own.

Ⅰ. Shipyards and Suppliers View the Same System Differently

Shipyards and equipment suppliers often look at the same system from very different perspectives.

🏗️ Shipyard Perspective
  • What role does this CBS play within the overall system?
  • How does it interface with other CBSs?
  • What operational impact would result from its failure?
  • How is it integrated into the vessel as a whole?
⚙️ Equipment Supplier Perspective
  • Does the product satisfy its required functions?
  • Do the internal CBS functions operate correctly?
  • Does the product meet its technical specifications and performance requirements?
  • Has the implementation been carried out appropriately?
Both perspectives are equally valid. The difference lies not in who is right, but in the level at which each organization views the system.

Ⅱ. Cybersecurity Creates Shared Responsibilities

In traditional projects, each supplier was primarily responsible for its own equipment. Cybersecurity, however, is gradually changing this responsibility model.

For example, an equipment supplier is expected not only to explain its own CBS, but also to describe how that CBS interacts with the surrounding systems. Similarly, the shipyard is responsible not only for system integration, but also for understanding the engineering intent behind the supplier's design.

Cybersecurity therefore does not simply increase the responsibilities of individual organizations. Instead, it significantly increases the need for collaboration between them.

Ⅲ. Engineering Evidence Must Connect Across Organizations

Engineering Evidence should never remain isolated within a single organization. For example:

  • Interface information prepared by a supplier should align with the shipyard's overall system design.
  • Recovery information provided by the supplier should support the vessel's overall recovery strategy.
  • Product-level test results should be traceable to integrated system testing.
Engineering Evidence is therefore not completed within the boundaries of one organization. It gradually takes shape by connecting information contributed by multiple stakeholders throughout the project.

Ⅳ. Early Collaboration Reduces Engineering Rework

In real-world projects, many Cybersecurity-related issues arise simply because discussions begin too late. Typical examples include:

  • Modifying interfaces after the Zone architecture has already been finalized
  • Redesigning system functions due to newly introduced Remote Access policies
  • Discovering operational constraints only during the testing phase

These situations often lead to unnecessary engineering rework. By contrast, when shipyards and equipment suppliers begin collaborating from the early design stages and share a common engineering perspective, many of these changes can be avoided.

Cybersecurity is not a feature to be added at the end of a project. It is an engineering consideration that should be incorporated from the very beginning.

Ⅴ. The Role of the CRSI

IACS UR E26 defines the role of the Cyber Resilience System Integrator (CRSI). However, this does not mean that the CRSI is responsible for producing all Cybersecurity information or designing every aspect of the system.

In practice, the CRSI's most important responsibility is to connect the information provided by shipyards and suppliers while ensuring consistency at the system level. For example:

  • Is the Zone architecture consistently defined?
  • Are interface descriptions aligned across different systems?
  • Does the overall Recovery strategy remain consistent throughout the vessel?
  • Is the Engineering Evidence free from contradictions?
Coordinating these elements is often far more important than producing additional documentation. In this sense, the CRSI should not be viewed as the organization that creates all information. Rather, it is the organization that connects information into a coherent system.

Ⅵ. Successful Projects Depend on Collaboration, Not Documentation

Successful Cybersecurity projects are not defined by the number of documents produced. Far more important is whether the right information is shared with the right stakeholders, at the right level of detail, and at the appropriate stage of the project. Even excellent Engineering Evidence has limited value if it is never shared or properly understood.

When an effective collaboration framework is established, the same Engineering Evidence can support a far more efficient project. Ultimately, successful Cybersecurity projects begin not with better documentation, but with better collaboration.

Closing Remarks

Today's Maritime Cybersecurity cannot be achieved by any single organization working independently.

  • Shipyards provide the perspective of overall system integration.
  • Equipment suppliers contribute expertise related to individual CBSs.
  • The CRSI connects these contributions at the system level.
  • Classification societies independently verify the final outcome.

Although each stakeholder has a different role, they all share the same objective: to build digital ship systems that are secure, understandable, and verifiable.

Key Takeaway

E26 for the shipyard, E27 for the supplier — that split describes accountability, not collaboration. Real Cybersecurity engineering happens where those two perspectives connect, coordinated by the CRSI into one coherent, traceable system.

In the next chapter, we will explore how this collaborative approach is translated into practical documentation throughout real-world projects, and how Engineering Evidence evolves into a structured documentation framework that supports the entire system lifecycle.

#MaritimeCybersecurity #IACS #URE26 #URE27 #Shipyard #CRSI #EngineeringEvidence #Maritime40 #BlueHorizonist
Blue Horizonist (Lew)
Blue Horizonist — Jiho (Jay, 智晧) Lew
Maritime & Cyber Security Consultant · ISP Consultant

Practitioner at the intersection of maritime OT security and IACS UR E26/E27 compliance. Writing the Blue Horizonist series to bridge the gap between regulatory language and real-world engineering decisions at shipyards and aboard vessels.

⚓ Join the ShipPaulJobs Community

Join →
Share

Comments