You closed module 3 with an unanswered question: Nimbus has 38 people, a limited budget and a list of improvements that does not fit into a year, so what gets done first? This lesson is the method for answering that defensibly. You will not learn any new technology: you will learn to turn what you already know — the asset inventory from 01-04, STRIDE, the attack catalogue from 02-02, the measures from 02-04 and the cryptographic protections from module 3 — into a justified, written, reviewable order of priority. It is the least technical and the most decisive lesson of the course, because a team that protects whatever it fancies protecting spends the entire budget and still leaves open the hole the attacker in 02-06 walked through.

1. Without prioritisation there is no security
2. The risk equation and what it really means
3. The full process: ISO 31000 and ISO 27005 in an SME
4. Establishing the context: the step almost everyone skips
5. Identifying risks: from the asset and STRIDE to a well-written risk
6. Qualitative analysis: scales, the 5×5 matrix and acceptance levels
7. What the matrix cannot tell you
8. Quantitative analysis: SLE, ARO, ALE and ROSI
9. Inherent risk, control and residual risk
10. Risk appetite and tolerance: who sets the threshold
11. The four treatment strategies
12. The risk register as a living artefact
13. When it is reviewed and what triggers a reassessment

Marta, Nimbus's CTO, comes out of module 3 with a list of 47 possible improvements. She has an annual security budget of 18,000 € (a fictitious figure, but of a realistic order for an SME of 38 people) and a single systems person: optimistically, Lucía can devote 25 % of her working time to security without operations falling over — around 440 hours a year. Iván has no hours allocated at all: his job is to ship features.

The 47 improvements do not fit, and no combination of effort makes them fit. The decision, therefore, is not "what do we do" but "what do we leave undone", and that is exactly the decision a risk assessment lets you take with arguments instead of with intuition.

Defensible is the key word. When a customer asks a year from now "why didn't you have EDR?", the right answer is not "we didn't get round to it", but "we assessed it, it came twelfth on the list, it was planned for the second half of the year and management accepted that in writing". That is risk management.

It is, almost literally, the most misinterpreted sentence in security. Three clarifications make it useful:

(a) It is not a formula, it is a conversation tool. Nobody knows the true likelihood of Nimbus suffering ransomware next year. What the equation does is force you to separate two questions that people mix together: "how often does this happen?" and "how much does it hurt when it does?". When Lucía says "we need to renew that certificate now", the equation asks: how likely is it to expire without anyone noticing, and what exactly happens if it goes down? If the answer is "high" and "the entire platform for two hours", that competes seriously with the rest of the list.

(b) Impact is business impact, not technical impact. "The database is compromised" is not an impact: it is an event. The impact is "40 clinics with no diary, notification to the supervisory authority, an estimated loss of two customers and legal costs". A risk whose impact is written in technical terms cannot be prioritised by management, which is precisely who has to do it.

(c) ISO 27005 adds a third factor: the threat exploits a vulnerability on an asset. In an SME it is enough to fold that into the likelihood, because the vulnerability is what makes the likelihood high. That ransomware exists is a constant for everyone; that Nimbus's backups sit in the same cloud account is what drives its likelihood of suffering an irreversible disaster.

ISO 31000 is the generic risk management standard — it applies to financial, occupational or any other kind of risk — and ISO 27005 is its application to information security risk. Both describe the same cycle:

Two details of the diagram matter more than the diagram itself: communication is not a step, it runs across all of them — an assessment done by Lucía on her own and presented at the end is an assessment management does not feel is theirs and will therefore not fund; and the cycle closes back on "Identify", not on "Analyse", because a review does not merely rescore what is already there: it looks for new risks, since the architecture has changed.

Before you identify a single risk you have to fix four things in writing. Without them, the rest of the exercise produces numbers that cannot be compared with one another.

The time horizon is what saves the most arguments. "It's likely" means nothing unless you say over what period. At Nimbus every likelihood is expressed as times per year, and that makes two different people score similarly.

You already have the two inputs: the A-01…A-22 inventory from 01-04 and the STRIDE modelling from the same chapter. The procedure is mechanical: asset → applicable STRIDE category → known vulnerability → written risk → owner (who is the asset owner).

A badly written risk cannot be scored; always use this structure:

Notice that the correct wording already contains, implicitly, the missing control. That is no accident: a well-written risk all but proposes its own treatment.

Do not invent risks: collect them from where they already are.

The quality of a qualitative analysis depends entirely on the scales having objective criteria, not adjectives. "Medium" means nothing; "between once every 3 and once every 10 years" does.

You score the worst of the five criteria, never the average.

That Nimbus has a dedicated personal data column is not decorative: its customers are clinics and the appointment history indirectly reveals health information. It is the dimension that drives level 5 impacts.

