Information Security Risk Management: A Practical Guide

A founder once asked me, with real frustration, "Just tell me what I need to buy so we're secure." I told him the honest answer, which is that "secure" is not a state a business can be in. It's a direction. What he could do was decide, with open eyes, which risks he was going to reduce, which he was going to hand to someone else, and which he was going to live with. That conversation was the most useful hour of security work we did together, and it involved no software at all. That conversation is what information security risk management actually is — not a spreadsheet, a set of decisions.

Risk management is the third foundation of information security. The CIA triad tells you what you're protecting. Threat modelling tells you from what. Risk management tells you how much effort each threat deserves, which is the question that actually determines what you do on Monday.

Part 3 of 10 · Foundations of Infosec. Previous: Threat Modelling. Next: Multi-Factor Authentication.

Key takeaways

Information security risk management is how you decide what each threat deserves in effort and money.
Risk = likelihood × impact; quantify as ranges rather than Low/Medium/High colours.
Four responses: mitigate, avoid, transfer, accept — and accepted risk must be written down.
A short, owned, quarterly-reviewed register beats a 300-row spreadsheet nobody reads.

What information security risk management measures

In everyday speech "risk" means "something bad that might happen". In security it has a tighter definition. ISO 27005 and NIST SP 800-30 both frame it the same way: risk is a function of the likelihood that a threat exploits a vulnerability and the impact if it does.

Three words in that sentence deserve unpacking.

A threat is a potential cause of harm — a ransomware crew, a careless employee, a flood. A vulnerability is a weakness that a threat could exploit — an unpatched server, an unlocked door, an untrained employee. Impact is what it costs you when the two meet: money, time, reputation, legal exposure, in the worst cases safety.

Risk exists only where all three coincide. A vulnerability with no plausible threat is not a risk; a threat with nothing to exploit is not a risk; and a threat exploiting a vulnerability that affects nothing you care about is not a risk either. That sounds obvious, but a great deal of security spending goes on vulnerabilities that no threat is realistically pursuing, while genuine risks go unaddressed because they don't show up in a scanner.

Qualitative and quantitative

Most organisations assess risk qualitatively: likelihood is Low/Medium/High, impact is Low/Medium/High, and the two are combined in a heat map. It's quick, it's intuitive, and it's what most risk registers look like.

It's also weaker than it looks. Douglas Hubbard and Richard Seiersen, in How to Measure Anything in Cybersecurity Risk, make a persuasive case that heat maps introduce their own errors: different people mean different things by "Medium", the categories compress wildly different outcomes into one colour, and multiplying ordinal scales is mathematically meaningless even though everyone does it.

The alternative is quantitative risk analysis, which puts numbers on things: an estimated probability per year and an estimated loss range. The most widely used model is FAIR (Factor Analysis of Information Risk), an Open Group standard that decomposes risk into loss event frequency and loss magnitude, each estimated as a range rather than a point.

You do not need to become an actuary. But even a rough quantitative habit changes conversations. "This is a High risk" invites argument. "We estimate a 20–40% chance per year of a ransomware incident, with a cost between QAR 200,000 and 2 million once you include downtime" invites a decision — and lets you compare it directly with the cost of the control that would reduce it.

Where do the numbers come from? From data you already have (how many phishing emails got through last quarter?), from public reporting (the IBM/Ponemon Cost of a Data Breach study has put the global average cost of a breach in the high single-digit millions of dollars for several years, with small businesses far lower in absolute terms and often higher relative to revenue), and from calibrated estimation — a learnable skill Hubbard spends a whole chapter on.

The four responses

Once a risk is understood, you have the same four options I described for threats, because a treated threat is a managed risk:

Mitigate. Reduce likelihood (patch the server, train the staff, add MFA) or impact (segment the network so a compromise stays contained, keep offline backups so ransomware is an inconvenience rather than an extinction event). Most security work lives here.

Avoid. Stop doing the thing that creates the risk. Don't store the data. Don't expose the service to the internet. Don't run the legacy system. This is chronically under-used because it feels like giving something up, but it is the only response that reduces risk to zero.

Transfer. Cyber insurance, contractual liability, or outsourcing to a provider whose business is managing that risk. Transfer is real but partial: insurance pays money, it doesn't restore your reputation, and insurers increasingly require evidence of basic controls — MFA, backups, endpoint protection — before they'll write a policy at all.

Accept. Decide the risk is within your tolerance and document that you decided. This is legitimate and necessary; you cannot mitigate everything. What is not legitimate is implicit acceptance — the risk nobody assessed because nobody looked.

