Common-Cause Risk

A risk register holds 34 rows. Each is scored on a 5x5 likelihood-by-impact grid, the top six clear the funding line and the rest are "monitored". Six of the monitored rows describe different systems degrading, and every one of them begins "if the corporate identity provider is unavailable".

The grid has no way to say that those six rows are one event. Multiplying likelihood by impact treats each as an independent draw, so a single failure costing six times any individual row's impact is recorded as six mediums and funded as none. The organisation has not mis-scored anything. It has used a method whose arithmetic assumes independence on a portfolio that is not independent.

Why it matters

Risk registers exist to allocate money. Independence is the assumption that makes the ranking wrong in the one direction that matters: it systematically under-prices the concentrated, correlated events that produce actual crises, and over-prices the diffuse ones.

Work the numbers. If the six were genuinely independent at a 2% annual chance each, the probability that at least one fires is 1 - 0.98^6, about 11%, and the expected outcome is one moderate loss. Because they share a cause it is one event at roughly 2% with six times the loss: rarer, much larger, and with a tail the grid cannot represent at all. Expected value alone still hides it, because the two portfolios have similar means and completely different distributions. The decision you would make about a 2% chance of a £6M loss is not the decision you would make about six 2% chances of £1M.

Implementation patterns

• Add a dependency field to every register entry and group by it. A register that cannot answer "which entries share a cause" is a list, not a model, and the grouping is half a day of work.
• Score the group as one entry. "Corporate identity provider unavailable for more than 30 minutes during business hours", with the combined impact, clears the funding line on its own.
• Quantify the top two or three groups as loss ranges rather than colours: £0.4M to £3M, most likely £1.1M. A £120k break-glass authentication path either clears that bar or it does not, and the argument becomes finite.
• Test the grouping against reality with a dependency exercise: disable the shared component in a game day and see which mitigations were routed through it.
• Write each entry as an event with a duration, because most scoring disagreement is two people scoring different events rather than differing in judgement.

Industry example

Read enough public postmortems from 2019 onwards and one shape recurs often enough to plan against: an unattended operating-system or agent update restarting networking on hosts across several regions within the same hour. Regions modelled as independent in the risk register turn out to be coupled through a shared management process that no row mentions. A register listing "region A unavailable" and "region B unavailable" as separate entries misprices exactly this, and so does one that scores "certificate expiry" per service when a single automation issues all the certificates.

Failure scenarios

• Diversification that is not. Five mitigations all depend on the identity provider, the certificate authority, the same region, or the same on-call rota.
• The vendor concentration nobody summed. Eleven entries name the same supplier, and no row says "this supplier fails".
• Mitigation sharing a cause with the risk. The failover path authenticates through the service whose failure triggers the failover.
• Aggregation by scoring average, which is worse than no aggregation: averaging six 3x3 scores produces a 3x3.
• The register that grows instead of resolving. 200 rows, no groups, no dates, and a quarterly meeting that reads the top five.

Trade-offs

Grouping and quantification cost analyst time and create an artefact senior people will argue with, which is the point and also the friction. Full quantitative modelling of an entire register is a quarter of work that changes no decision beyond the top few groups. The pragmatic split is coarse scoring for the long tail and loss ranges for the groups above the funding line — cheap where precision is worthless, precise where money moves.

When not to use it

A twenty-person company does not need a dependency-grouped register with loss distributions. One page listing the five things that would end the business, each with an owner and a next action, beats any grid, and the shared dependencies are obvious enough to hold in one head. Quantification earns its cost only when there is genuine money to allocate between competing mitigations and someone senior who will change a decision on the ranking. If the output is a slide for a committee, keep it cheap and spend the saved effort on the game day instead.

Interview question

Q: You inherit a register where the top risks are funded and the rest are monitored. What is the first analysis you run on it, and what would you expect to find?

What a strong answer covers: group by shared dependency before re-scoring anything · expect to find a cluster below the funding line that is one event · the independence arithmetic and why expected value hides the tail · re-express the top clusters as loss ranges so mitigations can be argued on cost · keep the long tail coarse · and check that mitigations do not share a cause with the risk they mitigate.

Quick check

Quiz: Six register entries each score 9 out of 25 and all fail together. Why does the register fund none of them? — Because the grid scores rows independently; the combined event is never represented, so its impact never appears above the line.

Flashcard: What does a 5x5 risk grid assume that is usually false? — That the rows are independent; shared causes turn several mediums into one large event that the grid cannot express.