Risk management: identification, analysis, the register and treatment

Objective 5.2 is about how risk management changes the security of an organisation: finding what could go wrong, deciding how much it matters, writing it down where someone owns it, and choosing what to do about it. This one lesson now carries the whole cycle, from the asset list to the treatment decision, and it is the applied lab for 5.2.

Why this matters

This is the objective with calculations in it. SLE, ALE and ARO are simple, they are reliably asked, and that makes them among the most efficient marks on the exam.

It is also where the vocabulary must be exact. Threat, vulnerability, risk and impact are four different things, and the exam offers all four as options to a question about one of them. The four treatment options are close to guaranteed content, and "transfer" and "accept" are confused more often than people expect.

The lesson

Identifying assets, and the stakeholders who own their risk

Risk is always risk to something, so identification starts with the assets: systems, data sets, applications, premises, people, suppliers, and the business processes that depend on them. An organisation that cannot list its assets cannot list its risks, which is why the asset inventory from Domain 4 is the first input here.

Then the vocabulary, precisely:

• A threat is something that could cause harm: a ransomware group, a fire, a careless employee, a failing disk.
• A vulnerability is a weakness a threat could exploit: an unpatched service, no backups, excessive permissions.
• Risk is the combination: how likely it is that a threat exploits a vulnerability, and the impact if it does. No vulnerability, no risk.
• Impact is the consequence; likelihood or probability is how often it is expected. Threat likelihood is examined in its own right in Domain 2.

Risks are found from varied sources, because each finds a different kind: scans and penetration tests, audits, incidents and near-misses, threat intelligence, business change, and asking the people who do the work.

Every asset, and every risk to it, needs a stakeholder who owns it: the business person accountable for the asset and authorised to decide about its risk. The owner of the payroll system's risk is the head of payroll or finance, not the analyst who found the unpatched server. Security identifies, assesses and advises; the business owns and decides. An analyst accepting a risk on the organisation's behalf is acting without authority.

Write each risk as a sentence with a cause and a consequence. "Ransomware" is not a risk statement. "A malicious attachment lets malware encrypt the file servers, and we cannot trade for five days" is one.

Scoring and categorising risk, qualitatively or quantitatively, and when each is honest

Categorising groups risks so they can be owned and compared: by type (technical, operational, compliance, financial, third-party, reputational), by business unit, or by the asset class affected. Categories show concentration: twelve medium risks all sitting with one supplier are one large risk.

Scoring rates each risk so the list can be prioritised, and there are two approaches.

Qualitative scoring uses descriptive ratings: high, medium or low, or a 1 to 5 scale for likelihood and impact combined in a risk matrix. It is fast, works where no data exists, and communicates well to non-specialists. Its weakness is that the numbers are not really numbers. Two "high" risks may differ by orders of magnitude in cost, and a matrix cannot tell you whether a control is worth its price.

Quantitative scoring puts money on it, using the formulas in the next section. It supports genuine cost-benefit decisions, and it needs data (asset values, frequency estimates) that organisations often do not have.

The honest position: quantitative where you have data, qualitative where you do not, and never pretend qualitative output is quantitative. The classic failure is a five-by-five matrix whose cells are multiplied into a "risk score" of 16 that is then treated as a measurement. It is an ordinal rating dressed as arithmetic.

SLE, ALE and ARO, and the arithmetic the exam will make you do

The formulas. Learn these exactly.

• SLE (single loss expectancy): the cost of one occurrence. Where a question gives an asset value and the proportion lost in one event (the exposure factor), SLE = asset value × that proportion. Some questions simply state the loss from one event.
• ARO (annualised rate of occurrence): how many times per year it is expected. Once every four years is 0.25; twice a year is 2.
• ALE (annualised loss expectancy) = SLE × ARO. The expected cost per year.

A worked example of the shape the exam uses:

A server is valued at £80,000. A flood would destroy 60% of its value. Floods in this location occur once every 20 years. What is the ALE?

