CBS Safe State & Minimal Risk Condition (MRC)

Part of the RESPOND Playbook ← Return to Hub

Phase: Respond All vessels

Satisfies: E26IMO MSC-FAL.1BIMCO v5

CBS Safe State & Fallback to Minimal Risk Condition

This guide defines what each critical CBS must do when it loses power, network connectivity, or operational integrity — and how the vessel is brought to a documented Minimal Risk Condition when normal recovery is not possible.

IACS UR E26 §4.4.4 requires that every Computer Based System in scope has a pre-defined safe state — a known, documented condition the system defaults to when it fails or is deliberately isolated. This is not the same as switching to local manual operation (§4.4.2) or executing an emergency shutdown (§4.4.1). A safe state is what the system does by itself when it loses control input or network integrity, before any human intervention takes place.

If a CBS does not have a defined safe state, a cyber-induced failure could leave it in an unknown or dangerous condition — a propulsion system holding full ahead, a fire detection system going silent, or a steering system freezing on its last heading. The Class Surveyor will ask: “What does this system do when it fails? Is that documented?”

Safe State vs Minimal Risk Condition — The Distinction

CBS Safe State

The pre-programmed condition a single CBS falls into automatically when it loses power, loses network connection, or detects an integrity fault. Defined per system. Documented in the CSDD. Requires no human action — it is a hardware or firmware-level behaviour. Example: a fire detection panel that defaults to alarm-active when its network link is severed.

Minimal Risk Condition (MRC)

The vessel-level condition achieved when multiple CBS have failed or been isolated and normal operations cannot be safely continued. The MRC is the endpoint of the incident response — the point at which the vessel is as safe as possible given the circumstances, and the crew can hold position or proceed to port under manual control. Requires documented procedures and Master authorisation.

CBS safe state and minimal risk condition decision tree — IACS UR E26 §4.4.4 showing automatic system behaviour on failure, vessel-level MRC declaration procedure, and five-step ETO response for propulsion, steering, PMS, fire detection, ECDIS and ballast control systems

The decision tree shows the two-stage assessment an ETO must work through when a CBS loses integrity. The first stage is per-system — does this CBS have a defined safe state, and is it entering that state correctly? The second stage is vessel-level — given the current operational picture, can the vessel continue safely or does the Master need to declare a Minimal Risk Condition?

The most important distinction in E26 §4.4.4 is that a safe state is an automatic system-level response, while the MRC is a command-level decision. An ETO cannot declare an MRC — only the Master can. But the ETO is responsible for giving the Master an accurate picture of which systems are affected, what state they are in, and what the manual fallback options are.

The five-step MRC procedure at the bottom of the diagram is what every ETO should be able to execute from memory during a real incident.

<< Click the diagram to expand at full resolution

Safe State Requirements — System by System

The following table defines the required safe state behaviour for each Category III system. These must be verified at commissioning, documented in the CSDD, and referenced in the Incident Response Plan. The ETO is responsible for confirming the safe state behaviour with each OEM before delivery.

System	Required Safe State	Failure to Define Risk	CSDD Evidence Required
Main Propulsion CBS	Reduce to minimum safe speed or maintain last stable command — never full ahead or full astern on loss of control input	CBS loss triggers uncontrolled thrust — collision or grounding risk without any warning	OEM safe state declaration + commissioning test record confirming behaviour
Steering / Autopilot CBS	Maintain last valid heading command and alert bridge — must not freeze in mid-turn or drive to hardover	Autopilot CBS failure could lock helm at last input — collision risk in constrained waters	OEM safe state declaration + hardover test record
Power Management System (PMS)	Hold current generator configuration — do not automatically shed load or start additional generators without operator confirmation	Uncontrolled load shedding or blackout condition without safe state definition	PMS vendor safe state configuration document + blackout recovery test
Fire Detection & Alarm CBS	Fail-active — on any network or power loss, default to alarm state, not silence. A silent fire detection system on CBS failure is unacceptable	CBS fault silences fire alarm — fire goes undetected during incident response	Fail-safe mode confirmation from fire system OEM + documented test
Integrated Automation System (IAS)	Hold last valid parameter values and raise alarm — do not reset valves, pumps, or actuators to default positions without operator command	IAS reset opens valves or stops pumps automatically — flooding, cargo loss, or loss of cooling to critical equipment	IAS OEM safe state matrix covering all actuator outputs + test record
ECDIS (Navigation)	Retain last known position and route — do not clear chart data or lose GPS feed without alerting bridge. Revert to paper chart backup procedure if CBS cannot be restored	ECDIS failure with no paper chart backup or safe state procedure — navigational uncertainty in restricted waters	ECDIS OEM safe state documentation + paper backup verification
Ballast / Cargo Control CBS	Lock all valves in current position on CBS loss — do not automatically open or close transfer valves without operator confirmation	Uncontrolled ballast transfer on CBS failure — stability compromise or structural stress	Valve position lock confirmation from OEM + CBS isolation test

