Risk

In information security, risk is treated as a function of three inputs - a threat, a vulnerability it can exploit, and the impact if it does - modulated by likelihood. NIST SP 800-30 Rev. 1 defines risk as a function of the likelihood of a threat event occurring and resulting in adverse impact, and the magnitude of that impact; ISO/IEC 27005 (the information-security application of ISO 31000) frames the same relationship. The practical output of an assessment is a risk register that pairs each asset-threat-vulnerability-consequence statement with a rating, most commonly on a likelihood-by-impact matrix rendered as a heat map. The heat map is a communication and prioritisation aid, not a calculator: two risks in the same red cell can warrant very different responses, and the ordinal 1-5 scores are not true numbers to be multiplied.

Risk is quantified along a spectrum. Qualitative methods use worded scales and are fast and data-light but subjective; quantitative methods express risk in money, classically as Single Loss Expectancy times Annual Rate of Occurrence to yield Annualised Loss Expectancy, or, in more rigorous models such as FAIR, as loss distributions produced by Monte Carlo simulation and read as a loss-exceedance curve. Quantification exposes tail risk and enables cost-benefit comparison of controls but demands defensible frequency and impact data, so most organisations start qualitative and quantify only the few decisions where a large investment turns on the number.

Once rated, each risk above the acceptance line is treated by one of four standard options: mitigate/modify (add or strengthen controls), transfer/share (insurance or contractual allocation, though accountability stays with the owner), avoid (stop the activity), or accept/retain (consciously live with it as a documented, authorised decision). The gap between inherent risk (before controls) and residual risk (after controls) is what treatment moves; residual risk must be formally accepted by someone with authority, and risk appetite and risk tolerance - the amount and type of risk the organisation is willing to pursue or bear - set where the acceptance line sits. Regulatory drivers make this explicit: NIS2 Article 21 requires risk-management measures proportionate to the risk, and ISO/IEC 27001:2022 clauses 6.1.2-6.1.3 require a documented risk assessment and a risk treatment plan mapped to controls.

Two misconceptions recur. First, risk is often confused with its parts: a threat is only a possibility and a vulnerability only a weakness, whereas risk weighs likelihood against impact, so "we have a critical vulnerability" is not yet a risk statement until exposure and consequence are considered. Second, risk is treated as static, but it is conditional on the current control set, the threat landscape and the business context, all of which change; a register that is not periodically reviewed and re-scored records risks that may no longer exist or misses new ones. Sound practice records assumptions, owners, the control baseline and a review date for every entry.