Risk appetite: the conversation nobody has

Every one of those decisions depends on something most organisations have never written down: their risk appetite. How much risk are you willing to carry in pursuit of your goals?

A startup burning through a funding round has a different appetite from a bank. A clinic holding patient records has obligations a marketing agency doesn't. Neither is wrong, but each needs to know which one it is, because "how much should we spend on security?" has no answer without it.

The ISO 27001 standard requires management to define risk acceptance criteria for exactly this reason. In practice, I've found a single page works: a short statement of what the organisation will not tolerate (any exposure of customer payment data; more than 24 hours of downtime in core systems), what it will tolerate with controls, and who is authorised to accept residual risk above a threshold. Signed by someone senior. That page turns every later argument into a lookup.

Why most risk registers are theatre

I've read a lot of risk registers. Many are spreadsheets with hundreds of rows, each rated Medium, updated annually by the one person who understands the spreadsheet, and read by no one. They exist to satisfy an auditor, and they succeed at that while doing nothing to reduce risk.

The failure modes are consistent:

Too many entries. If everything is on the register, nothing is prioritised. A register with fifteen well-understood risks beats one with three hundred.
No owner. A risk without a named person responsible for it is a risk nobody is managing.
Static. Risks change. New systems appear, threats evolve, controls decay. A register reviewed once a year is describing the past.
Disconnected from money. If the register doesn't drive budget decisions, it isn't managing risk; it's recording anxiety.

A useful register is short, owned, reviewed at least quarterly, expressed in terms decision-makers understand, and visibly connected to what the organisation actually spends and does.

Residual risk and the honesty test

After you've applied controls, some risk remains. That's residual risk, and being explicit about it is the honesty test of a security programme.

Consider MFA. It dramatically reduces the risk of account takeover — Microsoft has reported that MFA blocks the overwhelming majority of automated credential attacks. It does not eliminate it: attackers now run phishing kits that proxy the MFA prompt in real time, and "MFA fatigue" attacks bombard users with push notifications until one is approved. The residual risk is real, it's smaller than before, and the right response might be phishing-resistant MFA (passkeys, FIDO2 keys) for the highest-value accounts and acceptance for the rest.

Saying "we have MFA, so we're covered" fails the honesty test. Saying "we've reduced account takeover risk substantially and accept the remaining exposure for standard users while moving admins to hardware keys" passes it.

Doing it in a small business

You don't need a GRC platform. Here's a workable approach for an organisation with no dedicated security staff.

List your critical assets — the five to ten systems and datasets the business can't run without. You did this in the CIA triad exercise.
For each, name the two or three most plausible threats. Use your threat model. Be honest that the most plausible threats are boring: phishing, reused passwords, unpatched software, a departed employee's account.
Estimate likelihood per year and cost if it happens, as ranges. Don't agonise; a rough range beats a confident colour.
Rank by expected loss, roughly likelihood times midpoint of impact.
For the top items, choose a response and put a name and a date on it. Compare the cost of the control against the expected loss it prevents; if the control costs more than the risk, accept the risk and move on.
Write the appetite page and get it signed.
Review quarterly, and after any incident.

This will fit on two pages. It will also be more useful than most of the risk frameworks I've seen at companies fifty times the size, because it will actually be read by the people making decisions.

The mindset

The deepest shift risk management asks of you is to stop thinking of security as a property you either have or lack, and start thinking of it as a portfolio of bets. Every control is a bet that its cost is lower than the loss it prevents. Every acceptance is a bet the other way. You will get some of these wrong. The goal is not to be right every time; it's to make the bets consciously, at a size you can survive, and to learn from the ones that go against you.

The founder who wanted to know what to buy? We ended up buying very little. We turned on MFA, fixed the offboarding process, moved backups offline and wrote the appetite page. Total cost: a few hundred riyals a month and two afternoons. His expected annual loss dropped by more than any product on the market could have achieved, and he could explain why to his investors. That's what managed risk looks like.

Further reading

NIST SP 800-30 Rev. 1 — Guide for Conducting Risk Assessments
ISO/IEC 27005:2022 — Guidance on managing information security risks
The Open Group, Open FAIR Body of Knowledge
Douglas W. Hubbard and Richard Seiersen, How to Measure Anything in Cybersecurity Risk (2nd ed., Wiley, 2023)
IBM Security / Ponemon Institute, Cost of a Data Breach Report (annual)

This series