Reaching Minimal Risk Condition — The Procedure

When individual CBS safe states have been triggered but the vessel cannot safely continue normal operations, the Master authorises a transition to MRC. This is the vessel-level endpoint of a serious cyber incident. The ETO leads the technical execution; the Master retains command authority throughout.

Step 1

Confirm CBS Status Across All Critical Systems ETO verifies the current state of each Category III CBS — which are in safe state, which are operational, and which are unknown. Document the status on the Incident Severity Matrix. Brief the Master on which systems are affected before any MRC decision is taken.

Step 2

Transfer All Affected Systems to Local Manual Control For each CBS in safe state or failed, transfer control to the local panel per the Local & Manual Operation procedure (§4.4.2). Confirm each transfer is complete before proceeding. Do not attempt to restart compromised CBS — this may re-introduce the threat or cause unpredictable behaviour.

Step 3

Master Declares Minimal Risk Condition Once all affected CBS are either in confirmed safe state or under local manual control, the Master formally declares MRC. This is recorded in the bridge log with time, reason, systems affected, and the name of the Officer of the Watch. MRC is not an emergency condition — it is a controlled, documented state.

Step 4

Notify Company / DPA and Assess Voyage Options The DPA is notified of MRC status per the Regulatory & Shore-Side Reporting procedure. The Master and company assess whether the vessel can safely proceed to the next port under local manual control, should divert to the nearest port of refuge, or requires external assistance. Port State Control notification may be required depending on flag state requirements.

Step 5

Preserve Evidence — Do Not Restart CBS While in MRC, no compromised CBS is to be restarted without a clean recovery procedure. Evidence must be preserved — logs exported, affected equipment isolated and tagged. Restarting a compromised CBS without forensic examination may destroy the evidence needed for insurance claims, PSC investigations, and the post-incident review.

Common Gaps — What Surveyors Find

No safe state documentation from OEMs

The most common gap — the ETO assumes the system fails safely but has no written confirmation from the OEM. Safe state behaviour must be declared in writing and included in the CSDD.

MRC not defined in the IRP

The Incident Response Plan mentions containment and recovery but does not define what MRC looks like for this vessel specifically or who has authority to declare it. MRC must be a named procedure in the IRP.

Safe state not tested at commissioning

The OEM has declared a safe state in documentation but it has never been physically triggered to verify the behaviour matches the declaration. Class surveyors increasingly require evidence of a commissioning test, not just a vendor document.

Conflicting safe states between systems

Individual system safe states have been defined in isolation but create a conflict when triggered together — for example a PMS that sheds load to “safe state” while the IAS simultaneously tries to maintain process parameters that require that load. Safe states must be reviewed as a system, not individually.

The Link Between §4.4.2, §4.4.1, and §4.4.4

These three requirements work together as a single response framework. §4.4.1 (Incident Response) is the plan — what to do when an incident is detected. §4.4.2 (Local Manual Operation) is the physical fallback — how to operate systems without CBS. §4.4.4 (Safe State / MRC) is the safety net — what each system does automatically before the human response begins, and the documented vessel condition when CBS cannot be recovered. A Class Surveyor assessing E26 compliance will check all three together. If any one is missing, the others are incomplete.

Compliance Documentation

Templates supporting safe state declaration and MRC procedures.

TAG-OT-IRP-01

Incident Response Plan Template

Unlock with Pro Bundle

TAG-OT-LOG-05

Local Control Test Record

View Form

TAG-OT-LOG-06

Threat Mapping Matrix

View Form

PREVIOUS:
Local & Manual Operation

Next Section

Internal Crisis Communication

Internal Crisis Communication This guide covers internal communication procedures during a cyber incident — who to not...

Internal Crisis Communication →