E26 Deliverable Quality — The Low, Medium, and High Tiers

💡 Insight Deliverable Quality UR E26 Cyber Resilience

E26 Deliverable Quality: The Low, Medium, and High Tiers

The same E26 documents — so why do some projects build resilience while others leave behind only paperwork?

Julius
Julius
Maritime Technical Consultant · Shipboard Cybersecurity & Compliance
- LinkedIn : https://www.linkedin.com/in/abysstoinfinity/

Over the past few years, IACS UR E26 has become an essential requirement for newbuilding vessel projects. As a result, a great many E26 deliverables are being produced.

Cyber Security Plan Asset Inventory Network Diagram Data Flow Diagram Risk Assessment Security Test Report Backup & Recovery Procedure Remote Access Procedure Vendor Security Documentation

What's interesting is that most projects submit a similar list of documents. But when you actually open the deliverables, the difference in quality is far greater than expected. Some documents become powerful assets in the operational phase. Others are never opened again after class approval.

Why does this difference arise? The answer is surprisingly simple.


Higher-tier organizations produce documents.

The highest-tier organizations produce resilience.

The Real Purpose of E26

Many people think of E26 as a cybersecurity regulation. But the core of E26 is not the security function. The core is cyber resilience. That is:

It assumes that an attack may occur,
acknowledges that a failure may happen,
and designs so that essential functions can be maintained even in that situation.

A good deliverable, therefore, must not be a document that describes security equipment, but a document that explains how the vessel will survive.


Low

The Low Tier

"As long as it passes class approval, that's enough."

This is the most commonly seen tier. The documents exist. All the requirements are checked off. But after reading the documents, you find yourself thinking: So how does the system actually work?

Take an Asset Inventory, for example.

Asset Name IP Address
ECDIS 192.168.1.10
Radar 192.168.1.20
IAS Server 192.168.1.30

That's it. From this document alone, you cannot tell:

What is the essential function?
What is the impact in case of failure?
Who manages it?
What network is it connected to?
Is it a backup target?
What is its recovery priority?

The document exists, but there is no information.

Characteristics

· Many traces of copy-and-paste.
· The content is nearly identical across projects.
· There are inconsistencies with the actual system.
· Vendor materials are attached as-is.
· No usability in the operational phase.
· Not linked to essential functions.

The problem

It can pass the review. But when an incident occurs, it provides no help at all. In other words, it is nothing more than an approval document.


Medium

The Medium Tier

"It can describe the current state."

This is the tier most organizations aim for. The documents and the actual system are largely consistent. The Asset Inventory includes not just a simple equipment list but also the following information:

Function Location Owner Vendor Criticality Security zone

The Network Diagram, too, reflects the actual configuration. The Risk Assessment also has at least a minimum of logic.

Characteristics

The system's current status can be grasped
Change history can be managed
It can respond to reviews
It can be handed over to the operating organization

The problem

But there is a limit here too. Many documents explain "what exists" but cannot explain "what happens."

For example: the ECDIS server has failed. What next? Even if you dig through the documents, it is hard to find.

High

The High Tier

"It can describe resilience."

High-tier deliverables do not simply describe assets. They describe functions. And they even describe failure scenarios. Take an Asset Inventory, for example.

Asset Function Essential Function Recovery Priority
ECDIS-A Navigation Yes High
ECDIS-B Navigation Backup Yes High
Printer Administration No Low

At this point, it becomes not a simple equipment-management document but an operational decision-making document.


Top

The Top Tier

"It supports operation, incident response, and recovery."

This is, in fact, the tier closest to the intent of E26. Deliverables at this tier do not simply describe the current state. They are used when an incident occurs. For example, they can immediately answer the following questions:

What if the ECDIS is infected with ransomware?
What if the IAS Historian server fails?
What if the Cargo Control System is isolated?
What if a vendor VPN account is compromised?

And the following information is already defined:

Affected essential function Alternative operating procedures Recovery sequence Responsible party Estimated recovery time Validation method

Documents at this tier are not review-response documents but are closer to an operation tool.


The Real Difference Shows in the Data Flow Diagram

This is one of the documents where the quality gap is largest in practice.

Low-tier DFD
Server A → Server B
Medium-tier DFD
Includes protocol and port
High-tier DFD
Data purpose Essentiality Trust boundary Security controls Failure impact
Top-tier DFD — connects all the way to
Essential-function impact Attack scenarios Isolation strategy Recovery strategy Monitoring points