Without that last table the matrix decides nothing. Scoring is half the job; the other half is having agreed in advance what happens with each band, because agreeing it after seeing the numbers invites you to move the threshold until the result is comfortable.

• Misleading aggregation. Ten "medium" risks that share a root cause — all of them depend on A-05 — are not ten middling problems: they are one critical problem in disguise, and the matrix will not see it because it scores risks in isolation. Remedy: group by root cause before deciding.
• Mid-point bias. Anyone who is unsure scores a 3. A register with 60 % of its entries at 3×3 is not being assessed: it is being filled in. Remedy: ban a 3 without written justification, or use an even scale with no centre.
• The bands are ordinal, not cardinal. A 16 is not "twice as bad" as an 8; you cannot add or average scores. And there is compression at the top end: everything catastrophic ends up as a 5, so a 200,000 € leak and a 2 million € one score the same. For those few cases you fall back on the quantitative approach.
• Assessor bias. Lucía overrates what she controls; Iván underrates what he wrote. Remedy: score as a group, not by e-mail.

The quantitative approach puts euros where the qualitative one puts colours. It does not replace the matrix — it is far too expensive for 47 risks — but it is indispensable for justifying a specific investment to management.

Read that result carefully, because it contains the whole lesson. The leak is far more serious per event (192,000 € against 52,000 €), but the outage has the higher ALE because it is expected five times more often. If Nimbus chose by ALE alone, it would invest in availability before confidentiality. That counter-intuitive result is exactly what the method contributes: it forces the decision to be discussed rather than assumed.

ROSI (Return On Security Investment) answers "is this control worth it?". It is calculated as (Saving − Annual cost of the control) / Annual cost of the control × 100, where the saving is the difference between the ALE before and after applying it.

This reproduces, in numbers, the conclusion of the 12 measures in 02-04: MFA and immutable backups are the two highest-return investments, and EDR — the only one with a real mid-range cost — comes a long way behind. It is not that EDR is bad: it is that it is in the wrong place in the order.

Essential warning. The four input numbers on each line are human estimates. A ROSI of 7,367 % conveys a precision that does not exist. What the calculation demonstrates is not "7,367", but the order of magnitude and the relative order: MFA is two orders of magnitude better as an investment than EDR. Always present these numbers with their range ("between 3,000 % and 12,000 % depending on the ARO estimate") and document where each assumption comes from. A quantitative analysis with hidden assumptions is worse than an honest qualitative one.

Three rules that are broken daily. (1) Residual risk is never zero: anyone presenting a register with residuals of 1 is either lying or has not understood the exercise; the goal is to take it below the appetite, not to eliminate it. (2) A control only reduces risk if it genuinely works: scoring the residual assuming MFA on every account when it is on half of them is accounting fraud, so the residual is scored against the verified state, and that verification is the subject of 04-03. (3) It is worth knowing whether the control reduces likelihood or impact: MFA reduces likelihood — they do not get in; immutable backups do not reduce it at all and reduce impact — they get in, but you recover. A risk treated only with likelihood controls is left without a safety net when the likelihood materialises anyway.

Appetite is the amount of risk the organisation is willing to take on in order to achieve its objectives: a strategic statement. Tolerance is the acceptable deviation around that appetite, expressed per category and in measurable terms. This is how Nimbus has it written down:

Without this document the matrix decides nothing. You can score 47 risks perfectly and still not know which ones have to be treated, because "High" only means something once somebody has said in advance what happens with High. At Nimbus management sets it on Marta's proposal, and it is deliberately asymmetric: nil appetite on health data and medium on technical debt. That asymmetry is the company's security strategy, written in ten lines.

The fifth option, which does not exist: ignore. Accepting and ignoring produce the same bill and are entirely different things. Accepting has a name, a signature, a date and an expiry; ignoring has none of that. The difference shows up on exactly the day of the incident.

And the three traps that stop a policy paying out: (1) the prerequisites — current policies require in writing MFA on administrative access, verified backups and patch management, so if Nimbus declares it has MFA and the incident shows the consultancy was getting in without it, the insurer can reject the claim for a misstatement in the declaration; (2) the exclusions — acts of war or of a state, relevant in attributed ransomware; failure of an undeclared supplier; regulatory fines in some jurisdictions; and (3) the process obligations, because many policies require you to use the insurer's forensic and legal team and to notify within a short deadline: calling your trusted consultancy first can invalidate the cover.

Validation note. Taking out cyber insurance, reading its exclusions and the declarations you sign in the underwriting questionnaire have serious contractual consequences. Review it with a specialist broker and with legal advice before signing, and review it again whenever your architecture changes. Transferring the risk is not transferring the responsibility.

