2 Risk? Foundations of Risk Management
What could go wrong, and how do we measure it?
🗂️ Tessera Case: “We’ve covered the big risks”
Day three of the engagement, an email lands from Tessera’s CTO. Attached is a polished spreadsheet: the draft risk register, thirty-odd rows, colour-coded green and amber, not a red cell in sight. “We’ve covered the big risks,” she writes. “Let me know if you need anything else for the risk assessment.” That attachment is your first real artefact of the engagement, and the claim stapled to it is, as always, the thing to test. A register that rates everything medium is not evidence of low risk. It prompts questions about the method, assumptions and evidence. The ratings may be reasonable; their uniform colour does not decide that.
2.1 What risk actually is
Risk is the effect of uncertainty on objectives. That is the ISO definition, stripped to its bones, and it is better than it sounds. Two words do the work. Uncertainty means you do not know whether something will happen, only that it might. Objectives means risk is always measured against something an organisation cares about: revenue, reputation, customer trust, compliance, availability. A threat that cannot touch any objective is not a risk worth managing. A threat that can is, no matter how unlikely it feels on a calm day.
Notice what risk is not. It is not a threat, and it is not a vulnerability, though both create it. A threat is an actor or event that could cause harm: a ransomware crew, a flood, a careless insider. A vulnerability is a weakness that a threat could exploit: an unpatched server, a shared admin password, an offboarding step that never runs. Risk is what you get when a threat meets a vulnerability and the result could damage an objective. Tessera’s unpatched server is not a risk by itself. The ransomware crew that could reach it, and the revenue loss and certification delay that would follow, is the risk.
This three-part model, threat plus vulnerability plus impact on an objective, underlies every risk register. Most of the optimism you will spend this chapter correcting comes from someone quietly dropping one of the three: naming a threat with no vulnerability, a vulnerability with no credible threat, or an impact with no objective attached.
2.2 The risk lifecycle
Risk management is not a document you produce once. It is a cycle you run, repeatedly, for as long as the organisation exists. ISO/IEC 27005 lays the loop out, and NIST SP 800-30 walks the same path in slightly different language. The shape is the same.
You establish context: what is in scope, which objectives matter, what appetite for risk the organisation has set. You identify risks: the threats, the vulnerabilities, the scenarios where the two meet. You analyse each one, estimating likelihood and impact. You evaluate them, ranking the analysed risks against your criteria to decide which deserve treatment. You treat them, choosing from the four options we will come to. And you monitor and review, because risks change, controls drift, and a register that was right in January is stale by July.
The cycle matters more than the artefact. A risk register is a snapshot of one trip around the loop. The organisation that updates it annually, to satisfy an auditor, has a document. The organisation that runs the loop continuously has risk management. When you audit, part of what you are testing is which of those Tessera is.
2.3 Likelihood × impact
Many risk methods consider likelihood and impact. This book uses a simple ordinal matrix; multiplication of category scores is a planning convention, not a universal risk formula. How likely is this to happen, and how bad would it be if it did? Score each on a scale, combine them, and you have a rating you can rank, plot on a matrix, and defend.
Likelihood is usually a blend of two things the register rarely separates: how often the threat tries, and how likely it is to succeed given the controls in place. A phishing campaign hits Tessera’s staff hundreds of times a week; that is high threat activity. Whether it becomes an incident depends on whether the training, the mail filter, and the MFA hold. Conflating the two is how registers end up with every externally-facing risk marked “high likelihood.” It is also how they end up low: rating the attempt frequency and then quietly assuming the controls work, without ever testing them.
Impact is where the optimism lives. Organisations under-rate impact because they measure the obvious cost and miss the cascading one. A lost laptop is a replacement cost. A lost laptop holding an unencrypted customer list may require breach assessment, notification if the legal conditions are met, and contractual response. The first number is small. The second is the one that ends careers. Your job, when you read an impact rating, is to ask which of those two numbers the author actually wrote down.
The matrix is seductive because it produces a tidy colour. Green, amber, red. Treat the colour as a hypothesis, not a conclusion. Two risks sitting in the same amber cell can be wildly different in what they demand of you, because the matrix has flattened a judgement into a square. We will come back to why, in the Watch out at the end.
2.4 The risk register and the risk owner
The risk register is where the lifecycle leaves a paper trail. Every identified risk gets a row: a description, the assets and objectives it threatens, a likelihood and impact rating, the treatment chosen, the controls that implement the treatment, and a residual rating once those controls are in place. Done well, it is the most honest document in the organisation. Done poorly, it is theatre.
There is one column that gets neglected more than any other, and it is the one that determines whether the register functions: the risk owner. Every risk needs a named individual, not a team, not “the business,” accountable for keeping it managed. Ownership is not the same as blame. It is the answer to the question “who will notice when this risk changes, and who will act?” A risk without an owner is an orphan. It will drift until it becomes an incident, and then someone will discover that nobody owned it, which is exactly when ownership would have mattered.
ISO/IEC 27001:2022 makes this explicit in its organisational controls: roles and responsibilities for information security must be defined and assigned. The risk owner is the sharpest test of whether that control is real. When you audit Tessera’s register, look at the owner column first. If it names only teams, ask how responsibility resolves to an accountable role or individual. Record a finding only after testing the applicable requirement and the actual assignment.
🗂️ Tessera Case: The preliminary Tessera risk matrix
Here is the register as it arrives, trimmed to the rows that matter. Looks complete. Looks disciplined. Read it as the auditor, not the recipient.
| Risk | Likelihood | Impact | Rating | Owner |
|---|---|---|---|---|
| Tenant data leakage between customers in multi-tenant platform | Low | Medium | Medium | Engineering |
| Ransomware via phishing of staff | Medium | Medium | Medium | IT |
| Insider misuse of production DB access | Low | Medium | Medium | Management |
| AWS region outage, platform unavailable | Low | High | Medium | Engineering |
| Loss of certification due to failed audit | Low | High | Medium | CTO |
Treat these as management’s initial labels, with their rationale still to be obtained. They do not consistently follow E02’s subsequently agreed scoring method: “low × medium” would score two, not medium. Record that methodological mismatch and ask which method the preparer used. Do not silently recompute management’s labels as though their assumptions were known.
For a worked revision, use region interruption. Before testing recovery, assign likelihood 2 (plausible) and impact 3 (severe against service obligations): score 6, high for planning. The likelihood is an explicit assumption, not a frequency estimate. E08 later supplies recovery evidence that may affect the assessment. A low residual rating cannot be justified solely by the existence of the recovery policy.
2.5 Treatment: avoid, mitigate, transfer, accept
Once a risk is evaluated, you treat it. The vocabulary is small and worth memorising, because every control you audit for the rest of this book is implementing one of these four decisions.
- Avoid. Eliminate the risk by removing the source. Decommission the system, switch off the feature, exit the market. Decisive, often expensive, sometimes the only honest answer.
- Mitigate. Reduce likelihood or impact by putting controls in place. Most of information security is mitigation: patching, MFA, encryption, access reviews, logging, training. Mitigation rarely removes a risk; it lowers it to a level the organisation can live with.
- Transfer. Move the risk, or its cost, to another party. Cyber-insurance is the obvious example. A managed-service contract that carries an SLA is another. Transfer is never total: insurance covers the money, not the reputational damage, and a contract does not return your customers’ data. You have transferred the financial consequence, not the underlying exposure.
- Accept. Acknowledge the risk and choose to live with it, explicitly, with a reason, signed by someone with the authority to accept it. Acceptance is legitimate. Implicit acceptance, where a risk is simply never treated and never owned, is the most common failure mode in the registers you will read.
The choice is rarely pure. A real treatment plan combines them: mitigate hard, transfer what remains through insurance, and accept the residual, with the owner’s name on the acceptance. The discipline is to make the choice deliberately and record it. A control with no treatment rationale attached is a control someone installed on instinct and never justified.
2.6 Residual risk
Inherent risk is the risk before controls: the raw exposure, threat meeting vulnerability with nothing in the way. Residual risk is what remains after treatment. Mitigation moves a risk from its inherent level down to a residual level the organisation has decided is acceptable.
Residual risk is where auditors live. Inherent risk tells you about the world. Residual risk tells you whether the controls are doing their job. A risk that sits at “High inherent, High residual” may remain high despite functioning controls, or may reflect weak or unverified treatment. Distinguish those explanations. A risk at “High inherent, Low residual” has controls you now need to test, because the entire justification for that comfortable residual rating rests on them. Every residual rating in a register is a claim about a control. Your job, for the rest of the engagement, is to substantiate those claims one by one.
Two traps, both common, both dangerous.
First, treating residual as if it meant eliminated. It does not. Residual risk is the risk that remains after treatment, and it remains because no control is perfect, because controls fail, and because the threat landscape moves. A register full of “residual: low” is not a register of solved problems. It is a register of bets on controls, and bets can lose. If the organisation talks as though treatment closed the risk, the treatment is probably aspirational.
Second, the single-point likelihood × impact rating hiding aggregation and velocity. One phishing email rated “medium” tells you almost nothing, because phishing is not a one-off. It is a continuous stream. The relevant question is the likelihood that at least one succeeds over a year, not the likelihood of any single attempt. Likewise, a risk whose impact compounds fast (a tenant-data leak that spreads as customers discover it, a ransomware payload that moves laterally in minutes) cannot be captured by a static impact score. A matrix cell is a still photograph. Real risk has a frame rate. When you re-rate, ask not just “how likely, how bad” but “how often, and how fast does it get worse.”
2.7 Two standards, one loop: ISO/IEC 27005 and NIST SP 800-30
You will meet two risk standards repeatedly, and it helps to know how they differ and why it rarely matters which one you reach for.
ISO/IEC 27005 is the information security risk management standard that sits beside ISO/IEC 27001. If 27001 tells you to do risk management (it is mandatory: Clause 6.1.2 requires a risk assessment and Clause 6.1.3 requires a risk treatment plan, and the Statement of Applicability is built directly from the treatment decisions), then 27005 tells you how, in process terms: context, assessment, treatment, acceptance, communication, monitoring. It is the method document for the ISMS. For Tessera, chasing 27001 certification, 27005 is the natural home for the methodology their register should follow.
NIST SP 800-30 is the US federal equivalent, “Guide for Conducting Risk Assessments.” It is more granular on the assessment step itself: it breaks the analysis into identifying threat sources and events, vulnerabilities, and predisposing conditions, then determining likelihood, then impact, then risk. It is the document to reach for when you want a rigorous, repeatable walk through a single assessment.
Their scopes differ: ISO/IEC 27005 addresses information-security risk management, while NIST SP 800-30 Rev. 1 concentrates on risk assessment. Neither makes the other’s full process mandatory merely by being mentioned. An auditor who can read a Tessera register and map its columns to either standard, fluently, has the skill; the partisan who insists one is correct and the other is not has missed the point. The risk-based audit approach does not care which standard produced the register. It cares whether the register survives scrutiny.
2.8 The risk-based audit approach
The risk-based audit approach uses risk to decide where the audit looks hardest. You do not test every control with equal effort, because no engagement has the time or the budget for that, and because uniform effort is wasted effort: it spends the same care on a low-impact nicety as on a load-bearing control that protects the crown jewels.
Use the register as an input, then challenge it. Consider inherent exposure, dependence on critical controls, prior results and evidence reliability. A high-inherent/low-residual risk may need substantial operating tests because the low rating depends on those controls. Allocate depth proportionately while preserving required coverage; a management rating does not justify an existence-only test.
There is a second, subtler dimension. You are not only using risk to plan the audit; you are auditing risk management itself. Is the register complete? Are the owners real? Do the ratings survive a challenge? Is the cycle actually running, or was it last touched the week before you arrived? For an organisation certifying to ISO/IEC 27001, a sound risk management process is not optional; it is the spine of the whole management system. An opinion on Tessera’s readiness is, in large part, an opinion on whether their risk management is real. You cannot certify an organisation that manages controls but not risk.
The frameworks in the next chapter give a structured way to treat the risks identified here. The audit plan in Chapter 4 is built on the risk-based priorities you set here.
Consider this illustrative draft: “Tenant leakage: medium; encryption limits harm to one customer.” The supplied record establishes neither the affected population nor that encryption prevents authorised application access. Ask for the data flow, isolation boundary and contractual criteria. Retain uncertainty until those facts are available.
A second draft might declare every leak legally notifiable. That also overreaches. Notification depends on the applicable scheme and facts; chapter 9 separates assessment from notification. Your correction should remove the unsupported claim, not automatically replace medium with high.
The likelihood × impact framework was built for threats that steal data or break systems. It applies, with a twist, to AI systems themselves, because an AI deployment is a new source of risk that an organisation can own, treat, and rate like any other.
Treat the model as an asset with its own threats and vulnerabilities. A threat source might be a prompt-injection attack, a training-data extraction attempt, or simply drift as the model is retrained. The vulnerabilities are familiar to anyone who has worked with these systems: they confabulate, they leak training data under the right queries, and they fail in ways that look confident rather than loud. The impact? A Tessera support chatbot that hallucinates a refund policy it just invented is a customer-trust risk. An AI assistant that summarises customer tickets and leaks one tenant’s details into another tenant’s summary is the cross-tenant leak from the Field Note, delivered through a new channel.
When you audit an organisation that has deployed AI, the risk register should contain rows for the model: who owns it, how it was assessed before deployment, what monitoring catches drift or misuse, what the residual risk is. If those rows are missing, the organisation has not managed the risk; it has assumed it. That is the very failure this chapter is about, wearing a new face.
Lock in your re-rated Tessera risk matrix. For every rating you changed, document the rationale in a sentence another auditor could follow: what context the original rating missed (contractual, regulatory, operational, or aggregation), what you re-rated it to, and on what evidence. Note the owner you would assign where the register has none, and flag any risk you believe is missing entirely. By the end, your matrix should read less like the CTO’s “we’ve covered the big risks” and more like a defensible argument about what could actually go wrong at Tessera. This is the artefact the rest of the engagement will keep returning to.
2.9 Practice: defend a rating
Time: 20 minutes. No AI required. Use E02 and E08. Rebuild the region-outage row with a named owner, inherent likelihood/impact assumptions, the proposed recovery treatment, and the evidence needed before accepting a residual rating. Then choose a second row from the opening register and mark unknown facts explicitly. Add both to milestone 2.
Check: separate management’s original label from your agreed scoring method. A high score needs a rationale; a low residual score needs support for the controls it depends on. An evidence gap is not a measured incident probability. Do not require your revised matrix to contain a particular colour.
Framework selection next turns those priorities into criteria.