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?

Over the past year, 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.

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.

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.

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.

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:

• The affected essential function
• Alternative operating procedures
• Recovery sequence
• The 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:

• Equipment name
• Manufacturer
• IP address
• Installation location

But the operating organization wants:

• The scope of impact in case of failure
• Recovery priority
• The maintenance owner
• The 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.

Not “is there an Asset Inventory?” but “can you perform impact analysis using the Asset Inventory?”

Not “is there a Backup Procedure?” but “can recovery be done within 48 hours?”

Not “is there a Network Diagram?” but “can you explain the path of attack propagation?”

Not “is there a DFD?” but “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-tier documents record existence.
• Medium-tier documents describe the current state.
• High-tier documents describe failures and their impact.
• 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.