Risk assessment principle
Operational risk assessment should be simple enough to use during real work, but structured enough to support responsible decisions. The goal is not paperwork. The goal is controlled awareness before exposure increases.
A practical risk assessment identifies the risk, scores probability and impact, defines mitigation tasks, reassesses the remaining risk, assigns ownership and tracks completion.
Working principle: Identify risk → Assess probability and impact → Define mitigation → Reassess residual risk → Assign owner → Track completion.
Assessment flow
| Phase | Question | Output |
|---|---|---|
| 1. Identify | What can go wrong? | Clear risk description |
| 2. Assess | How likely is it, and how serious would it be? | Probability, impact and initial risk score |
| 3. Mitigate | What controls reduce the risk? | Defined mitigation tasks |
| 4. Reassess | What risk remains after mitigation? | Residual probability, impact and risk score |
| 5. Own | Who is responsible, and by when? | Named owner and completion date |
Basic risk formula
A simple operational model can use:
In Norwegian operational language, probability is often described as sannsynlighet. The method is the same: estimate how likely the event is and how serious the consequence would be.
Scoring model
The scale below is a practical example. Real organizations should adapt definitions to their own safety requirements, contractual commitments, operational environment and risk appetite.
| Score | Probability / Sannsynlighet | Impact |
|---|---|---|
| 1 | Rare / unlikely under normal conditions | Minor local effect, no critical operational impact |
| 2 | Possible, but not expected | Limited disturbance or local operational inconvenience |
| 3 | Possible during the activity or condition | Operational impact, reduced redundancy or service concern |
| 4 | Likely if controls are not applied | Major operational impact or serious degradation |
| 5 | Very likely or already developing | Critical impact, safety concern or major service loss |
Risk level identification
Color should make the risk level easier to read quickly. It should support the decision, not replace the explanation behind the score.
| Score | Level | Visual Marker | Typical Action |
|---|---|---|---|
| 1–4 | Low | ● Green | Proceed with normal controls and monitoring. |
| 5–9 | Medium | ● Amber | Proceed only with defined controls and clear ownership. |
| 10–16 | High | ● Red | Requires mitigation, approval and escalation awareness. |
| 17–25 | Critical | ● Dark Red | Do not proceed without senior approval and risk reduction. |
Risk assessment register
The examples below show the same structure as a traditional risk register, but arranged as separate risk cards for better readability: original risk, probability, impact, mitigation, residual risk, responsibility and completion date.
Loss of redundancy during planned UPS maintenance
Initial Assessment
Probability: 3
Impact: 4
Mitigation Tasks
- Approved MOP reviewed
- Load level verified
- Monitoring confirmed active
- Rollback plan reviewed
- Stop conditions defined
Residual Risk
Probability: 2
Impact: 4
Ownership
Owner:
Operations Lead
Completion:
Before work start
Cooling capacity reduced during planned CRAC/CRAH maintenance
Initial Assessment
Probability: 3
Impact: 4
Mitigation Tasks
- Redundant cooling verified
- Temperature trend monitored
- Escalation criteria defined
- Stop conditions defined
- Maintenance window confirmed
Residual Risk
Probability: 2
Impact: 3
Ownership
Owner:
Facility Operations
Completion:
Before maintenance window
Incorrect asset identified during technical work
Initial Assessment
Probability: 2
Impact: 5
Mitigation Tasks
- Approved asset ID used
- Physical label verified
- Procedure reference checked
- Second-person confirmation completed
Residual Risk
Probability: 1
Impact: 5
Ownership
Owner:
Technical Lead
Completion:
Before execution
Stop conditions
A risk assessment should define when work must stop. Stop conditions protect the team from continuing only because the activity has already started.
| Marker | Stop Condition | Required Response |
|---|---|---|
| ■ | Actual conditions do not match the approved plan | Stop, reassess and confirm whether the plan remains valid. |
| ■ | Redundancy becomes uncertain | Stop work and escalate to operational authority. |
| ■ | Critical alarm appears unexpectedly | Stabilize, investigate and record the condition. |
| ■ | Asset identity or system state cannot be confirmed | Do not proceed until correct asset and state are verified. |
| ■ | Rollback path is no longer available | Stop progression and reassess operational exposure. |
| ■ | Residual risk is higher than accepted | Escalate for approval, additional mitigation or cancellation. |
Stop rule: If the risk picture changes, stop and reassess before continuing.
Risk ownership
Risk ownership must be explicit. A mitigation task without an owner is only a suggestion.
| Role | Responsibility |
|---|---|
| Risk Owner | Accountable for accepting, reducing or escalating the risk. |
| Action Owner | Responsible for completing a defined mitigation task. |
| Technical Reviewer | Confirms that the proposed controls are technically valid. |
| Operational Approver | Confirms that the remaining risk is acceptable for execution. |
Risk should not be accepted only by the person who wants the work completed. Acceptance should sit with the role responsible for the operational consequence.
Operational exposure
Operational exposure is the period where the facility is more vulnerable than normal. This can be more important than the task duration itself.
| Exposure Type | Example |
|---|---|
| Power exposure | Reduced UPS or generator redundancy |
| Cooling exposure | Reduced cooling capacity or uncertain thermal margin |
| Monitoring exposure | Temporary loss of alarm visibility or sensor reliability |
| Access exposure | Restricted access routes, open panels or active work zones |
| Recovery exposure | Delayed rollback capability or unclear return-to-normal path |
| Human exposure | Increased dependency on coordination, handover or manual action |
Residual risk
Residual risk is the risk remaining after mitigation tasks are applied. It should be reviewed before work starts or before an incident response is considered stable.
If residual risk remains high or critical, it should not be hidden by wording. It should be escalated to the correct authority for decision, acceptance, further mitigation or cancellation.
Downloadable template
A downloadable Excel template is available for practical use as a starting structure. It includes probability, impact, initial risk, mitigation tasks, residual risk, ownership, due date and color-based risk level identification.
Download Operational Risk Assessment Template
Public examples and limitations
This page describes a generalized operational risk assessment method. Real risk models must be aligned with the organization’s safety requirements, legal obligations, contractual commitments, risk appetite, management system and operational governance.