RTO & RPO Determination for Shipboard CBS
This module establishes the methodology for deriving Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) for each Computer-Based System (CBS) in scope of IACS UR E26. These values are a direct output of the System Criticality Mapping work completed in this Identify phase and must be documented in the Ship Cyber Security and Resilience Program (SCSRP). The operational execution of recovery within these targets is covered in Recover → Recovery Execution & Verification.
RTO and RPO are not numbers you choose — they are values you derive and justify per CBS. A flat target copied from a generic IT policy (“RTO: 4 hours, RPO: 24 hours”) will not survive Class scrutiny. E26 §4.5.1.3 requires a documented methodology. A technically-prepared surveyor will ask: “How did you arrive at that number for your ECDIS?” This module gives you the answer.
Survey Risk — Most Common SCSRP Failure
The most common failure mode during Class annual surveys is a SCSRP that states a single RTO/RPO value across all systems with no documented basis. If the answer to “how did you arrive at that number?” is “it seemed reasonable,” the document fails on methodology — not just content.
1. What E26 Actually Requires
IACS UR E26 §4.5.1.3 defines both objectives precisely and ties them to a documented methodology — not a policy wish. E26 does not prescribe numerical values; it requires the shipowner to derive and justify them based on the specific characteristics of each CBS.
The time required to recover the required communication links and processing capabilities of a CBS after a cyber incident. It is a system recovery metric.
Source: E26 §4.5.1.3
The longest period of time for which an absence of data can be tolerated. It is a data recovery metric governing how much data loss is acceptable after a restore.
Source: E26 §4.5.1.3
The timeline shows the relationship that most maritime professionals have seen described in text but rarely visualised clearly. RPO governs how far back you can afford to restore from — it determines your backup frequency. RTO governs how long you have to get the system running again — it determines your fallback endurance requirements and your recovery resource planning.
The critical maritime distinction is that RTO is not a business continuity target — it is a safety boundary. The same ECDIS can have a four-hour RTO alongside at anchor and an RTO equal to the OEM restart time in restricted waters. A flat RTO applied across all systems and all voyage phases will not satisfy E26 §4.5.1.3 because it does not reflect the actual safety risk of extended downtime in different operational contexts.
The four determination factors at the bottom of the diagram are the inputs Class surveyors expect to see documented for every Cat II and Cat III system in the SCSRP.
<< Click the diagram to expand at full resolution
2. The Four Mandatory Determination Factors
Reading across E26 §4.5.1.3 and §4.5.1.4.4, four factors are explicitly named or implied. All four must be documented for each CBS. Factor 01 — CBS Criticality Category — is the direct output of your System Criticality Mapping already completed in this Identify phase.
The system’s safety classification — Cat III, II, or I — from System Criticality Mapping. Sets the ceiling for acceptable downtime. Category III has zero tolerance for unmitigated failure at sea.
Named explicitly in §4.5.1.4.4. The maximum operational gap before safety, navigational integrity, or regulatory compliance is compromised. This is voyage-phase dependent — not a single fixed value.
If a certified fallback exists — manual steering, local engine control, paper charts — the RTO can reflect its endurance. If no fallback exists, RTO must equal the OEM restart time with no buffer.
The minimum time physically required to restore the system, sourced from OEM documentation per UR E27 §3.1.8. The RTO cannot be shorter than this — it sets the absolute floor regardless of operational intent.
A fifth factor — vendor support arrangements (§4.5.1.4.4) — applies where recovery requires vendor involvement. Where OEM-locked configurations mean vendor response time becomes part of the effective RTO, this must be reflected in service contract terms and documented compensating controls.
3. Why Maritime RTO Differs From IT RTO
In a conventional IT context, RTO is about business continuity — how long can an organisation tolerate a system offline before financial damage becomes unacceptable. On a vessel, the calculus is entirely different and must be understood before any value is assigned.
4. Recovery Objectives by CBS Category
The values below are baseline ranges derived from the CBS criticality category established in System Criticality Mapping (E26 §4.1.1). These must be refined to system-specific values in the CBS Recovery Register in Section 5.
Note on Category III RTO at sea: A clock-based RTO is operationally misleading for Cat III systems underway. The correct SCSRP framing is: “Category III systems shall be restored within the verified manual fallback endurance of the crew, and in no case later than the OEM-documented restart time.” The value is system-specific — populate it individually in the CBS Recovery Register below.
5. The Sea vs. Port Asymmetry
E26 §4.5.1.3 requires that “the operation and navigation of the ship shall be prioritized in the plan.” This tightens recovery tolerances based on operational state. A single RTO value per system, applied regardless of voyage phase, does not satisfy this requirement.
6. CBS Recovery Register — SCSRP Template
The CBS Recovery Register is the auditable artefact that makes your RTO/RPO values defensible to Class. It links each system to its OEM restart documentation, fallback capability, and agreed objectives. Maintained in the SCSRP and updated via MoC whenever CBS configurations change. (E26 §4.5.1.4.4 / UR E27 §3.1.8)
Critical Technical Manager Warning
Never populate the CBS Recovery Register with assumed restart times. Every OEM restart baseline must be sourced from a specific section of the OEM technical manual, referenced by document title, version, and section number. Assumed values will not satisfy a Class surveyor. Confirm values during commissioning and update via MoC.
7. RPO and Backup Frequency — The Direct Link
The RPO value directly governs the backup schedule in the SCSRP. Most operators state an RPO without realising they are simultaneously committing to a backup frequency. If your Cat III RPO is 8 hours, your backup policy must guarantee no more than 8 hours of configuration data can be lost at any point.
Met by taking a Gold Copy backup before and after every MoC event. The last known good state is never older than the most recent configuration change — the operationally correct definition of RPO for OT systems. Supplement with a quarterly scheduled backup as a safety net.
Met by a 6-monthly scheduled routine backup plus mandatory MoC-triggered backups. Offline storage of at least one full backup set is an explicit E26 §4.5.2.3.2 requirement — protecting against ransomware affecting online backup appliances.
The full backup execution procedure — Gold Copy creation, media labelling, offline storage, and annual restoration testing — is documented in Recover → Golden Image Management and Recover → Offline Backup Rules.
Surveyor Verification & Audit Readiness
During annual and special surveys, Class will review the CBS Recovery Register and challenge the methodology behind every RTO/RPO value. Have the following ready:
- CBS Recovery Register — per-system RTO/RPO with OEM source references
- OEM Restart Documentation — specific manual section per CBS (UR E27 §3.1.8)
- Backup Policy — showing RPO-to-frequency linkage
- “How did you determine the RTO for your ECDIS?”
- “Does this RTO apply at sea or only at anchor?”
- “Show me the OEM documentation supporting these restart times.”
The specific regulatory requirements this playbook satisfies. Use these references when preparing for Class survey or responding to a surveyor's checklist.