• SLE = 80,000 × 0.6 = £48,000
• ARO = 1 / 20 = 0.05
• ALE = 48,000 × 0.05 = £2,400

The point of ALE is the decision it enables. Compare the ALE before the control minus the ALE after it against the annual cost of the control. A control costing £10,000 a year to remove a £2,400 ALE is not worth it on those numbers alone; one costing £500 a year clearly is.

Two cautions the exam rewards:

• ALE is an average, not a prediction. An ARO of 0.05 means nothing for nineteen years and £48,000 once. For a risk that could end the organisation, the average is the wrong basis for the decision.
• Some impacts do not convert to money honestly: loss of life, loss of a licence, reputational collapse. Forcing them into a currency figure produces a confident wrong answer.

The risk register: owners, current mitigations, residual risk and the review that keeps it true

The risk register is the record of identified risks and what is being done about them. A risk that is found and not recorded has not been managed; it has been noticed.

Each entry holds:

• the risk statement, with its category;
• the owner: a named person, not a team;
• the likelihood and impact, and the resulting score;
• the current mitigations: the controls already in place;
• the residual risk: what remains after those mitigations;
• the chosen treatment, with actions and dates;
• the status and the next review date.

The distinction to hold is between inherent risk, before controls, and residual risk, after them. Residual risk is what the owner actually decides about. Recording current mitigations honestly matters: listing a control that is planned but not yet running makes the residual risk look lower than it is.

Two things keep a register true. Communication: the register is shared with the people who own and fund the risks, in business terms, rather than living in the security team's folder. Reviews: each entry is reviewed on a schedule, and again when something changes (a new system, an incident, a supplier change). A register nobody reviews describes the organisation as it was, and the gap between that and reality is where the next incident lives.

Transfer, accept, avoid or mitigate, weighed against appetite, business impact and oversight

The four treatments. Learn the distinctions exactly.

• Mitigate: reduce the likelihood or the impact with controls. Patch, segment, back up, train. The most common response.
• Transfer: move the financial consequence to someone else, classically through insurance, or through contract terms with a supplier. What transfers is money, never the obligation: the regulator still holds you responsible, and your customers still blame you. That is the most tested nuance in this list.
• Avoid: stop doing the activity. Decommission the system, decline the market, do not collect the data. The only treatment that removes the risk entirely; its cost is the opportunity given up.
• Accept: take no further action, knowingly. Legitimate when treatment costs more than the expected loss, or the residual risk is within appetite. It must be documented, owned and revisited; undocumented acceptance is neglect.

The choice is not made on the score alone. Business-level considerations shape it:

• Risk appetite: how much risk the organisation is willing to take in pursuit of its objectives, set by its leadership. The same residual risk can be a reasonable acceptance in one organisation and a mandatory fix in another. There is no universally correct level.
• Business impact analysis (BIA): which functions matter most and how fast loss of them hurts. A risk to a function the BIA ranks critical is treated harder. The recovery metrics a BIA produces are covered with resilience in Domain 3.
• Stakeholder involvement: the owner, the people who run the process, and the people affected should be part of the decision, not informed after it.
• Management oversight: significant acceptances and treatments are approved at the right level and visible to senior management, so nobody quietly accepts a risk too large for their authority.
• Regulatory and legal factors: some risks cannot be accepted, because a law or regulator requires the control. Some can only be avoided.

What to take into the exam

• Threat plus vulnerability gives risk. A threat with nothing to exploit is not a risk.
• SLE is the cost of one event; ALE = SLE × ARO; "once every N years" gives ARO = 1/N.
• Compare the drop in ALE with the annual cost of the control.
• The risk owner is a named business person, not the analyst who found it.
• Inherent is before controls, residual is after; residual is what is decided about.
• Transfer moves the money, never the obligation. Avoid is the only treatment that removes the risk. Acceptance must be documented and owned.