This guide defines the process for updating the Ship Cyber Security and Resilience Programme (SCSRP) and CSDD following a cyber incident, a system change, or a new threat — keeping the plan current, accurate, and Class-approved. Under IACS UR E26 §4.4.1 and §4.5.3, the vessel must maintain a living document that reflects actual system state — not the state at initial commissioning.
A cyber incident reveals specific weaknesses in the vessel’s defences. A system change creates new risks that the current plan may not address. Both require a formal update to the SCSRP and — where the network architecture or CBS scope changes — an amendment to the CSDD submitted to Class. This is not optional housekeeping — an outdated CSDD is a Class finding at the next survey.
What triggers a plan update
Three categories of event require a formal SCSRP update. The first two also require a CSDD amendment submitted to Class.
Category 1 — Post-incident
After any Level 2 or Level 3 incident
Root cause identified and documented
Attack vector used is now closed
New threat intelligence added to plan
Response procedures updated based on lessons learned
Recovery time actual vs RTO target — adjust if needed
CSDD amendment required if any CBS scope or network topology changed during or after the incident.
Category 2 — System change (MoC)
Any Management of Change event
New CBS added to or removed from the vessel network
Firmware or software major version update on Cat II/III system
Network topology change — new VLAN, new firewall rule, new conduit
New OEM remote access capability enabled
Change in security zone assignment for any CBS
CSDD amendment required for all topology or CBS scope changes — submit to Class before change is made permanent.
Category 3 — Periodic review
Scheduled review regardless of incidents
Annual review as part of ISM DOC audit preparation
Pre-survey review before Class annual or special survey
New IACS UR E26/E27 revision published
New IMO circular or MSC-FAL revision issued
Significant new CVE published for a vessel’s CBS
CSDD amendment only required if review identifies a discrepancy between current CSDD and actual vessel state.
SCSRP update checklist — what to review after each trigger
Work through this checklist for every plan update. Not every item will require a change — but every item must be actively reviewed and confirmed current or updated.
Incident Response Plan (§4.4.1) — Does the plan correctly reflect the attack vector used? Are new detection indicators added? Are notification timelines and contacts still accurate?
CBS Register — Does the register reflect the current CBS inventory? Any systems added, removed, or recategorised during the incident or MoC event must be updated before the next survey.
Software & firmware register — Updated with new firmware versions post-recovery · new CVE entries for affected systems · updated patch status for all Cat II and III CBS.
RTO and RPO values — Did the actual recovery time exceed the documented RTO? If so, the RTO must be revised upward or the recovery capability must be improved to meet the existing target. Both options require documentation.
Golden Image baseline — Is the Golden Image for affected systems updated to the post-recovery clean state? An outdated Golden Image will reintroduce the same vulnerability in any future recovery.
Access control review — Were any credentials compromised during the incident? All service accounts on affected systems must be rotated. OEM remote access sessions must be reviewed and any lingering sessions terminated.
Crew awareness training — Did the incident involve a crew-introduced vector (USB, phishing, credential sharing)? The relevant crew awareness module must be re-delivered and attendance logged before the next sailing.
Vendor and third-party protocols — Did the incident involve an OEM connection or a vendor-supplied device? Update the Third-Party Access SOP to include mandatory scanning, revised SEP requirements, or additional monitoring for that vendor.
CSDD amendment — submission process
When a CSDD amendment is required, the process must follow the vessel’s MoC procedure. A CSDD change submitted informally without MoC documentation is not valid for Class purposes.
1
Raise a MoC form (TAG-OT-MOC-01) — Document what changed, why it changed, what risk assessment was performed, and what compensating controls are in place. The MoC form is the audit trail that demonstrates the change was controlled.
2
Update the CSDD document — Revise the relevant sections: zone/conduit diagram if topology changed, CBS register if systems changed, data flow matrix if communication paths changed, exclusion register if scope changed. Increment the document version number and update the revision date.
3
DPA reviews and approves — The DPA must sign off the updated CSDD before submission to Class. Changes submitted without DPA approval are not considered company-authorised amendments under ISM Code.
4
Submit to Class Society — Transmit the updated CSDD with the MoC reference number to the Class surveyor responsible for the vessel. Request written acknowledgement of receipt — this acknowledgement is your evidence of timely notification.
5
File and retain — The MoC form, revised CSDD, DPA sign-off, and Class acknowledgement must be retained together as a package. Minimum retention period aligns with ISM records requirements — typically 3 years or the next special survey, whichever is longer.
Final audit sign-off
Under IACS UR E26 §4.5.3, the final step of recovery is verifying that the system is restored to a safe, consistent, and known state. To prove this to a surveyor, the ETO must present:
Evidence item
Regulatory alignment
Who signs
Cyber Incident Log — complete
E26 §4.4.1 — detailed record of incident and all response actions with timestamps
ETO + Master
System restoration verification checklist
E26 §4.5.3 — signed confirmation systems are in safe operational state
ETO + Chief Engineer
Updated CSDD with revision history
E26 §4.2.1 — current network architecture and CBS register reflecting post-incident state
DPA
MoC form with Class acknowledgement
ISM Code §10 — controlled change management with documented Class notification
DPA + Class surveyor receipt
Post-incident debrief record
E26 §4.4.1 — evidence that lessons learned were captured and fed into plan update
ETO + Master + DPA
Continuity of resilience
The end of the Recover phase is not the end of the journey. Updated threat intelligence, revised RTOs, new firmware baselines, and improved access controls all feed immediately back into the IDENTIFY phase — creating a continuous improvement loop that keeps the vessel ahead of evolving threats.
A Class surveyor reviewing your file at the next annual survey is not just checking that an incident happened and was resolved. They are checking that the plan was updated, the CSDD was amended, and the lessons were demonstrably incorporated. A complete update package is your evidence of a functioning cyber management system — not just a one-time recovery.
The specific regulatory requirements this playbook satisfies. Use these references when preparing for Class survey or responding to a surveyor's checklist.
E26 §4.4.1
Incident response plan — An incident response plan must be in place covering how to detect, respond to, and limit the consequences of a cyber incident. It must be kept in hard copy on board.
E26 §4.5.3
Controlled shutdown, reset, rollback and restart — Systems must support: controlled shutdown leaving integrated systems in a safe state; reset to initial state; rollback to a previous configuration; and clean restart from a read-only source.
E27 §3.1.9
Management of change plan — A procedure describing how modifications to the CBS are controlled, reviewed and documented. Expected to align with the existing UR E22 management of change process.
