Topic 04

Risk: Likelihood and Impact

Risk

Risk is what lets a team spend a finite budget where it actually matters. Informally, risk equals likelihood times impact: how probable is this threat, and how bad is it if it happens? This topic makes that concrete enough to rank Meridian's threats, so the SQL-injection risk on the customer database gets attention before an attack that needs physical access to a locked datacenter.

The output of the last two topics — a STRIDE list against Meridian's real attack surface — is just a pile of threats until you score it. Ranking is the entire point, because a flat list of 200 equally-urgent findings means nothing gets fixed.

The Two Factors

Likelihood asks how often, how easily, and how motivated an attacker would be — and a bug with a public exploit is not "unlikely," whatever your gut says. Impact asks what is lost: data, downtime, cost, reputation, regulatory exposure. A high-impact but near-impossible threat and a low-impact but constant one can land at the same score, and both deserve explicit thought rather than a reflex.

Qualitative or Quantitative

A simple high/medium/low matrix is fast and usually good enough to prioritize — most teams never need more. When a decision genuinely turns on a number, quantitative methods put money on risk: annualized loss expectancy, or ranges in the style of FAIR. The trap is false precision — a made-up dollar figure is not better than an honest high/medium/low.

Inherent vs Residual Risk

Inherent risk is the risk before controls; residual risk is what remains after them. The goal is to drive residual risk below the organization's tolerance — not to zero — and, crucially, to know what residual you are accepting. Unmade decisions are still decisions, just undocumented ones nobody owns.

Ranking Meridian's Risks

Score the STRIDE list and the priority order falls out: the internet-facing, high-impact threats first. Injection against the customer database outranks a clever attack requiring datacenter access; a known-exploited bug on app.meridian.example outranks a theoretical "critical" on an isolated internal host. That ranked list is the roadmap the defensive chapters follow.

Inherent vs Residual Risk

Inherent risk — the raw risk of a threat with no controls in place. Useful for understanding how bad something could be.

Residual risk — what is left after your controls. This is the number you actually manage: drive it below tolerance and get named sign-off on anything you accept above it.

Common Mistakes
  • Treating every finding as equally urgent — a flat list of 200 "criticals" means effort scatters and nothing gets fixed.
  • Scoring likelihood from gut feeling with no reference to real attacker behavior or public exploit availability — a bug with a working exploit is not "unlikely."
  • Ignoring impact concentration, so one system holding all the customer data is weighted like any other box on the diagram.
  • Manufacturing a precise dollar figure to look rigorous when an honest high/medium/low would drive the same decision.
  • Accepting risk implicitly by never deciding, leaving undocumented residual risk nobody owns.
Best Practices
  • Rank threats by likelihood times impact and fund the top of the list first — prioritization is the whole exercise.
  • Use real signals for likelihood: public exploits, observed attacker trends, and your own incident history.
  • Weight impact by concentration — the system holding all the customer PII deserves attention beyond its size on the diagram.
  • Track residual risk explicitly and get named sign-off on anything accepted above tolerance.
  • Re-score when the environment changes, since a low-likelihood risk becomes high the day an exploit is published.
Comparable toolsMethod Risk matrix (qualitative) · FAIR (quantitative)Metric ALE = SLE × ARO · CVSS/EPSS as inputsTooling GRC platforms / risk registers

Knowledge Check

A vulnerability has a public, working exploit. How should that affect its likelihood score?

  • It raises likelihood — a ready exploit makes the attack easy
  • It lowers likelihood, since the defenders now know about it too
  • It has no effect — likelihood should come from expert intuition
  • It only shifts the impact score, never the likelihood

Why rank Meridian's threats instead of treating them as one flat list of criticals?

  • A finite budget must fund the highest-scoring threats first
  • Ranking lets the team ignore every threat below the top one
  • A flat list is fine as long as every item is labeled critical
  • Ranking removes the need to ever re-score risks later

What is residual risk?

  • What remains after your controls, which you accept
  • The raw inherent risk of a threat before any control exists
  • The risk that only appears after a system has been breached
  • The portion of risk that has been transferred to an insurer

You got correct