CSDD & Exclusion Assessment
UR E26 §5.1.1 & §6: The Cyber System Definition Document (CSDD) is the mandatory technical file submitted for Class approval. It defines the “Trust Boundary” of the vessel. Section 6 provides the framework for Risk-Based Exclusion, allowing non-critical systems to be removed from scope if they pose no threat to safety functions.
1. Assembling the CSDD (The Submission File)
The CSDD is your vessel’s “Master Blueprint.” It proves to the Auditor that you have Identified your assets correctly. Your CSDD must include these three core pillars:
Must show physical cabling (Ethernet/Serial) and logical zones. Highlight all “Conduits” crossing between IT and OT environments.
Comprehensive list including firmware versions. All software must be cross-referenced against the Vulnerability Feed.
Identify critical protocols (Modbus, NMEA, S7). This matrix defines the “Blast Radius” in the event of a cyber incident.
1.1 CSDD Checklist for Class Submission
Before submitting your technical file to the Class Society, verify that these specific data points are documented to avoid RFI (Request for Information) delays.
| [ ] | Boundary Logic | Are all Firewalls/Diodes identified by physical location and port mapping? |
| [ ] | Dependency Impact | Does the CSDD list the ‘System Criticality’ for every asset found in the inventory? |
| [ ] | Vendor Data Flow | Are NMEA/Modbus/Proprietary flows mapped between different OEM systems? |
| [ ] | Software Baseline | Is there a ‘Frozen’ firmware version listed for all Category II & III components? |
Universal CSDD Index (IACS UR E26 Compliant)
This hierarchical structure fulfills the Cyber Security Design Description requirements for all major Classification Societies. Use this index to organize technical evidence for the design and construction phase.
- 1.1 Security Zone & Profile Allocation
- 1.2 System Supplier & Functional Data
- 1.3 Physical Access & Asset Locations
- 2.1 Intra-Zone Communication Matrix
- 2.2 Boundary Device & Firewall Rules
- 2.3 Untrusted Network Interfaces
- 3.1 Malicious Code Protection (AV/EDR)
- 3.2 Remote Access Control (RAG)
- 3.3 Wireless Security Implementation
- 4.1 Safe Shutdown & Reset Procedures
- 4.2 System Restore & Backup Strategy
- 4.3 Recovery Manual References
- 5.1 Type Approval (TAC) Certificates
- 5.2 Supplier UR E27 Compliance Docs
- 5.3 Technical Justifications
- 6.1 Excluded System Registry
- 6.2 Negligible Risk RA Evidence
- 6.3 Final Class Review Justification
2. Scope Exclusion Logic (DNV F011/F021 & UR E26)
Use this decision matrix to determine if a system or component can be excluded from mandatory security requirements. Per DNV F011, any proposed exclusion must be supported by a Risk Assessment demonstrating Negligible Risk.
| System / Component | Essential Function Test | Connectivity & Logic Test | Requirement Result |
|---|---|---|---|
| Stand-alone Entertainment | Does not support safety, propulsion, or environmental protection. | No physical or logical connection to any OT or Essential networks. |
POTENTIAL EXCLUSION Requires RA “Negligible Risk” Score |
| Passenger Wi-Fi (Hotel) | Non-essential function, but uses shared infrastructure. | Shares a physical conduit or boundary device with the Nav Zone. |
MANDATORY SCOPE In scope due to Shared Conduit |
| Non-Critical Sensor (in AMS) | Component of an Essential System (AMS). | Discrete signal only; cannot be used to pivot or impact the CBS logic. |
COMPONENT EXCLUSION F021 RA justification required |
| Integrated Control System | Directly supports Essential Functions (Propulsion/Safety). | Core CBS logic; integrated across multiple zones. |
FULL MANDATORY SCOPE Exclusion forbidden by UR E26 |
Strategic Intelligence: The “Maintenance Port” Trap
Auditors often reject exclusions for systems that appear isolated but have a “Remote Maintenance Port”. If an OEM can dial into a system, it is logically connected to the external world. Always audit the Physical Layer (Layer 1) before claiming Section 6 exclusion.
2.1. Risk-Based Exclusion Checklist
To qualify for exclusion under DNV-CG-0325 or UR E26 Section 6, you must provide evidence for the following five points:
- Logical Isolation: No IP-network communication. No remote access.
- Physical Control: System is in a locked, restricted area.
- Port Lockdown: No physical ports (USB/RJ45) accessible to unauthorized personnel.
- Non-Criticality: System is not needed for Propulsion, Steering, or Power.
- No Integration: The system is not an Integrated Control System (ICS).
Class Evidence Tip
DNV and other Class Societies require that any “Negligible Risk” claim be supported by a technical justification. You must prove the system has a minimized attack surface and no potential impact on safety functions.
Compliance Documentation Previews
Standardized templates and technical logs. View watermarked previews below; premium SOPs and fillable forms require the Pro Bundle.
Next Section
Audit Evidence Templates
Phase 1: Identify All vessels Satisfies: E26 §5.1 IEC 62443-2-4 IMO MSC-FAL.1 All vessels Audit Evidence Templates The ...
