Which Comes First — the Chicken or the Egg? (Part 1)
Which Comes First — the Chicken or the Egg?
Risk Management in UR E26 Deliverable Development — when every deliverable is another's input
- LinkedIn : https://www.linkedin.com/in/abysstoinfinity/
In the prologue we described a system in which three bodies — Owner, Class, and Shipyard — pull continuously on one another. Part 1 descends to the place where that collision first shows itself, in the most concrete way possible: the very moment you begin to produce the deliverables. On paper the UR E26 list looks tidy. But the instant you reach for the work, you stall at one question — where do you even begin?
Ⅰ. The Circularity Inside the Deliverables
The problem is that the deliverables require one another — not in one direction, but in a circle. And this circularity is not something we created by sequencing the work badly. The UR E26 standard itself binds the deliverables together as each other's inputs. Follow the clauses and the loop becomes visible.
① Asset Inventory ↔ Category ↔ Zone
In the design phase the systems integrator must submit the Vessel Asset Inventory, the ZCD, and the Cyber Security Design Description (CSDD) to the Society (5.1). Yet the asset-inventory clause (4.1.1.3.1) says the inventory may specify each CBS's category and security zone — the inventory is the vessel that carries the zone, but to determine that zone you again need the inventory (the ZCD must show "which CBS belongs to which zone," 4.2.1.4.1). And E26 does not define the categories itself; it defers to UR E22, where category is set by the consequences of a failure (1.3.3) — to gauge which you must already know the zone. Inventory → category → consequence → zone → back to inventory. The document you submit first demands information that can only be settled last.
② Zone Design ↔ Risk
Zones are grouped by risk profile (4.2.1.2) — risk determines the zones. At the same time, good zoning itself reduces the attack surface and lateral movement, lowering risk — the zones determine the risk. And the zoning rules are mandatory (4.2.1.3): safety-function CBSs must be physically segmented; navigation/communication may not share a zone with machinery or cargo; wireless requires a dedicated zone. So when the judgment on one system changes, the entire zone boundary is redrawn — and with it the conduits, firewall rules, and CSDD traffic descriptions, in a chain reaction.
③ ZCD ↔ Supplier Deliverables
The ZCD is not self-contained. The standard requires it to reference the supplier's approved topology diagrams (E27 3.1.2) (4.2.1.4.1). But at design approval of a newbuild, vendor selection and detailed topology are still in flux. The diagram you must reference does not yet exist — and you are required to submit, first, the diagram that references it.
④ Operational Program (SCARP) ↔ Design — a Feedback Running Backward in Time
SCARP is an operational-phase document, submitted before the first annual survey (5.3.1), carrying the "management of…" firewalls, malware, access control, remote access, incident response and recovery (Appendix I). But everything it manages is defined by the design deliverables — firewall management presumes the ZCD's zone boundaries; isolation breakpoints presume the zone structure (4.4.1.3); the recovery plan presumes a logical network diagram (4.5.1.3). More decisively, the design-phase asset inventory is maintained "in accordance with the Owner's software-maintenance policy in the SCARP" (4.1.1.3.2). The design references an operational document not yet written. The chicken (design) lays the egg (operation) — and that egg, in turn, defines the chicken.
⑤ The Owner's Cyber Resilience Policy — the Earliest Chicken
Ahead of all these loops, the chicken that lays the first egg is the Owner's policy. Not a named submission, but presumed throughout (mobile devices 4.2.7.3, removable media 4.2.4.3.4, software maintenance 4.1.1.3.2). In practice it defines the technical specifications for security solutions and equipment: once it sets "what, with which equipment, to what level," that spec governs supplier → topology → ZCD → zones. Yet to be reasonable, the policy must already know the risk assessment, the zones, the category distribution. The earliest chicken requires the very last egg.
⑥ CSDD — the Requirements Specification, and the Strongest Knot
The knot that absorbs the most dependencies is the CSDD — not a drawing, but the body of the requirements definition itself. The standard does not list its contents; it states that "the Design-phase items under each requirement in Section 4" are the CSDD (5.1.2). If the ZCD is the picture of "where you draw the lines," the CSDD is the prose of "what those lines compel."
This is why the CSDD binds most tightly to the Policy and SCARP. The Owner's policy (intent) is the requirement's origin; the CSDD (specification) translates it into a per-CBS means of satisfaction; SCARP (operation) keeps that specification alive for the vessel's life. The three are one requirement, in three forms across decision → fixing → maintenance.
This is why none of the three can be settled in isolation. If the policy shifts, the CSDD shifts; if the CSDD shifts, the very thing SCARP must manage changes. And this requirements axis is lashed to the design web of asset inventory, ZCD and risk assessment (loops ①–③). The CSDD is the strongest knot because it sits exactly where the design web and the requirements axis cross.
What is striking is that the standard does not deny this circularity — it assumes it. The risk assessment is to be continuously updated "considering possible variations of the original design and newly discovered threats" (6.3); the asset inventory and ZCD carry a "Maintain" tag across nearly every phase (Appendix I). The standard does not say "fill it in correctly and submit it once." It says "submit it unsettled, and keep correcting it as things change." What guides that endless correction is, precisely, the risk management of deliverable development.
Ⅱ. Both Waiting and Rushing Carry a Cost
The deepest loop lies between the deliverables and the maturity of the design. To draw an accurate ZCD you need a fixed design — yet those very deliverables (the zone design, the SL requirements) are the documents meant to constrain and steer that design.
The standard assumes a finished, static system. But a newbuild is a system being born. Both the chicken and the egg lie on the desk at once — neither of them fully made.
Ⅲ. The Chicken-and-Egg Is Not Solved by Sequence
A circle cannot be solved by asking "which comes first," because a true circle has no first. The way to break the loop lies elsewhere.
- Place a hypothesis first. Instead of waiting for a complete inventory, set down a hypothetical zone structure. Better wrong than empty — what is wrong can be corrected, but what is empty moves nothing.
- Don't try to get it right in one pass. A deliverable begins at Rev 0.1 and is raised a version each time information arrives. The first version's aim is not accuracy, but to make the next conversation possible.
- Tag every assumption. An assumption is a tracked risk: "if Vendor X's design differs from this, reopen Zone N." The moment an assumption breaks is the moment a risk materializes — writing that trigger down in advance is what RM is.
This is the deliverable-side version of the "ceaseless recalculation" from the prologue. Not keeping a deliverable you set once, but solving it again each time an assumption breaks.
Ⅳ. Who Fires First?
So who places the first hypothesis? When the three bodies stand still, each saying "you decide first and I'll match," no one lays the first egg.
In the prologue, the Owner was the body that holds the heaviest mass yet brings that weight to bear too late. The chicken-and-egg deadlock is exactly where that weight should be spent. When the Owner fires the first baseline, the deadlock turns into "the reference point the other bodies orbit." It is not the one who waits, but the one who throws the first hypothesis, that becomes the center of the system.
The earliest chicken becomes the first egg itself.
And the standard already points to where that baseline belongs. The Owner's cyber resilience policy — the document defining the security specifications — is the most powerful hypothesis the Owner can fire. Rather than writing the policy after the risk assessment is done, throw a provisional policy (a specification hypothesis) first, let the suppliers, the yard and the Society react to it, and update it each time risk and zones take shape.
This is not a "do it this way" piece. It only leaves a few questions for the Owner to ask before beginning the next deliverable.
- ?Are we frozen deciding where to start — or have we already placed a hypothesis on the desk that is allowed to be wrong?
- ?Is our deliverable "an answer that must be right the first time," or "a model we raise version by version"?
- ?Is our cyber policy waiting for the risk assessment to finish — or is it already moving the suppliers and the yard as a specification hypothesis?
- ?Are our design-phase deliverables written with an eye to how the operational program (SCARP) will inherit them after delivery?
- ?Do the assumptions we made to break the loop carry tags, so that someone notices the moment they break?
Which comes first, the chicken or the egg — there is no answer. But the instant someone places one of them on the desk, the system, at last, begins to move.
Key Takeaways
The deliverables are each other's inputs; whichever you start from leads back to itself
The requirements specification where the design web and the Policy–CSDD–SCARP axis cross
The standard assumes you submit before data exists, then maintain as it changes
A provisional Owner policy is the baseline that lets the other bodies orbit and align
Core Insights:
A maritime cybersecurity and compliance specialist across the ship design & build lifecycle, focused on cybersecurity architecture, governance, and regulatory conformity for the shipbuilding and offshore sectors.
🌐 More Articles ↗
On paper, the UR E26 deliverables often appear straightforward and well-structured. However, once a project begins, the real question quickly becomes: Where do we start?
ReplyDeleteOwners, Class, and Shipyards continuously influence one another throughout the vessel lifecycle. Over the roughly two years leading to delivery, cybersecurity risks must be identified, discussed, managed, and resolved long before they become issues.
This requires constant collaboration among stakeholders, and someone must maintain alignment across technical, operational, and compliance perspectives.
From my perspective, this is where the value of CRSI becomes most apparent—not merely as a compliance function, but as the mechanism that drives risk management and coordination across all parties involved.