Chapter 8. How Engineering Information Flows Through a Project
Chapter 8. How Engineering Information Flows Through a Project
Why Maritime Cybersecurity Became a System Engineering Issue (8/9)
In the previous chapter, we explored how Cybersecurity responsibilities are shared between shipyards, equipment suppliers, and the CRSI, and how Engineering Evidence must connect across organizational boundaries to remain useful. This naturally leads to a related question: how does Engineering Information actually flow through a project — from the first request for information to years after delivery?
Engineers who are new to Cybersecurity Engineering projects often begin by looking for a list of required documents. They want to know when a CSDD is needed, what tests should be prepared, and which deliverables must be submitted. However, once you become involved in a real project, you quickly realize that the most important aspect is not the documentation itself, but when Engineering Information is created, who needs it, and how it is carried forward throughout the project lifecycle.
In this chapter, I'd like to share some observations on how Engineering Information actually flows throughout a UR E26/E27 project based on practical project experience.
Ⅰ. At the Beginning of a Project, the Biggest Gap Is Not Documentation — It's System Information
When a project begins, shipyards request a wide range of information from equipment suppliers. However, what they need at this stage is rarely a 500-page user manual. Instead, they are looking for answers to practical engineering questions, such as:
- Which network will this equipment connect to?
- Does it require external connectivity?
- Which communication protocols does it use?
- How will it interact with other onboard systems?
In many cases, suppliers respond by providing product brochures, manuals, or catalogues before addressing these engineering questions.
Ⅱ. As the Design Evolves, Information Takes on New Meaning
Information that seems sufficient during the early design stage often becomes much more significant as the project progresses.
For example, an IP address may initially appear to be nothing more than a configuration parameter. Later in the project, however, it becomes closely related to:
- Zone architecture
- Firewall rules
- Remote access configuration
- Test scenarios
The same piece of information gradually evolves into valuable Engineering Information as the project develops.
Ⅲ. Most Project Issues Are Caused by Disconnected Information, Not Missing Information
Toward the end of a project, the problem is often not that information is unavailable — it already exists.
- The network architecture is documented in the design package.
- The software version is recorded in the FAT report.
- The recovery procedure is described in the operational documentation.
The challenge is that these pieces of information are rarely connected.
When a classification society asks a single engineering question, multiple teams may need to search through different documents before finding a complete answer.
In many real projects, Information Fragmentation becomes a much bigger challenge than an actual Information Gap.
Ⅳ. Good Engineering Information Continues to Be Used During Verification
Testing should not be viewed as the process of generating new information. Instead, it should verify the engineering decisions that have already been made.
For example, the Network Architecture defined during the design phase becomes the basis for FAT and SAT verification, while Remote Access policies often become operational procedures after commissioning.
Repetitive work decreases significantly as the project moves forward.
Once the same information begins to be recreated in multiple places, project complexity increases rapidly.
Ⅴ. Engineering Information Continues to Deliver Value Long After Project Delivery
Many people assume that documentation has fulfilled its purpose once a vessel is delivered. In reality, that is often when its long-term value begins.
- Software updates may be required during vessel operation.
- New remote maintenance capabilities may need to be introduced.
- The same equipment may be installed on future vessels several years later.
In these situations, the greatest value comes not from creating new documentation, but from being able to reuse existing Engineering Information with confidence.
Ⅵ. Successful Projects Are Driven by Information Flow, Not Document Management
In practice, the most successful projects are rarely those that produce the largest number of documents. They are the projects where the right information reaches the right people at the right time.
Shipyards, equipment suppliers, system integrators, and classification societies all play different roles throughout the project. Yet they rely on the same Engineering Information, each from a different perspective.
For this reason, a successful project is not defined by the volume of its documentation. It is defined by how effectively Engineering Information is created, validated, shared, and reused throughout the project lifecycle.
That is why, in real Engineering projects, Information Flow is ultimately more important than Documentation itself.
Ⅶ. Practical Anchors for Managing Information Flow
Recognizing that Information Flow matters is only the first step. In practice, a few concrete habits make the difference between information that flows and information that fragments:
- ✓ Designate a single source of truth for each information category — one master Zone & Conduit Diagram, not a separate copy per team or per document.
- ✓ Version and date every engineering artifact so FAT/SAT reviewers always know which design baseline they are actually testing against.
- ✓ Assign an explicit owner at every handover point — design to testing, testing to operation — so information never sits unattended between organizations.
- ✓ Keep a one-page traceability index — a simple map of which document answers which question — instead of continuously expanding the document set itself.
Closing Remarks
Maritime Cybersecurity Engineering is not about producing more documents, nor is it simply about preparing evidence to satisfy regulatory requirements.
True Engineering is about ensuring that the right information is created at the right time, reviewed by the appropriate stakeholders, and continuously reused throughout the lifecycle of a system.
In many ways, IACS UR E26 and UR E27 provide a common engineering framework that enables this flow of information to become more structured and more consistent.
Ultimately, successful projects are not those with the largest documentation packages, but those where Engineering Information flows naturally across the entire project.
Engineering Information is not a document to be filed away — it is an asset that must be created, connected, and reused throughout the entire project lifecycle.
In the final chapter of this series, I will bring together the Engineering Thinking we have explored throughout these articles and share my thoughts on where Maritime Cybersecurity Engineering is heading in the years ahead.
Related Reading:
- Anatomy of a Ship ZCD — Understanding the Building Blocks of an IACS UR E26 Zone and Conduit Diagram
- Why Most Ship ZCDs Fail — Seven Common Mistakes in IACS UR E26/E27 Projects
- [CRSI] IACS UR E26 Cybersecurity Requirements: Roles of Shipowners, Shipyards and Suppliers
- Is a SoC-Centric Approach Enough for Ship Cybersecurity?
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 →
Comments
Post a Comment