This is the deliverable of the lesson, and you will need it in the final project of module 7. A register is a living document: if its last modification date is more than six months old, it is not a register, it is a memory.

The remaining seven risks follow exactly the same scheme; they are summarised here so as not to repeat the structure:

Look at the register as a whole and you will see three things that no single entry says on its own: four of the eleven risks name the A-05 cloud account directly and almost all the rest depend on it (01-04), most of the treatments are cheap, and the only formal acceptance carries a signature, a date and an expiry. That last field is what stops an acceptance turning into a permanent oversight. Notice R-09 too: it has no adversary and is still in the High band.

Monthly, Marta and Lucía review the status of the open treatments: are they moving? Quarterly, with Iván, the Critical and High risks are reviewed: is the score still valid? And annually management carries out the full review: new risks, closure of obsolete ones and the appetite.

On top of that, the triggers that force a reassessment without waiting for the calendar: an architecture change (a new integration, a migration, the new mobile app); an incident of your own or in your sector — any incident reassesses the likelihood of its entire class: the case in 02-06 should push ransomware to level 5 for all healthcare SaaS; a new supplier or a change in an existing one (04-04); a regulatory or contractual change, such as a customer requiring ISO 27001; an organisational change, such as Lucía leaving; and the result of an audit or a penetration test (05-03, 06-04).

• Doing the assessment once and filing it away. This is mistake number one and the most expensive: a register from 18 months ago describes a company that no longer exists. Tip: put the quarterly review in the calendar with the invitation accepted, and treat the register like code: version control, reviewed changes, history.
• Scoring without written criteria. If two people score the same thing 4 and 2, the problem is not them: it is that "likely" is not defined. Do not score anything until the tables in section 6 are approved, and keep them in front of you during the session.
• Letting only the technical team do the assessment. Lucía knows what can break; only Sara and Marta know what it costs when it does. A purely technical assessment produces badly estimated impacts and, worse still, no authority to allocate budget.
• Confusing the register with the to-do list. "Update the server" is not a risk, it is a treatment. If your register is full of infinitives, you are using it as a backlog: apply the formula in 5.1 to every entry. And do not inflate everything to Critical to get budget: it works once; the second time, management stops reading the document. If more than 15 % of your register is Critical, you are not prioritising.
• Scoring the residual with controls that do not yet exist. It is called project optimism and it falsifies the whole register. The desired state goes in treatment, not in residual.
• Forgetting the risks with no adversary. R-09 (Lucía is the only systems person) and R-10 (provider outage) have no attacker and are just as real. Availability breaks on its own.

The discovery work in 01-04 turned up a spreadsheet with the payroll of all 38 employees shared through a public link, created by Sara 14 months ago and never revoked.

1. Write the risk using the formula in section 5.1.
2. Score likelihood and impact with the scales in 6.1 and 6.2, justifying each number.
3. Determine the band and the applicable decision rule.
4. Propose a strategy and a treatment, and estimate the residual risk.

Nimbus is considering a managed detection service that would watch the logs, at a cost of 14,400 € a year. Its main effect is to reduce the time to detect, not to prevent entry.

1. For R-01 (ransomware, ALE of 96,000 €), which factor of the equation does a detection service change: the likelihood or the impact? Reason it through with the timeline in 02-06.
2. If you estimate it reduces the ALE by 35 %, calculate the ROSI.
3. Compare it against the three options in section 8.2 and decide what you would recommend to Marta this year. Would your answer change if Nimbus already had MFA and immutable backups?

Marta receives the risk register of a comparable company and you spot: 34 of 40 risks scored 3×3; every owner is "IT Department"; the residual column empty in 31 entries; 6 risks with an "Accept" strategy and no signature or date; and last_review identical across all 40 entries, 19 months ago. Identify what problem each symptom reveals, what correction you would apply and in what order.

Exercise 1

(1) "If anyone who receives or discovers the public link accesses the payroll spreadsheet held in corporate storage (A-16), which has been shared for 14 months with no restriction and no expiry, then the salaries, DNI (the Spanish national ID number) and bank details of all 38 employees are exposed, breaching data protection law, with probable notification to those affected and to the supervisory authority, and serious damage to internal trust."

(2) Likelihood = 4 (High): it requires no technical capability at all, you only need the link; it has been live for 14 months, has probably circulated by e-mail and may be indexed. This is not a remote hypothesis, it is an exposure in progress. Some assessors would argue for a 5; the real difference is whether there is evidence of access, and that is checked in the storage access log before scoring. Impact = 4 (Major): identifying and financial personal data of employees — but not of customers and not health data, which keeps it below 5 — probable notification, severe internal impact, moderate financial impact. Level = 16 → Critical band.

