The IACS UR E26/E27 Documentation Playbook
What newbuild shipyards, suppliers and owners must submit to the classification society, phase by phase, under IACS UR E26 Rev.1 and UR E27 Rev.1. Written as a working reference: every statement is anchored to the clause that requires it.
For vessels contracted for construction on or after 1 July 2024, IACS UR E26 and E27 make cyber resilience a condition of class. E26 targets the ship: the shipyard, acting as systems integrator, must submit five vessel-level documents during design and a Ship cyber resilience test procedure at commissioning, then demonstrate the result on board to a surveyor. E27 targets the systems: every in-scope supplier must deliver up to ten documents per computer based system (CBS) and demonstrate 30 required security capabilities, plus 11 more where the system talks to untrusted networks. The shipowner inherits the whole set at delivery and must keep it alive through annual and special surveys. This playbook maps who owes which document, to whom, at which phase, and what each document must contain, with clause references you can hand to a plan approval engineer.
Does E26/E27 apply to your project?
Three questions settle it.
1. When was the ship contracted?
Both URs apply to ships contracted for construction on or after 1 July 2024. The contract date is the date the shipbuilding contract is signed between the prospective owner and the shipbuilder; IACS Procedural Requirement No. 29 governs edge cases such as options and major conversions. For earlier ships, both URs may be applied as non-mandatory guidance. E26 Note 2 and Note 3 E27 Note 2 and Note 3
2. Is the vessel type in scope?
E26 1.3.1 E27 1.3
| Mandatory | Non-mandatory guidance |
|---|---|
| Passenger ships, including passenger high-speed craft, on international voyages | Ships of war and troopships |
| Cargo ships of 500 GT and upwards on international voyages | Cargo ships under 500 GT |
| High-speed craft of 500 GT and upwards on international voyages | Vessels not propelled by mechanical means; wooden ships of primitive build |
| Mobile offshore drilling units of 500 GT and upwards | Passenger yachts (not more than 12 passengers); pleasure yachts not engaged in trade |
| Self-propelled mobile offshore units engaged in construction (wind turbine installation, crane units, drilling tenders, accommodation and similar) | Fishing vessels; site-specific offshore installations (FPSOs, FSUs) |
3. Which systems are caught?
E26 1.3.2 scopes in the OT systems serving, if present on board: propulsion; steering; anchoring and mooring; electrical power generation and distribution; fire detection and extinguishing; bilge and ballast systems and the loading computer; watertight integrity and flooding detection; lighting; and any required safety system whose disruption may pose risks to ship operations, such as emergency shutdown, cargo safety, pressure vessel safety and gas detection. Statutory navigational systems and class- or statute-required internal and external communication systems are added explicitly, and so is every IP-based interface from an in-scope CBS to anything else, including passenger-facing, administrative and crew welfare networks and temporary maintenance connections.
Two consequences follow. First, scope is decided by function, not by how a system is marketed; a packaged crane control PLC is in scope the moment it serves a listed function. Second, the IP-interface rule means the boundary of the analysis is wider than the OT systems themselves: anything they touch must at least appear in the zone design as an untrusted network.
Exclusions are earned, not declared.
A CBS inside scope can only be excluded through a documented risk assessment under E26 section 6, and the acceptance criteria are strict: no IP connections to other systems, no accessible physical interface ports, controlled physical access, and not an integrated control system serving multiple scoped functions E26 6.4. The risk assessment is itself a submitted document E26 5.1.4. “We did not connect it” is an argument you must evidence, not assert.
Navigation and radiocommunication equipment
has a parallel path: the Society may accept IEC 61162-460 or other equivalent standards in lieu of the E27 section 4 capabilities, on the condition that E26 is still complied with, and such systems should sit in a dedicated security zone E26 1.3.2 E26 4.2.1.3.
Who owes what: the four-party split
| Party | Owes | Key references |
|---|---|---|
| Supplier | Up to ten documents per CBS (3.1.1 to 3.1.10), demonstration of the section 4 capabilities at survey and factory acceptance test, and a System certificate per CBS; approved documents are handed to the systems integrator | E27 sections 3, 4, 6 |
| Systems integrator (the shipyard by default) | The five vessel-level design documents (E26 5.1.1 to 5.1.5), as-built updates, the Ship cyber resilience test procedure, and the witnessed on-board test campaign | E26 sections 5.1, 5.2 |
| Shipowner | The Ship cyber security and resilience program before the first annual survey, then evidence of implementation at every annual survey and re-testing at special survey | E26 section 5.3 |
| Classification society | Plan approval of submitted documents, witnessing of FAT and on-board testing, the decision on any SCRTP test omission, and acceptance of any exclusion | E26 sections 5, 6E27 section 6 |
The definition that decides most arguments: the systems integrator role “shall be taken by the Shipyard unless an alternative organization is specifically contracted/assigned this responsibility”, and it runs until vessel delivery E26 section 2, Systems Integrator. If the shipbuilding contract is silent, the yard owns E26 compliance by default. Yards should budget for that obligation; owners should check the contract names someone.
A second handoff matters at the end: upon delivery, the systems integrator must hand the shipowner both the approved supplier documentation and everything the integrator produced under 5.1 and 5.2 E26 section 5. An owner who does not receive that package at delivery starts the operational phase already behind.
The vessel-level document set (E26 5.1)
Five documents, submitted by the systems integrator for plan approval during design, kept current through construction, and resubmitted as-built before commissioning E26 5.1 E26 5.2.
1. 5.1.1, content per 4.2.1.4.1
Zones and conduit diagram
The ship's CBSs grouped into security zones, every CBS allocated and physically located, communication inside zones, conduits between zones, and every conduit to untrusted networks. It must reference the approved versions of each supplier's topology diagrams (E27 3.1.2), which is why it cannot be finalized before supplier documentation exists. Design rules it must embody: safety-function CBSs in their own physically segmented zones; navigation and communication systems never in the same zone as machinery or cargo systems; wireless devices in dedicated zones; untrusted networks physically segmented or brought up to zone requirements (4.2.1.3).
2. 5.1.2
Cyber security design description, the CSDD
The written argument that the design meets section 4, assembled from the "Design phase" items of every requirement: zone-by-zone descriptions and permitted boundary traffic including firewall rules (4.2.1.4.1), malware protection summary per CBS (4.2.3.4.1), physical access control locations (4.2.4.4.1), wireless zone descriptions (4.2.5.4.1), every CBS that is remotely accessible and how 4.2.6.3 is met (4.2.6.4.1), CBSs needing physical port blocking (4.2.7.4.1), protection of SOLAS II-1 Reg. 31 local control (4.4.2.4.1), zone isolation methods and their effects (4.4.3.4.1), safe states per control function (4.4.4.4.1), and references to supplier information supporting incident response and recovery (4.4.1.4.1, 4.5.1.4.1, 4.5.3.4.1).
3. 5.1.3, content per 4.1.1
Vessel asset inventory
Hardware and software of every in-scope CBS and the networks connecting them, at the field level of E27 3.1.1, incorporating every supplier's CBS asset inventory plus anything the integrator itself delivers. It must be kept updated for the life of the ship, and confidential content such as IP addresses demands restricted handling (4.1.1.3).
4. 5.1.4, content per section 6
Risk assessment for the exclusion of CBSs
Only if exclusions are claimed. Must evidence the acceptance criteria above and analyze vulnerabilities, threats, impacts and the attack surface of each excluded CBS.
5. 5.1.5
Description of compensating countermeasures
Only if any CBS was approved with compensating countermeasures in lieu of an E27 requirement: which CBS, which missing capability, and a detailed description of the countermeasure. Mirrored on the supplier side in E27 3.1.3, and the SCRTP must include tests for every compensating countermeasure (5.2.1).
The supplier package (E27 3.1): ten documents per CBS
| # | Document (exact UR name) | Review | When required |
|---|---|---|---|
| 3.1.1 | CBS asset inventory | Approval | Always |
| 3.1.2 | Topology diagrams (physical and logical) | Approval | Always |
| 3.1.3 | Description of security capabilities | Approval | CBS without type-approved capabilities |
| 3.1.4 | Test procedure of security capabilities | Approval | CBS without type-approved capabilities |
| 3.1.5 | Security configuration guidelines | Information | CBS without type-approved capabilities |
| 3.1.6 | Secure development lifecycle documents | Approval, upon request | CBS without type-approved capabilities |
| 3.1.7 | Plans for maintenance and verification of the CBS | Information, upon request | CBS without type-approved capabilities |
| 3.1.8 | Information supporting the owner's incident response and recovery plan | Information, upon request | CBS without type-approved capabilities |
| 3.1.9 | Management of change plan | Information, upon request | CBS without type-approved capabilities |
| 3.1.10 | Test reports | Information | CBS with a Type Approval certificate |
Review classes per E27 Appendix II. A valid Type Approval certificate covering the E27 capabilities reduces the set: the supplier submits the two always-required documents plus signed test reports demonstrating completed design, construction, testing, configuration and hardening, and survey may be waived, per E27 3.1.10 and 6.2.
What plan approval actually checks in the two load-bearing documents:
3.1.3 Description of security capabilities: one designated chapter per requirement, every hardware and software component addressed, every interface to other in-scope CBSs described with destination, data flows and protocols, every untrusted-network interface described against the section 4.2 capabilities, and any requirement not fully met declared with a proposed compensating countermeasure that protects against the same threats, provides an equal level of protection, is not already required elsewhere, and does not introduce higher risk.
3.1.4 Test procedure of security capabilities: per requirement, the test setup, equipment, initial conditions, detailed steps, expected results and acceptance criteria, with means to record results and findings. This is the document FAT runs on E27 6.3.2, so vagueness here surfaces as dispute in front of a surveyor.
The certification flow E27 section 6, Figures 1 and 2: determine whether E27 is mandatory for the CBS, then either the type-approval path or project-specific plan approval plus witnessed survey and FAT; both end in a ship-specific System certificate, and the approved documents travel with the CBS to the systems integrator.
The 41 capabilities: 30 required, 11 for untrusted networks
E27 section 4 defines the security capabilities a CBS must demonstrate, drawn from IEC 62443-3-3 system requirements. Section 4.1 Table 1 lists the 30 required for every in-scope CBS; section 4.2 Table 2 adds 11 more only where the CBS communicates with untrusted networks, meaning any network outside the scope of UR E26. There is no flat list of 41: a serial-only engine controller with no outside interface answers 30, a remotely maintained system answers all 41.
The 30 required capabilities, by the UR's own objective groupings: identification and authentication (items 1 to 7: human user identification and authentication, account management, identifier management, authenticator management, wireless access management, password strength, authenticator feedback); use control and audit (items 8 to 16: authorization enforcement with least privilege and segregation of duties, wireless use control, use control for portable and mobile devices, mobile code control, session lock, auditable events, audit storage capacity, response to audit processing failures, timestamps); system integrity (items 17 to 20: communication integrity, malicious code protection, security functionality verification, deterministic output); data confidentiality (items 21 and 22: information confidentiality, use of cryptography); audit access (item 23: audit log accessibility); and resource availability (items 24 to 30: denial of service protection, resource management, system backup, system recovery and reconstitution, alternative power source, network and security configuration settings, least functionality).
The 11 additional capabilities for untrusted-network communication (items 31 to 41): multifactor authentication for human users, software process and device identification and authentication, unsuccessful login attempt limits, system use notification, monitored and controlled access via untrusted networks, explicit access request approval by personnel on board, remote session termination, cryptographic integrity protection, input validation, session integrity, and invalidation of session IDs after termination.
Two integration notes that routinely surprise project teams. First, E26 4.2.6.3.2 independently requires multifactor authentication for any human access to in-scope CBSs from an untrusted network, remote connections that must be explicitly accepted on board, logging of remote sessions, and the ability to interrupt, abort and roll back remote maintenance. These land on the vessel design even where an individual supplier scoped them out. Second, evidence type varies by capability: a majority of the 41 can be evidenced on documentation and configuration review, while the remainder need witnessed functional testing, which is exactly why the 3.1.4 test procedure and the SCRTP must be planned together.
Commissioning and the Ship cyber resilience test procedure (E26 5.2)
Before final commissioning, the systems integrator must do three things E26 5.2: submit as-built versions of the 5.1 documents, submit the Ship cyber resilience test procedure (SCRTP), and carry out the testing on board, witnessed by the Society, after other commissioning activities for the CBSs are complete.
The rules that decide how much testing a yard actually faces, all from 5.2.1:
All tests go into the SCRTP. Security functions already tested during CBS certification under E27 may be candidates for omission, but only where the relevant "Commissioning phase" subsection says so, and "the decision to omit tests will be taken by the Society". The yard proposes; class disposes.
Omission is generally unavailable in three cases: findings or comments carried over from the certification process, requirements met by compensating countermeasures, and modifications of the CBS after certification.
Some demonstrations are vessel-level by nature and cannot be inherited from any FAT: that security zones are implemented as approved, verified by inspection, network scanning or other methods; that zone boundaries pass only documented traffic, verified by firewall rule evaluation or port scanning; that required local controls operate with all networks disconnected; and that remote access controls behave as approved end to end (4.2.1.4.3, 4.4.2.4.3, 4.2.6.4.3).
Format is prescribed: per test, the setup, equipment, initial conditions, methodology and detailed steps, expected results and acceptance criteria, plus means to update status and record findings during testing. Before submission the integrator must verify the SCRTP is under change management and aligned with the latest CBS and network configurations.
Plan the SCRTP as a living index of every requirement's commissioning demonstration, each line carrying its evidence source: certified at FAT with certificate and report reference, or to be tested on board. That single structure answers the surveyor's first question, “why is this test not being run”, with the UR's own logic.
After delivery: what the owner must keep alive (E26 5.3)
Before the first annual survey: the shipowner submits the Ship cyber security and resilience program, the management-system document covering, at minimum: management of change, management of software updates, management of security zone boundary devices such as firewalls, malware protection, access control, confidential information, remote access, mobile and portable devices, detection of security anomalies, verification of security functions, incident response plans, and recovery plans (E26 5.3.1 and Appendix I). The incident response plan must be on board in hard copy, with breakpoints for isolating compromised systems and response options that do not rely only on shutdown (4.4.1.3); the recovery plan must specify recovery time and recovery point objectives (4.5.1.3).
At the first annual survey: records demonstrating the program is implemented, not merely written.
At subsequent annual surveys: the same demonstration upon request.
At special survey: re-testing witnessed by the Society in accordance with the SCRTP, which the owner, with supplier support, must have kept updated against changes, new threats and new vulnerabilities (E26 5.3, 5.3.3).
Throughout: modifications follow the management of change requirements of UR E22, documentation stays current, and a change of vessel management company triggers a new verification of the program (5.3.1).
The practical consequence for yards and owners negotiating delivery: the operational phase runs on documents created during build. An inventory that drifted during construction, or supplier 3.1.8 recovery information that was never collected, becomes the owner's survey finding years later.
The build-phase timeline
| Phase | Systems integrator (shipyard) | Supplier | Shipowner |
|---|---|---|---|
| Design | Submit zones and conduit diagram, CSDD, vessel asset inventory, and where applicable the exclusion risk assessment and compensating countermeasures description | Submit CBS documents for plan approval; begin certification path (type approval or project-specific) | Name the systems integrator in the contract if not the yard |
| Construction | Maintain all five documents under management of change; prevent unauthorized access to CBSs; keep malware protection updated | Complete survey and FAT, witnessed; System certificate issued; deliver approved documents to the integrator | |
| Commissioning | Submit as-built documents and the SCRTP; execute witnessed on-board testing | Support testing; close carried-over findings | |
| Delivery | Hand over supplier documentation and all integrator documentation | Receive and verify the complete package | |
| First annual survey | Submit the Ship cyber security and resilience program; demonstrate implementation | ||
| Annual surveys | Provide security updates and compatibility information (E27 5.2 to 5.4) | Demonstrate implementation upon request | |
| Special survey | Support re-testing | Execute SCRTP re-testing, witnessed |
Ten failure patterns to design out
- 1No one is named systems integrator. The role defaults to the yard (E26 section 2); yards that have not priced the five-document obligation discover it at plan approval.
- 2Supplier documents arrive as brochures. The 3.1.3 description requires a chapter per requirement across all 30, or 41, capabilities; marketing PDFs fail plan approval and stall the zones and conduit diagram that depends on approved topologies.
- 3Zones drawn after the network is built. Physical segmentation of safety zones (4.2.1.3) is a cable-routing and cabinet decision; retrofitting it at commissioning is yard-schedule poison.
- 4The inventory diverges from the ship. Commissioning requires demonstrating the inventory is updated, complete and correct at delivery (4.1.1.4.3); an inventory maintained in slideware fails a network scan comparison.
- 5Exclusions asserted, not evidenced. Section 6 acceptance criteria are specific: no IP connections, no accessible ports, controlled access, not an integrated multi-function system. Each needs evidence in the 5.1.4 risk assessment.
- 6Compensating countermeasures treated as waivers. They must match the original requirement's intent and rigor, be declared in 3.1.3 and 5.1.5, and be tested in the SCRTP. They add test scope; they do not remove it.
- 7Untrusted-network capabilities scoped out by the wrong party. A supplier may deliver a CBS with no untrusted interface, but the moment the vessel design adds remote maintenance, items 31 to 41 and E26 4.2.6 land on the integration.
- 8SCRTP omissions assumed. Omission is the Society's decision, test by test, and is generally unavailable for carried-over findings, compensating countermeasures and post-certification modifications (5.2.1).
- 9Remote access designed without the on-board half. Explicit acceptance on board, session logging, interrupt and rollback, and MFA are vessel-level requirements (4.2.6.3); a vendor VPN alone does not answer them.
- 10The delivery handover is informal. E26 section 5 obliges the integrator to hand the owner the full approved set; owners should make that package a delivery deliverable with a completeness check, because the first annual survey assumes they have it.
Two working checklists
Checklist A: integrator's plan approval submission E26 5.1
- ✓Zones and conduit diagram: every in-scope CBS allocated to a zone; physical locations shown; references to approved supplier topology diagram versions; intra-zone, inter-zone and untrusted conduits all illustrated
- ✓CSDD: a design-phase answer for every section 4 requirement; boundary devices and permitted traffic specified per conduit; safe states specified per control function; zone isolation effects described
- ✓Vessel asset inventory: E27 3.1.1 fields for hardware and software; integrator-delivered equipment included; confidentiality handling defined
- ✓Exclusion risk assessment: present only if exclusions claimed; section 6.4 criteria evidenced per CBS
- ✓Compensating countermeasures description: present only if any CBS was approved with them; CBS, lacking capability and countermeasure detailed
- ✓Change management active on all five from first submission (UR E22 MoC)
Checklist B: what to request from every CBS supplier, with the clause to quote
- 3.1.1CBS asset inventory
- 3.1.2Physical and logical topology diagrams
- 3.1.3Description of security capabilities, one chapter per capability, interfaces and any compensating countermeasures declared
- 3.1.4Test procedure of security capabilities
- 3.1.5Security configuration guidelines, with defaults
- 3.1.6Secure development lifecycle documents
- 3.1.7Plans for maintenance and verification
- 3.1.8Information supporting incident response and recovery, covering local independent control, network isolation, forensics from audit records, deterministic output, backup, restore, and controlled shutdown, reset, roll-back and restart
- 3.1.9Management of change plan
- 3.1.10For type-approved CBSs: the Type Approval certificate and signed test reports
- ✓Statement of which capabilities in 4.1, and 4.2 where applicable, are met inherently, met with compensating countermeasures, or not met
- E27 5.2 to 5.4Commitment on security updates during operation
Where CyberAnchor fits
CyberAnchor is a compliance documentation platform for shipyards acting as systems integrator under IACS UR E26. It assembles the E26 5.1 submission set, the zones and conduits diagram, the vessel asset inventory, and the CSDD structure and content built from inventory, topology and supplier data for engineer completion, and it orchestrates supplier evidence across every E27 capability, the 30 required under 4.1 and the 11 additional under 4.2 where a CBS communicates with untrusted networks; 21 of the 41 can be closed on documentary evidence alone. Teams using this workflow reduce documentation effort by approximately 75% compared with assembling the same class-ready set manually. The AI reasons; the engineer decides.
Frequently asked questions
Is there a single list of documents the shipyard must submit under E26?
Yes. During design: the zones and conduit diagram (5.1.1), the cyber security design description (5.1.2), the vessel asset inventory (5.1.3), and where applicable the risk assessment for the exclusion of CBSs (5.1.4) and the description of compensating countermeasures (5.1.5). At commissioning: as-built versions of those documents plus the Ship cyber resilience test procedure (5.2.1), followed by witnessed on-board testing.
How many documents must a supplier provide under E27?
Up to ten per CBS, listed in E27 3.1.1 through 3.1.10: the CBS asset inventory, topology diagrams, description of security capabilities, test procedure of security capabilities, security configuration guidelines, secure development lifecycle documents, plans for maintenance and verification, information supporting the owner's incident response and recovery plan, the management of change plan, and test reports. A valid Type Approval certificate covering the E27 capabilities reduces the set to the asset inventory, topology diagrams and signed test reports.
Are there 41 security capabilities in E27?
There are 30 required capabilities for every in-scope CBS (section 4.1, Table 1) and 11 additional capabilities for CBSs that communicate with untrusted networks (section 4.2, Table 2). Only systems with untrusted-network communication answer all 41.
Who is the systems integrator if the contract does not say?
The shipyard. E26 defines the role as taken by the shipyard until vessel delivery unless an alternative organization is specifically contracted or assigned.
Can tests be left out of the Ship cyber resilience test procedure if they passed at FAT?
All tests must be included in the SCRTP; the decision to omit execution of a test rests with the classification society. Omission is generally not available where findings were carried over from certification, where requirements were met by compensating countermeasures, or where the CBS was modified after certification (E26 5.2.1).
What does the shipowner have to produce after delivery?
The Ship cyber security and resilience program, submitted before the first annual survey, covering at minimum management of change, software updates, firewalls and zone boundary devices, malware protection, access control, confidential information, remote access, mobile and portable devices, anomaly detection, verification of security functions, incident response plans and recovery plans, followed by evidence of implementation at annual surveys and SCRTP re-testing at special survey (E26 5.3).
Do E26 and E27 apply to ships contracted before 1 July 2024?
Not as mandatory requirements. Both URs state they may be used for other ships as non-mandatory guidance, and individual classification societies offer voluntary cyber notations for existing ships.
References
- —IACS UR E26 Rev.1, Cyber resilience of ships, November 2023
- —IACS UR E27 Rev.1, Cyber resilience of on-board systems and equipment, September 2023
- —IACS PR No. 29, procedural requirement governing "contracted for construction" dates
- —IACS Recommendation 166, Recommendation on Cyber Resilience
- —IEC 62443-3-3:2013 and IEC 62443-4-1:2018, referenced normatively by E27
- —Related on this site: the E26/E27 requirements guide at /docs/iacs-guide
This playbook paraphrases and cites the Unified Requirements for working convenience. The authoritative texts are the IACS publications themselves; where a classification society's rule implementation differs in detail, the society's rules govern.
© 2026 CyberAnchor Pte. Ltd. (UEN: 202626532W). All rights reserved. Made in Singapore.