Why Class-Approval Documents and Operational Documents Differ

There is one of the most common misconceptions in practice.

"It passed the class review, so isn't it a good document?"

Half right, half wrong. A class-approval document is written to prove conformity at a specific point in time. An operational document is used for actual decision-making when an incident occurs. The very purpose is different.

Take an Asset Inventory, for example. For a class-approval document, the following may be sufficient:

Class-approval needs
Equipment name
Manufacturer
IP address
Installation location
Operations needs
Scope of impact in case of failure
Recovery priority
Maintenance owner
Supplier contact chain
Backup location
Alternative operating procedures

In other words, class checks "what exists." The operating organization checks "what to do if a problem arises."

The same goes for the Network Diagram. A review-response diagram shows the connection structure. An operational diagram shows the impact. A high-tier organization can answer the following questions:

If this network segment fails, what stops?
If this firewall rule is removed, which function is affected?
If this supplier's VPN is blocked, which system is affected?

This is what a document from the operational perspective looks like.


The Most Dangerous Check-Box Culture in E26 Projects

The biggest cause of E26 project failure is not a lack of technology. It is check-box culture. Many projects proceed like this:

☑ Draft Asset Inventory
☑ Complete Risk Assessment
☑ Draft Network Diagram
☑ Draft Data Flow Diagram
☑ Draft Backup Policy
☑ Draft Remote Access Procedure
☑ Collect Vendor Requirements
☑ Obtain class approval
Project complete.

But the important questions are missing.

? Is the Asset Inventory accurate?
? Does the Risk Assessment reflect the actual system?
? Does the DFD explain actual communications?
? Can the backup be recovered?
? Are the suppliers actually being controlled?
Check-box culture removes questions. And the moment questions disappear, resilience disappears too.

Looking at real incident cases, problems caused by the absence of documents are far outnumbered by problems caused by documents that existed but could not be used.

Backup policy exists Check-box complete No recovery test Ransomware strikes Recovery fails
Firewall policy exists Check-box complete Actual rule: any-to-any Attack spreads Containment fails
Supplier security requirements exist Check-box complete Shared accounts in use Tracing fails

Every check-box was filled. But resilience does not exist.


What a Truly High-Quality Deliverable Is

A high-quality deliverable is not long in page count. Rather, it is a document that can answer the following questions:

Why does this system exist?
Which essential function does it support?
If a failure occurs, what is affected?
How will it be isolated?
How will it be recovered?
Who is responsible?
Can the operating organization maintain it?

From the E26 perspective in particular, a good deliverable must be able to explain the following four things:

Operability
Is it operable?
Maintainability
Is it maintainable?
Recoverability
Is it recoverable?
Traceability
Can changes and incidents be traced?

The Deliverables That Will Be Required Going Forward

Recently, the USCG introduced a performance-based inspection regime. Regulators are increasingly beginning to look not at "do the documents exist?" but at "does it actually work?" Cybersecurity is moving in the same direction.

The questions of the future will be different.

"Is there an Asset Inventory?"
"Can you perform impact analysis using the Asset Inventory?"
"Is there a Backup Procedure?"
"Can recovery be done within 48 hours?"
"Is there a Network Diagram?"
"Can you explain the path of attack propagation?"
"Is there a DFD?"
"Can you explain the essential-function impact?"

Conclusion

The quality of E26 deliverables is not determined by the volume of documents. It is determined by whether they can explain resilience.

Low Low-tier documents record existence.
Med Medium-tier documents describe the current state.
High High-tier documents describe failures and their impact.
Top Top-tier documents support operation and recovery.

And maritime cybersecurity going forward will increasingly demand top-tier deliverables. Because what regulators and owners want to know is not "do the documents exist?" but "can this vessel survive even under a real attack or failure?"

The purpose of E26 is not certification. It is resilience.

And a good deliverable becomes the most powerful evidence of that resilience.

#IACSURE26 #CyberResilience #MaritimeCybersecurity #DeliverableQuality #AssetInventory #DataFlowDiagram #Newbuilding
Julius
Julius
Maritime Technical Consultant · Shipboard Cybersecurity & Compliance

A maritime cybersecurity and compliance specialist across the ship design & build lifecycle, focused on cybersecurity architecture, governance, and regulatory conformity for the shipbuilding and offshore sectors.

🌐 More Articles ↗


⚓ Join the ShipPaulJobs Community

Join →
Share

Comments