If CSDD is rushed during construction, SCARP falls apart after delivery of Vessel.
Skip on CSDD During Construction, and SCARP Collapses After Delivery
What Shipowners Need to Verify Right Now
"The ship has been delivered, and we received all the cybersecurity paperwork — so we're done." Many shipowners think this way. But under the IACS UR E26/E27 framework, delivery is not the end — it's the beginning. Before the first Annual Survey after delivery, the shipowner must prepare a Ship Cyber Security and Resilience Program (SCARP) and submit it to the classification society, then present evidence of its implementation every year thereafter.
The problem is that SCARP is not written from scratch. SCARP inherits the Cyber Security Design Description (CSDD) that the shipyard and Systems Integrator prepared during construction, and extends it into an "operational version." In other words, if the CSDD is weak, SCARP will inevitably be weak too — and the shipowner ends up paying that price years later, standing in front of the surveyor at an annual survey.
Ⅰ. CSDD and SCARP Are One and the Same
The UR E26 documentation structure makes this link explicit.
- 1 Design & construction phase — The Systems Integrator prepares the Zones and Conduit Diagram, Vessel Asset Inventory, and CSDD, and submits them to the classification society (E26 §5.1.1–5.1.3)
- 2 Commissioning & delivery — The Systems Integrator updates these documents to "as-built" versions and submits them to the classification society (E26 §5.2, item 1)
- 3 Operational phase — The shipowner prepares SCARP based on these as-built documents (12 management items: configuration management & software updates, security zones & firewalls, malware protection, access control & confidential information, remote access, mobile/portable devices, anomaly detection, verification, incident response, and recovery planning) (E26 Appendix I, §4.1–4.5)
- 4 1st Annual Survey — The classification society verifies, through records/evidence, that the processes described in the approved SCARP are actually being implemented (E26 §5.3.1)
The key point is that each SCARP management item is designed to directly reference specific CSDD content. For example, only if the CSDD clearly identifies which CBSs allow remote access and describes their security measures, can SCARP describe a concrete "remote access management procedure." If the CSDD is vague, SCARP inevitably ends up vague too — and surveyors pinpoint that gap precisely.
Ⅱ. CSDD ↔ SCARP Consistency (Inline) Mapping
To keep "one and the same" from staying an abstract claim, here is a direct mapping — by UR E26 requirement item — between what must be written in the CSDD (the what, at design time) and the management procedure it feeds into in SCARP (the how, during operation). This correspondence is designed in IACS UR E26 Appendix I & II to be effectively 1:1.
| UR E26 Item | CSDD Content (Design phase) | SCARP Content (Operation phase) | Clause Ref. |
|---|---|---|---|
| 4.2.1 Security Zones & Network Segmentation |
CBS composition per security zone; purpose/protocol/data flow of inter-zone communication; boundary device (firewall) rule specification | Security zone boundary device management procedure — least functionality principle, allowed traffic list, DoS prevention, security audit log review | 4.2.1.4.4 |
| 4.2.3 Malware Protection |
Supplier-provided anti-malware mechanism per CBS, update method, required operating conditions & physical safeguards | Anti-virus maintenance & updates, removable media usage procedure, access control, physical safeguard management | 4.2.3.4.4 |
| 4.2.4 Access Control |
CBS location and physical access control (including HMI exception conditions) | Physical/logical access management (including visitors), credential management, least-privilege policy, confidential information management | 4.2.4.4.4 |
| 4.2.5 Wireless Communication |
Method of implementing the wireless network as a separate security zone, boundary devices, and allowed traffic | No separate SCARP item — managed operationally under the 4.2.4 access control / confidential information item | (folded into 4.2.4.4.4) |
| 4.2.6 Remote Access / Untrusted Network Comms |
Identification of CBSs allowing remote access; how each CBS meets the 4.2.6.3 requirements | Remote access user manual, roles/permissions, patch & update procedure, pre-checks for remote software updates, suspension/rollback procedure | 4.2.6.4.4 |
| 4.2.7 Mobile & Portable Devices |
Physical port-blocking measures for CBSs that do not meet UR E27 4.1 item 10 | Policy & procedure, physical port blocking, use restricted to authorized personnel/devices | 4.2.7.4.4 |
| 4.3.1 Network Monitoring |
No Design phase requirement — relies on E27 supplier documentation | Anomaly detection management activities, security audit log review, incident detection procedure — may be described together with 4.4.1 incident response | 4.3.1.4.4 |
| 4.3.2 Verification & Diagnostic Functions |
No Design phase requirement | Security function verification activities, test/maintenance cycle management | 4.3.2.4.4 |
| 4.4.1 Incident Response Plan |
Reference to supplier-provided information (E27 §3.1.8) | Incident response plan — who responds, when, and how; includes procedures for local/manual control (4.4.2), security zone isolation (4.4.3), and expected CBS behavior (4.4.4) | 4.4.1.4.4 |
| 4.4.2 Local & Manual Operation |
Description of cyber protection measures for local control per SOLAS II-1 Reg.31 | Described together within 4.4.1 incident response plan | (folded into 4.4.1.4.4) |
| 4.4.3 Network Isolation |
Isolation method per security zone and specification of isolation impact (dependency on data from other zones) | Folded into the isolation procedure of the 4.4.1 incident response plan | (folded into 4.4.1.4.4) |
| 4.4.4 Fallback to Minimal Risk Condition |
Definition of the safe state per control function | Folded into 4.4.1 incident response plan as expected CBS behavior | (folded into 4.4.1.4.4) |
| 4.5.1 Recovery Plan |
Reference to supplier-provided information (E27 §3.1.8) | Recovery plan — RTO/RPO, backup policy (frequency, retention, testing), reference to shutdown/reset/restore manuals | 4.5.1.4.4 |
| 4.5.2 / 4.5.3 Backup & Restore / Shutdown, Reset & Roll-back |
Reference to shutdown/reset/restore/restart manuals & procedures | Described together within 4.5.1 recovery plan | (folded into 4.5.1.4.4) |
※ Item 4.1.1 (asset inventory / MoC) links not to the CSDD but to the Vessel Asset Inventory and Zones and Conduit Diagram, and is addressed in SCARP §4.1.1.4.4 as Management of Change and software update management.
Ⅲ. Key Principles for Inline Drafting and the SCARP Table of Contents
Five principles to follow when applying the mapping above to actual document work.
- ① Every CBS/security-zone description in the CSDD must exactly match the CBS list covered by the corresponding SCARP management procedure. A mismatch can turn into an observation at the 1st Annual Survey.
- ② CSDD describes "the state at design time (what)"; SCARP describes "how that state is maintained and managed during operation (how)". If SCARP mentions a CBS or security zone not present in CSDD, a consistency problem results.
- ③ The Zones and Conduit Diagram (ZCD) and Vessel Asset Inventory (VAI) must be maintained alongside CSDD, and before drafting SCARP you should first confirm that all three documents (ZCD, CSDD, VAI) match the latest as-built version.
- ④ Because the UR E26 Appendix I table is the authoritative basis that formalizes the CSDD↔SCARP mapping, the safest approach is to structure the SCARP table of contents 1:1 against Appendix I's 12 management items (§4.1.1.4.4–§4.5.1.4.4) under "Ship cyber security and resilience program."
- ⑤ If, at delivery, the design rationale documented in the CSDD's "Design phase" section (firewall rules, zone boundaries, CBSs eligible for remote access, etc.) is directly quoted and referenced at the start of the corresponding SCARP management procedure, surveyors can quickly verify consistency between the "approved design documents vs. SCARP" at the 1st Annual Survey.
Putting principle ④ into practice, the SCARP table of contents takes the following structure.
- 1. Management of Change (MoC) — §4.1.1.4.4
- 2. Management of Software Updates — §4.1.1.4.4
- 3. Security Zone Boundary Devices — §4.2.1.4.4
- 4. Management of Malware Protection — §4.2.3.4.4
- 5. Management of Access Control — §4.2.4.4.4
- 6. Management of Confidential Information — §4.2.4.4.4
- 7. Management of Remote Access — §4.2.6.4.4
- 8. Mobile and Portable Devices — §4.2.7.4.4
- 9. Detection of Security Anomalies — §4.3.1.4.4
- 10. Verification of Security Functions — §4.3.2.4.4
- 11. Incident Response Plans — §4.4.1.4.4
- 12. Recovery Plans — §4.5.1.4.4
Item 11 should be described to include local/manual operation (4.4.2), network isolation (4.4.3), and fallback to minimal risk condition (4.4.4); item 12 should be described to include backup & restore (4.5.2) and shutdown/reset/roll-back (4.5.3).
Ⅳ. What Shipowners Commonly Miss During Construction
Much of the CSDD content is, in the end, assembled and restructured by the Systems Integrator from documents individual equipment/system suppliers provide under UR E27 — security function descriptions, test procedures, maintenance plans, incident response & recovery support information, and so on (supplier certification process: E27 §6). If a supplier fills in these documents only as a formality, that weakness carries straight through from CSDD to SCARP. From the contracting stage, shipowners should clearly specify the required E27 document list for major OT equipment suppliers (propulsion, steering, power, fire-fighting, cargo safety, and other Category II/III systems) and reflect it in the specification.
The Zones and Conduit Diagram and CSDD must specify which security zone each individual CBS belongs to, and which protocol/firewall rules govern communication between zones (E26 §4.2.1 Security Zones and Network Segmentation). With design changes common late in construction, it's not unusual for these documents to remain frozen at the "initial design" stage and diverge from the final as-built condition. The shipowner (or a delegated supervisor) must verify during commissioning that these documents match the actual wiring and network configuration.
The CSDD must specifically identify the list of CBSs that allow remote access and, for each CBS, the multi-factor authentication, session-termination, and logging methods used (E26 §4.2.6 Remote access control, §4.2.7 Mobile and Portable Devices). A merely declarative line such as "remote access is controlled" forces the actual procedure to be invented from scratch when SCARP is drafted — an after-the-fact procedure disconnected from the as-built design, which creates consistency problems during survey.
This gets missed surprisingly often. Under UR E27, suppliers must provide the information needed to build incident response and recovery plans — shutdown/reset/roll-back procedures, RTO/RPO information, and the like (E26 §4.4.1 Incident response plan, §4.5.1 Recovery plan). If this information is never referenced in the CSDD, the shipowner ends up combing through every piece of equipment's manuals from scratch after delivery, just to write SCARP's incident response and recovery plan.
Ⅴ. Why a Dedicated Security SI Is Necessary
This is where a dedicated cybersecurity SI plays a decisive role. A typical shipbuilding systems integrator is skilled at integrating propulsion, power, and navigation systems, but often has no dedicated staff for cybersecurity-specific work such as IEC 62443-based Zone/Conduit design, firewall rule-set design, vulnerability scanning, or penetration/DoS test procedure development. A dedicated security SI performs the following roles.
In other words, the role of a dedicated SI is not simply to "get the regulation passed," but to design the CSDD so that it flows naturally into SCARP. If this work is not done properly during construction, the shipowner ends up spending extra time and money after delivery on separate consulting just to rewrite SCARP.
Ⅵ. A Checklist for Shipowners
We recommend confirming the following during the construction contract and specification negotiation stage.
- ☐ Have you specified in the specification that major OT equipment suppliers are obligated to provide UR E27 documents (security function descriptions, test procedures, maintenance/incident-response support information)?
- ☐ Have you confirmed whether the shipyard or systems integrator uses a dedicated cybersecurity SI, and checked that SI's IACS E26/E27 track record?
- ☐ Does the contract include a procedure to verify that the CSDD matches the as-built condition at the completion of commissioning?
- ☐ Have you separately requested a SCARP draft (or table of contents) based on the CSDD at delivery?
- ☐ Have you confirmed that the cross-references between the Ship Cyber Resilience Test Procedure and the CSDD are clear?
The gap between delivery and the first annual survey is usually just over a year. Rather than writing a massive SCARP from scratch in that short window, securing CSDD quality during construction produces a far more solid result at far lower cost. Cybersecurity is not an item added after delivery — it is something that must be built into the design from the moment the construction contract is signed.
SCARP is not a document written fresh after delivery — it is the operational edition of the CSDD from construction. If the CSDD is weak, the shipowner pays for it years later, standing at the annual survey.
Securing CSDD quality through a dedicated cybersecurity SI from the moment the construction contract is signed produces a far more solid result, at far lower cost, than rewriting SCARP through separate consulting after delivery.
Regulatory Basis & References (IACS UR E26 Rev.1, Nov 2023)
Source: IACS UR E26 Rev.1 (Nov 2023), Section 4 & Section 5. Clause numbers may change in later revisions — please confirm against the latest revision before applying this to an actual project.
Related Reading:
- UR E26, After the Mandate ② — The Owner's View: Where Obligation Ends and Choice Begins
- The Cyber Resilience System Integrator and the Six Core Ship-Level Deliverables
- Why Most Ship ZCDs Fail — Seven Common Mistakes in IACS UR E26/E27 Projects
- From Networks to ZCD — Translating Physical and Logical Networks into IACS UR E26 Documentation
- OT Asset Management for Ships: Complete Technical Guide
Richard is a principal maritime engineering leader driving digital ship innovation and cybersecurity from ship operations to automation. His expertise spans naval architecture, ICS/OT security, offshore system design, vessel automation, IACS UR E26/E27 compliance, and smart ship & digital twin technologies — bringing an integrated systems perspective across a vessel's IT and OT infrastructure.
⚓ Join the ShipPaulJobs Community
Join →
Comments
Post a Comment