Defining Your Critical Risks (MUEs) and Controls

Purpose

This section explains how to document the potential major incidents (MUEs) your organisation faces and the controls you have in place to manage them. These records form the backbone of your CCM system and populate Bowtie diagrams.

1. Documenting Critical Risk Assessments (MUEs)

MUEs are the starting point. Each MUE gets its own "Critical Risk Assessment" record.

• How to Think About It: What are the major unwanted events that could happen?
• Creating an MUE Record:
  • The Risk Scenario field is key – it's the main description of the MUE and often serves as its title.
  • You'll link Causes (what could lead to the MUE) and Consequences (what could happen if the MUE occurs). These are typically separate linked records.
  • Crucially, you'll link Preventative Controls and Mitigating Controls. These link to "Controls" records (see below), which can be created directly from here if they don't exist.
• Workflow & Status: MUE records move through a workflow (e.g., "Draft," "Under Review," "Assessed"). The status can impact Bowtie visualisations (e.g., changing to "Control Issues" if a linked critical control fails verification). Your administrator configures this workflow and associated notifications (e.g., to an "Approver").

2. Documenting Controls

Controls are your safeguards, documented in "Controls" records. They can be created from the "Controls" register or directly when linking them to an MUE.

• Key Information & Purpose:
  • Preventative/Mitigating: This choice dictates whether the control aims to stop an event or reduce its impact, and where it appears on a Bowtie diagram.
  • Criticality Decision Tree: A series of Yes/No questions to help you determine if a control is critical.
  • Critical/Non Critical: This designation is important. If a control is "Critical":
    • Additional fields like "Critical Control Description" may become visible.
    • The section for Performance Standards/Requirements becomes relevant.
  • Display Performance Requirements?: A Yes/No option that shows or hides the detailed Performance Standard section for critical controls.
• Defining Performance Standards (for Critical Controls): If a control is "Critical" and you opt to display performance requirements, you can detail how it should perform and be verified by linking specific records:
  • Performance Requirements: What the control must achieve (e.g., "Pressure relief valve must open at 10 bar").
  • Performance Activity: How its performance is actively verified (e.g., "Quarterly functional test of PRV").
  • Performance Parameter: Specific metrics for that activity (e.g., "Test pressure set to 10 bar +/- 0.1 bar").
  • Failure Mechanism: Potential ways the control could fail and strategies to prevent that (e.g., "Valve seizure due to corrosion," prevented by "Regular inspection and material selection").
  • These sections help ensure critical controls are robustly defined and managed.
• Workflow & Status: Controls also have a workflow (e.g., "Draft," "Effective," "Not Effective"). The status (especially "Effective" or "Not Effective") directly influences the visual representation on Bowtie diagrams and can trigger changes in the linked MUE's status.

Configuration

The specific fields, dropdown options, visibility rules, and workflows for MUE and Control forms are configured by your myosh administrator to match your organisation's processes.