What is Risk?¶
What you'll be able to do in this chapter
- Define risk and break it into likelihood and impact (and see where that breaks down).
- Distinguish risk from threat and vulnerability.
- Tell inherent from residual risk, know the formal and operational readings of "inherent", and introduce risk appetite.
- Write a complete risk statement by hand.
"We're at risk from ransomware"¶
In your first week, three different people warn you that Scaldimet is "at risk from ransomware." Each means something slightly different, and none of them has actually told you anything you can act on. Are we likely to be hit? How badly would it hurt? Which systems? At which site? Compared to what other dangers? "At risk from ransomware" is a feeling, not an analysis. Part of your job is turning feelings like that into statements precise enough to decide on.
That conversion (from vague worry to a clear, comparable, decidable statement) is what risk management is. This Lesson gives you the concept; Module 4 turns it into a full working method. But the discipline starts here, with getting the word risk exactly right.
What risk actually means¶
The most widely used definition comes from the international risk standard, and it is worth memorising:
Risk is the effect of uncertainty on objectives.
Unpack the three words that matter. Effect: risk is about consequences, good or bad (in security we focus on the harmful side). Uncertainty: if it were certain, it would be a fact to plan around, not a risk. Objectives: and this is the part beginners miss: risk is always relative to a goal. Something is only a risk because it threatens something you are trying to achieve. Scaldimet's objective is to deliver in-specification parts on time; ransomware is a risk because it threatens that objective. No objective, no risk (just a thing that might happen).
A common first approximation is to estimate cyber risk from two ingredients:
Risk ≈ Likelihood × Impact
Likelihood: how probable is it? Impact: how badly would it hurt if it happened? A risk that is very likely but trivial (a single spam email) and a risk that is rare but devastating (a fire destroying a site) sit at opposite corners; most real risks are somewhere in between, and ranking them is the whole game.
Technical explainer (read & discuss, don't build): why 'likelihood × impact' is a useful lie
The formula is a simplification, and you should know how, so you are not fooled by it.
- The two numbers are usually estimates, not measurements. "Likely" and "severe" are judgements. Treating a guess multiplied by a guess as if it were precise is a classic trap (Module 4 tackles this directly).
- It hides the tail. A 1-in-100 event with catastrophic impact can matter more than its "average" suggests (averages can hide rare disasters).
- Impact is rarely a single number. A stopped line costs money and breaks a contract and damages trust. These don't add up neatly.
None of this makes the formula useless (it is an excellent first tool for ranking and comparing risks, which is most of what a CISO needs early on). Just hold it loosely. Module 4 shows its limits.
Risk is not threat, and not vulnerability¶
This is where careful vocabulary pays off. In Lesson 1.1 you met threat, vulnerability, asset and impact. Risk is not a synonym for any of them: it is what you get when you combine them and add likelihood and consequence. People who blur these words make muddled decisions.
| Term | What it is | Scaldimet example |
|---|---|---|
| Threat | The thing that could cause harm | A ransomware group |
| Vulnerability | The weakness it could use | Unsupported software on Beta's OT |
| Asset | The valuable thing at stake | The production line in France |
| Impact | The harm if it happens | Line stops; OEM penalties; lost trust |
| Risk | The combination, weighed by likelihood and impact | "Ransomware could exploit Beta's unsupported OT to halt the French line, causing penalties (and given the flat network and weak habits, this is more likely than at Alpha") |
See how the risk statement contains the others but says more than all of them: it names the cause, the event, the consequence, and makes a claim about how likely and how bad. That is the difference between "we're at risk from ransomware" and something you can actually act on.
Inherent vs residual, and the idea of appetite¶
Two more distinctions and you have the full conceptual toolkit.
Inherent risk is the risk before you do anything about it (the raw exposure). Residual risk is what remains after your controls and treatments. The whole point of a security programme is to move risks from inherent to an acceptable residual level. You will never reach zero, and chasing zero is itself a mistake (it costs more than the risk is worth). At Scaldimet, the inherent risk of the French OT is high (old software, flat network). After segmenting the network and tightening access, the residual risk is lower, though never nil.
Technical explainer (read & discuss, don't build): two ways to read 'inherent' risk
The definitions above are the formal ones from the risk-management literature (COSO, NIST, and ISO-based practice): inherent risk is the exposure with no controls at all, and residual is what is left once controls are applied. Clean in theory, but in cybersecurity it has a catch. If you assess every risk assuming zero controls, almost everything comes out "very high", which tells you little about where to act first.
So many organisations, especially in cyber, use a more operational reading. Here inherent risk means the exposure under the controls already in place today (the current baseline), and residual (or target) risk means the exposure after the further treatments you plan to add.
Both are legitimate; they serve different purposes. The formal version is better for consistency, for strategic understanding of total exposure, and for measuring how much your controls actually buy you (control effectiveness). The operational version usually gives more meaningful prioritisation for day-to-day decisions. The rule that matters: an organisation must decide which interpretation it uses and state it plainly, because the same "inherent" or "residual" rating means very different things under each. This connects directly to the course's baseline-first order: Module 4 assesses risk against Scaldimet's baseline (an operational reading), and returns to this choice when Scaldimet builds its register.
Which raises the obvious question: lower than what? Acceptable to whom? That is risk appetite: how much risk the organisation is willing to accept in pursuit of its objectives. Appetite is not a technical setting; it is a governance decision (recall Lesson 1.2, setting appetite is "direction"). A board might decide that any risk of a multi-day production stoppage is unacceptable and must be treated, while accepting some risk of minor data loss. Appetite is what lets you stop treating a risk and conclude that the remaining risk is within appetite. Without a stated appetite, every risk looks like it needs more work, forever.
Application: write a real risk statement (by hand)¶
This is the core exercise of the Lesson, and you do it on paper (no tool, no template generator). Building this judgement now is exactly why the course insists on doing it by hand first.
A good risk statement has three parts: a cause/source, an event, and a consequence tied to an objective. A useful sentence shape is:
Because of [cause/vulnerability], [a threat] could [event], leading to [consequence affecting an objective].
Take this raw worry from a Scaldimet engineer and turn it into a proper risk statement:
"The contractor who maintains the French factory systems can log in from home and nobody really checks what they do."
Write your version before reading ours. Aim for one sentence that a board member could read and immediately grasp the cause, the event, and why it matters to the business.
A model answer:
Because the external maintenance contractor has unmonitored remote access to Site Beta's production-control systems (cause/vulnerability), a compromised or careless contractor account (threat) could alter or disable a control system (event), halting the French production line and triggering penalties from our largest customer (consequence affecting the on-time-delivery objective).
Compare it with the original worry. Same situation (but now it names what is wrong, what could happen, and why the business should care); it can be compared against other risks; and it points at several possible treatments (monitor the access, restrict it, segment the network). "Nobody really checks what they do" cannot be acted on. The statement above can be. That conversion is the skill. Module 4 does it at scale; you have just done it once, by hand, which is how you learn it.
Key takeaway
Risk is the effect of uncertainty on objectives: always relative to a goal. We estimate it as likelihood × impact, a useful first tool to hold loosely. Risk is not the same as threat or vulnerability; it is the combination, weighed by how likely and how harmful. Inherent risk is the raw exposure, residual is what's left after treatment, and risk appetite (a governance decision) tells you when residual is low enough to stop. The practical skill is turning a vague worry into a precise risk statement: because of [cause], [threat] could [event], leading to [consequence to an objective].