Risk is not alert severity

Many systems use a simple classification:

Critical High Medium Low

The colours are familiar.

They help people decide where to look first.

They help escalation rules determine how quickly somebody should respond.

They make dashboards manageable.

But a red alert is not necessarily a risk assessment.

Severity and risk answer different questions.

Severity is useful

An exception needs some indication of importance.

A failed message between two low-priority systems should not necessarily generate the same response as the loss of a safety-critical control.

A severity value can help determine:

• notification,
• escalation,
• response time,
• visibility,
• and workflow priority.

That is valuable.

The problem occurs when severity is treated as if it fully describes the risk created by the exception.

It rarely does.

Risk requires context

Risk may depend on:

• the hazard,
• consequence,
• likelihood,
• duration,
• exposure,
• available redundancy,
• existing controls,
• effectiveness of those controls,
• uncertainty,
• and recoverability.

The same technical condition can therefore create different risks.

Consider a failed pump.

If an equivalent standby pump is healthy and automatically available, the immediate operating risk may remain modest.

If the failed pump is the last available unit supporting a critical function, the same equipment failure has a very different consequence.

The alert may be identical:

Pump unavailable.

The risk is not.

Organisational consequence can differ from technical severity

The reverse is also possible.

A condition may appear technically minor but have a serious governance consequence.

Suppose a monitoring sample is collected one day late.

Operationally, that may appear to be a small scheduling error.

If the monitoring frequency is a licence condition, the compliance consequence may be considerably more important.

Likewise, a contract system might detect a notice deadline.

Nothing has physically failed.

No equipment is unavailable.

But failure to act may materially affect the organisation’s contractual rights.

That is why exception severity should not be allowed to stand in for organisational risk.

Risk depends on what the condition means.

Risk changes over time

Risk is not necessarily fixed when an exception is first detected.

Suppose equipment enters a degraded state.

An engineering assessment determines that operation can continue for fourteen days under temporary conditions:

• pressure reduced,
• inspections increased,
• replacement equipment ordered,
• daily review required.

On Day 1, the residual risk may be considered acceptable.

On Day 10, the replacement may still be on schedule.

On Day 13, a delivery delay may appear.

On Day 15, the temporary approval has expired.

The original technical condition may be unchanged.

The governance position is not.

The risk record therefore needs to understand:

• temporary controls,
• assumptions,
• expiry,
• review dates,
• and changing circumstances.

This is another reason not to reduce risk to a static colour.

Risk should expose its assumptions

A useful risk assessment makes its basis visible.

For example:

Continued operation is considered acceptable because the secondary barrier remains available, pressure is limited to 70%, inspection occurs every 12 hours and replacement is expected within seven days.

That statement contains assumptions that can be tested.

If the secondary barrier becomes unavailable, the assessment may no longer be valid.

If the inspection is missed, the residual risk may change.

If replacement is delayed by three weeks, management may need to reconsider the original decision.

In a connected assurance environment, those assumptions can become controls.

The system can ask:

Are the conditions on which this risk acceptance depended still true?

That turns risk from a one-time form into part of the ongoing operating model.

Some risk belongs with the domain

A governance application should not try to calculate every technical risk itself.

An integrity application may contain the engineering model.

A geotechnical application may determine slope risk.

A legal application may identify contractual exposure.

An environmental system may assess a compliance condition.

Those systems should remain responsible for their specialist analysis.

The governance layer needs something different.

It needs to preserve:

• the assessment,
• its source,
• its assumptions,
• its current status,
• the decision authority,
• and the conditions under which the risk is considered acceptable.

That keeps domain expertise in the domain while making organisational accountability visible.

Risk exists to support a decision

Severity says:

Look here first.

Risk says:

Given the evidence, context and controls, this is what could happen and this is the exposure we believe remains.

Neither resolves the exception.

Eventually somebody has to decide.

Continue.

Stop.

Repair.

Escalate.

Notify.

Accept temporarily.

Reject.

Change the programme.

Spend more money.

Require another control.

Yet many systems represent incidents, work, approvals and actions in great detail while representing the actual decision as little more than a status change.

If material decisions determine what the organisation does and what risk it accepts, they deserve a stronger place in the information model.