Chapter 9 From Compliance Documentation to Sustainable Cybersecurity Engineering
Chapter 9. Maritime Cybersecurity as a Discipline
Why Maritime Cybersecurity Became a System Engineering Issue (9/9) — Final Chapter
In the previous chapter, we looked at how Engineering Information actually flows through a project — from the first request at kickoff, through the moments it takes on new meaning as design evolves, through verification, and into the years after delivery. As we reach the final chapter of this series, it is worth asking a more practical question.
What should shipyards and equipment suppliers actually prepare to execute these projects effectively?
Organizations approaching IACS UR E26/E27 for the first time often begin by identifying the required deliverables and then preparing each document as the project progresses. This may be unavoidable at the beginning. However, as projects become repetitive, it is difficult to build a sustainable Cybersecurity Engineering capability if every project starts by recreating the CSDD, collecting the same Network Information again, asking suppliers the same questions, and searching for the necessary Evidence shortly before testing.
In this final chapter, I'd like to share nine practical anchors for building that structure — based on real UR E26/E27 project experience.
Ⅰ. Start with Engineering Information, Not with the CSDD
Opening a blank CSDD and immediately starting to write may not be the best way to begin a UR E26 project. A CSDD is not really a document that creates information — it is better understood as a document that connects and explains existing Engineering Information from a cybersecurity perspective. Before drafting the CSDD, at least the following information should be available:
- CBS Inventory and key functions
- System/Network Architecture
- Zones and Network Boundaries
- Interfaces and Data Flows between CBSs
- Protocols, Ports, and Services
- External/Remote Access
- User and Privileged Access
- Software/Firmware and major Versions
- Backup and Recovery Mechanisms
- Operational Dependencies and major Failure Impacts
This does not mean all of this must be recreated in a new cybersecurity-specific document. A more practical approach is to identify what already exists in System Architecture documents, Network Diagrams, Interface Specifications, Product Specifications, FAT Procedures, and Operation Manuals, and then address only the missing elements.
CSDD Development → Information Collection
Engineering Information Collection → Review and Correlation → CSDD Development
Ⅱ. Shipyards and Suppliers Should Prepare Different Baselines
Shipyards and equipment suppliers do not need to prepare the same information. Because the shipyard is responsible for integrating the vessel as a whole, it needs to establish a System-Level Baseline:
- Overall CBS List and Cyber Scope
- Overall Network Architecture
- Zone/Conduit Structure
- Cross-Zone Communication
- External Connectivity
- Remote Access Architecture
- Key System Dependencies
- Ship-Level Recovery Concept
Equipment suppliers need a Product-Level Baseline that clearly explains their own CBS:
- CBS Architecture
- Hardware/Software Configuration
- Network Interfaces
- Protocols/Ports/Services
- Account and Authentication Mechanisms
- Security Configuration
- Logging and Audit Capabilities
- Backup/Restore Methods
- Software Update Methods
- Remote Maintenance Mechanisms
- Cybersecurity-related Test Evidence
Ⅲ. Define the Minimum Engineering Evidence Set
Not all available information needs to be requested. When organizations first begin Cybersecurity Engineering projects, uncertainty often leads them to collect as much documentation as possible — but asking suppliers for dozens of documents can actually make the project harder. The first step for the shipyard and CRSI should be to define the Minimum Engineering Evidence actually required to assess each CBS:
"What is the minimum Evidence needed to determine whether this CBS satisfies the applicable requirements?"
For Remote Access, for example, rather than simply requesting a "Remote Access Manual," it may be more useful to answer practical questions such as:
- Who can connect?
- Where do they connect from?
- What communication path is used?
- What Authentication mechanism is applied?
- Under what conditions is access permitted?
- How are Sessions controlled?
- Is access activity logged?
- Can Remote Access be disabled in an emergency?
Ⅳ. Build Traceability Before Testing Begins
If a project waits until the cybersecurity testing phase to connect Requirements with Test Cases, it may already be too late. At a minimum, the following relationship should be visible from the design stage:
For a Remote Access Requirement, for example, it should be possible to trace where the Requirement is reflected in the Architecture, which product function or Configuration implements it, which FAT/SAT item verifies it, and what final Evidence demonstrates that it has been satisfied.
Ⅴ. Establish a Single Source of Truth for Repeated Information
One of the more dangerous situations in a real project is when the same information appears differently across multiple documents — for the same CBS:
- — the CSDD states Software Version 3.2,
- — the FAT Report states Version 3.1,
- — the Supplier Manual states Version 2.9.
Having three documents does not strengthen the Evidence — it actually reduces confidence in it. Frequently reused information should, wherever possible, have a Single Source of Truth, such as:
- CBS Identification
- Manufacturer/Model
- Software/Firmware Version
- IP Address
- Zone / Interface
- Protocol/Port
- Security Function
- Test Status / Evidence Reference
Ⅵ. Treat Supplier Evidence as Reusable Product Knowledge
Equipment suppliers also need to change how they approach these projects. Responding individually to customer questions every time a new UR E27 project begins is not efficient in the long term. When the same CBS is supplied to multiple shipyards or vessels, much of the following remains the same — Product Architecture, Security Capability, Interfaces, Account Management, Logging, Malware Protection, Backup/Recovery, Software Update, Remote Access, and Security Test Results.
Instead of recreating this information for every project, suppliers can manage it as a Reusable Cybersecurity Product Package, with only project-specific elements managed separately. Conceptually, the Evidence can be divided into three layers:
Ⅶ. Move from Document Review to Change Management
A vessel will not remain permanently in the same Configuration that existed at delivery — software will be updated, network configurations will change, remote maintenance arrangements may be modified, and equipment may eventually be replaced. The important question, therefore, is not simply:
"Has the document been updated?"
A more important question is:
"What impact does this change have on the existing Cybersecurity Design?"
For example, adding a new Remote Maintenance Connection may require much more than updating a Network Diagram — it may affect Zone/Conduit, Firewall Rules, Access Control, Logging, Risk, Recovery, and even the Test Scope.
Future Cybersecurity Documentation should move beyond static document management and become increasingly connected with Configuration and Change Management.
Ⅷ. Automation Should Begin with Repeated Engineering Information
As the number of UR E26/E27 projects increases, demand for Automation will naturally grow. However, immediately starting with AI-generated CSDDs may not be the right first step. The first targets for Automation should be repetitive Engineering Information — for example:
- Generating a System List from the CBS Inventory
- Creating an Interface Matrix from Network Information
- Connecting Zone information with Data Flows
- Mapping Requirements to Evidence
- Reflecting Test Results in Verification Status
Ⅸ. The Future Is a Digital Engineering Model, Not a Larger Document Set
As Maritime Cybersecurity Engineering evolves, the ideal direction should not be an ever-increasing number of deliverables. A more sustainable model is one in which:
- Engineering Information is created once,
- multiple stakeholders share and reuse that information,
- Requirements are linked directly to Design,
- Test Results are reflected within the same information structure,
- the impact of changes can be traced,
- and required Documentation can be generated from the underlying Engineering Information.
This represents a transition from Document-Centric Engineering to Data/Information-Centric Engineering. In such an environment, the CSDD would no longer need to be treated as a standalone document created toward the end of the project — instead, it becomes one of the outputs that presents Engineering Information accumulated throughout the project lifecycle from a cybersecurity perspective.
Closing Remarks
The question that started this series was relatively simple:
"Why has Maritime Cybersecurity become a System Engineering issue?"
As we moved through each chapter, the answer became increasingly concrete. Cybersecurity on modern vessels cannot be achieved through security functions such as Firewalls or Authentication alone:
- We need to understand the relationships between CBSs.
- We need to be able to explain the Design Intent.
- We need to preserve those engineering decisions as Engineering Evidence.
- Shipyards and equipment suppliers need to connect information developed at different engineering levels.
- And that information must continue from design through testing and into operation.
To move one step further, we also need to move away from repeating the same activities from the beginning for every new project:
- Shipyards should accumulate a Vessel/System-Level Cybersecurity Baseline.
- Equipment suppliers should prepare Reusable Product-Level Cybersecurity Evidence.
- CRSI should connect these two layers and develop a Consistent System-Level Engineering Story.
- Traceability must be maintained across Requirement, Design, Configuration, Test, and Evidence.
When this becomes possible, responding to IACS UR E26/E27 will no longer need to be a new Compliance Exercise that starts from scratch with every project. Instead, organizations can build a repeatable Cybersecurity Engineering Process in which existing Engineering Knowledge is applied to new vessels, verified, and then accumulated again for future use.
I believe this is one of the key directions in which Maritime Cybersecurity Engineering should continue to evolve:
- ✓Less repeated documentation
- ✓Better structured information
- ✓Stronger traceability
- ✓More reusable engineering evidence
- ✓And ultimately, more sustainable Cybersecurity Engineering
With this chapter, I would like to conclude the series.
Across nine chapters, this series has argued a single thesis: Maritime Cybersecurity is no longer a set of security functions bolted onto a vessel — it is a System Engineering discipline that spans design intent, engineering evidence, organizational boundaries, and the entire project lifecycle.
Thank you for following this series from Chapter 1 to here. I hope it has been useful in framing how your own organization approaches IACS UR E26/E27 — not as a compliance checklist, but as an engineering capability worth building once and reusing for years.
Related Reading:
- Chapter 1. Why Does Cybersecurity Need to Be a System Engineering Issue? — Where This Series Began
- 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
- 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 →
A valuable insight.
ReplyDeleteThe future of maritime cybersecurity is shifting from document-centric compliance to engineering-centric assurance. With AI increasingly supporting ship systems, traceability between requirements, architecture, implementation, testing, and compliance evidence will become essential.
Documentation is no longer just paperwork—it is proof that trust has been engineered into the system.