(3) Critical band → immediate treatment, plan within 7 days, management informed. With one important nuance: revoking the link takes two minutes, so the treatment must not wait for the plan. First you stop the exposure; then you document it.

(4) Strategy Mitigate, in three layers: (a) revoke the link today and review the access log to establish whether there was real exposure — information you need in order to decide on notification; (b) move the file to a folder restricted to Sara and management; (c) attack the cause by disabling the creation of public links at organisation level and reviewing all the existing ones. With (a)+(b) the residual falls to 2 × 4 = 8, Medium; with (c) in place, to 1 × 4 = 4, Low. Part (c) is the only one that turns a one-off fix into a control, and the only one that stops the same risk reappearing in six months with a different file.

Exercise 2

(1) Detection does not reduce the likelihood: the attacker gets in anyway. It reduces the impact, by shortening the dwell time. In the 02-06 case the attacker was inside for 20 days; exfiltration happened between days 13 and 19 and the destruction of the backups on day 20. Detecting on day 2 would not have prevented the compromise, but it would have prevented the exfiltration of 1.2 TB and the destruction of the backups, which is where most of the harm sits. That is why detection has a high value despite preventing nothing.

(2) Saving = 96,000 × 0.35 = 33,600 €. ROSI = (33,600 − 14,400) / 14,400 × 100 = 133 %.

(3) At 133 % it falls below MFA (7,367 %) and immutable backups (2,033 %), and is practically level with EDR (150 %). Recommendation for this year: no, and not because it is bad, but because order matters: detecting an incident quickly and then being unable to restore still ends in disaster. And yes, the answer changes if those two are already in place: once the cheap prevention and recovery controls are done, the remaining ALE concentrates precisely on what detection attacks, its effective reduction rises and it becomes the next logical investment. This reveals something an isolated ROSI hides: the return on a control depends on which other controls already exist, so the calculation is redone every year.

Exercise 3

Order of correction: 5 → 1 → 2 → 3 → 4. First bring the document back to life, because correcting everything else on top of a dead register is putting make-up on a corpse; then fix the scoring method, on which everything else depends; then the owners, who are the ones who execute; then the residual; and finally formalise the acceptances, which is a signing formality once the rest is right.

You have learned the method that turns an unmanageable list into a defensible order, which was exactly the promise module 3 closed on. You know that without prioritisation there is no security, because Nimbus's budget and Lucía's 440 annual hours are finite, and that of the three ways of prioritising only one can be defended to a customer, to management or to an auditor.

You handle the risk equation for what it genuinely contributes: not an exact formula, but the obligation to separate "how often does it happen" from "how much does it hurt", and to write the impact in business terms so that whoever holds the budget can prioritise it. You know the ISO 31000/27005 cycle adapted to an SME, with communication as a cross-cutting activity, and you know how to identify risks from the A-01…A-22 inventory, from STRIDE and from the discovery findings, writing them with a formula that makes the risk all but propose its own treatment.

You are on top of qualitative analysis with scales built on objective criteria — not adjectives — and the 5×5 matrix with its acceptance bands, along with its limits: misleading aggregation, mid-point bias, ordinals that cannot be added and compression at the top end. And you know when to move to the quantitative: SLE, ARO and ALE calculated for the attachment leak and for the 48-hour outage, with the uncomfortable result that the outage has the higher ALE despite being far less serious per event, and with the ROSI that reproduces in euros the conclusion of 02-04 — MFA and immutable backups are two orders of magnitude better as an investment than EDR — always with the warning that the input data are estimates and what counts is the order, not the decimal. You distinguish inherent, control and residual with their three rules — the residual is never zero, only the verified control counts, and it is worth knowing whether it reduces likelihood or impact — you have the appetite and tolerance statement that management signs and without which the matrix decides nothing, you know the four treatment strategies with cyber insurance and its three real traps, and you take away the artefact: the risk register template and a Nimbus register with eleven risks that converge again and again on A-05, where the only acceptance carries a signature, a date and an expiry.

But a risk register, however good it is, expires with the person who wrote it. It says what Marta decided in February 2026; it does not say what a new employee should do next Tuesday, nor what is mandatory and what is merely recommended, nor who can authorise an exception. The decisions you have taken here — mandatory MFA, just-in-time access, a ban on public links, secrets in a manager and not in .env — need to stop living in the heads of three people.

In the next lesson, Security Policies (04-02), you will see how a decision is fixed in writing so that it outlives whoever took it: the hierarchy policy → standard → procedure → guideline, the anatomy of a policy with a complete reusable template, two Nimbus policies written out in full, the approval and communication process, and the exceptions register with mandatory expiry, where you will meet again — this time in writing — the consultancy's permanent access.