Two departments of the same company assess the risk of a ransomware attack on the sales system. IT puts likelihood at 4 and impact at 5, which gives 20 points and a red cell. Finance, working from the same 5×5 matrix, scores it 2 and 4, so the risk lands in the yellow zone. At the board meeting nobody can say which score is right, because both follow rules that nobody ever wrote down.
The risk matrix is the simplest risk assessment tool in cybersecurity, and that is exactly why it is easy to break. A coloured grid looks like a method, but without described scales, a time horizon and a rule for combining likelihood with impact, every assessor builds a private matrix in their head. A well-built one gives results that two people can reproduce independently.
What is a risk matrix and what is it for?
A risk matrix is a table that combines the likelihood level of an event with the level of its impact and assigns a risk level to that pair. It lets you compare many scenarios on one scale and decide which to tackle first. It does not replace threat identification or decisions on risk treatment; it only orders the results of a risk assessment.
The NIST Cybersecurity Framework 2.0 of 26 February 2024 describes where the matrix fits. In the ID.RA category, subcategory ID.RA-04 covers identifying and recording potential impacts and likelihoods, and ID.RA-05 covers using threats, vulnerabilities, likelihoods and impacts to understand inherent risk and inform risk response prioritisation. The matrix is a tool for that second step.
The wider process, from asset inventory to the report, is covered in the guide what is IT risk analysis, and the ISO 27005, NIST RMF and FAIR methodologies are compared in the article on cybersecurity risk assessment, which also contains a basic 5×5 matrix example. The matrix itself, however, requires several separate decisions: about the scales, about how scores are combined and about thresholds.
Why does the same 5×5 matrix give different results?
The same matrix gives different results because its levels have no definitions and every assessor fills them in from personal experience. The word “likely” means one thing to a system administrator and another to a finance director.
NIST SP 800-30 Rev. 1 of September 2012 says so directly: unless each value of a qualitative scale is clearly defined or illustrated with meaningful examples, different experts may produce significantly different results. The same document names two remedies: a justification next to each assigned value, and tables or other well-defined functions for combining values.
In practice this means three documents, not one. The first defines the likelihood levels, the second defines the impact levels, and the third is the rule that turns a pair of scores into a risk level. Only the full set lets you reproduce an assessment a year later, after a team change or in front of an auditor.
Assessments in specific environments add their own impact criteria. Why a vulnerability score is not a risk assessment of a production process is explained in the article on risk assessment in OT.
How do you define a likelihood scale?
You define a likelihood scale through frequency or a description of the chance within a fixed time horizon, for example the next 12 months. Without a horizon a “high” score means nothing, because almost any event is likely over a decade.
NIST SP 800-30 Rev. 1 recommends associating likelihood and impact assessments with a specific time period. For non-adversarial events such as a failure or an error, Table G-3 of the document gives example frequency thresholds:
| Level | Description according to NIST SP 800-30 (Table G-3) | How to write it in company policy |
|---|---|---|
| Very high | more often than 100 times a year | event visible in the logs every week |
| High | between 10 and 100 times a year | event every month or more often |
| Moderate | between 1 and 10 times a year | event several times a year |
| Low | less than once a year, but more than once every 10 years | event known from the company’s history |
| Very low | less than once every 10 years | event known only from the industry |
For deliberate actions such as an attack, frequency is often unknown. NIST then describes the levels in words, from “adversary is almost certain to initiate the threat event” to “highly unlikely”. It is worth translating those descriptions into facts an assessor can check: have similar attacks hit companies in the sector, is the vulnerability exposed to the internet, does a public exploit exist.
It also helps to split the assessment into two steps, which NIST combines in Table G-5. The first step is the chance that the event occurs at all, the second is the chance that, once it occurs, it causes harm. A phishing campaign after which a captured password is not enough to log in, because the account is protected by multi-factor authentication, has a high first step and a low second one.
How do you define an impact scale that measures more than money?
You define an impact scale in several dimensions at once and take the score from the highest of them. Financial loss is one dimension, alongside process downtime, leakage of personal data, regulatory consequences and harm to customers.
NIST SP 800-30 Rev. 1, in Table H-3, describes impacts on organisational operations, organisational assets, individuals, other organisations and the Nation. A high level there means, for example, a severe degradation in the ability to perform primary functions or a major financial loss, while a moderate level means a significant reduction in the effectiveness of those functions while they are still performed.
For personal data the perspective is different. Recital 76 of the GDPR requires the likelihood and severity of the risk to the rights and freedoms of the data subject to be determined by reference to the nature, scope, context and purposes of the processing. Impact is measured for the individual, not for the company, so a leak of a thousand health records can be a critical impact even with a small financial loss.
A practical form is a table in which every dimension has its own columns with thresholds and the rows correspond to impact levels. The assessor marks the level in each dimension and takes the highest. This format does not let anyone hide a data leak behind a small amount or a long outage behind the absence of fines.
How do you combine likelihood and impact into a risk level?
You combine likelihood and impact with a written rule: a table, a formula or a set of conditions, not with habit. Multiplying the two scores is the simplest rule, but not the only one and not always the best.
The problem with multiplication comes from the nature of ordinal scales. The numbers 1 to 5 express order, not equal intervals, and a product of 4 comes both from the pair 1 and 4 and from 2 and 2. A very rare event with a serious impact and a frequent event with a moderate impact land in the same cell, although they call for completely different responses.
NIST SP 800-30 Rev. 1 does not prescribe an algorithm for combining semi-quantitative values and points out that combination rules reflect the organisation’s risk tolerance. The example Table I-2 in that document is asymmetric. Very high likelihood with very low impact gives very low risk there, while low likelihood with very high impact gives moderate risk. Impact weighs more than frequency.
That asymmetry is worth recording deliberately. If the company accepts no scenario with a critical impact, the rule can say: every critical impact yields at least high risk, regardless of likelihood. A table lets you write such a rule down explicitly, while a product blurs it.
Key takeaways:
- Every level of a scale needs a definition and a time horizon, otherwise assessors build their own scales.
- Impact is assessed in several dimensions and the highest one counts.
- The rule for combining likelihood and impact must be written down, and a table expresses it better than a product.
How many levels should a scale have?
A scale should have as many levels as assessors can tell apart from the definitions. Five levels create an impression of precision, but if the descriptions of neighbouring levels blur, the score still depends on the assessor’s mood.
NIST SP 800-30 Rev. 1 notes that the range of values in qualitative assessments is usually small, which makes relative prioritisation within a set of risks difficult. As an alternative, the document describes semi-quantitative scales with bins, for example 0–15, 16–35, 36–70, 71–85 and 86–100, which translate easily into words and at the same time allow risks within one bin to be compared.
A four-level scale has one advantage: there is no middle for an undecided assessor to escape into. With several hundred scenarios, for example in a large corporate group, a 0–100 scale with described bins is useful. The same document allows different scales for systems of different importance.
Where should colour thresholds go and who sets them?
Colour thresholds are set by the board or by the person responsible for accepting risk, because they decide how much risk the company takes on without further action. The security team prepares a proposal, but it should not decide alone where the green zone ends.
Regulatory requirements point the same way. As of 19 September 2026. Article 20(1) of the NIS2 Directive requires Member States to ensure that the management bodies of essential and important entities approve cybersecurity risk-management measures and oversee their implementation; in each country the obligation applies through national transposition law. In Poland, that law is the Act on the National Cybersecurity System as amended on 23 January 2026 (Journal of Laws 2026, item 252, in Polish), in force since 3 April 2026. In the financial sector, Article 5(2)(d) of DORA assigns to the management body the setting of an appropriate risk tolerance level for ICT risk. Subcategory GV.RM-02 of NIST CSF 2.0 requires risk appetite and risk tolerance statements to be established, communicated and maintained.
A threshold written into policy should state straight away what happens to a risk in a given zone. A red cell without an assigned decision, deadline and owner is just a colour.
What mistakes break a risk matrix?
What breaks a matrix above all is scoring without definitions, but there are subtler mistakes that pass review because they look like method.
- Scoring assets instead of scenarios. “Mail server: risk 15” does not say what the server needs protecting from. You have to score an event: who, with what, with what impact.
- Mixing inherent and residual risk. If part of the team scores before controls and part after them, the ranking loses its meaning. Both scores should sit side by side in the register.
- Counting controls twice. Multi-factor authentication lowers the likelihood of account takeover, but it should not also lower the impact of the same scenario.
- Escaping to the middle of the scale. When definitions are vague, scores cluster at level 3 and the matrix stops differentiating risks.
- Undated scores. A likelihood score from last year does not reflect new vulnerabilities and infrastructure changes.
Risk researchers also describe the limits of the format itself. Louis Anthony Cox Jr., in the paper “What’s Wrong with Risk Matrices?” (Risk Analysis, 2008), showed that a matrix can assign the same rating to quantitatively very different risks and, in some configurations, rate a smaller risk higher. That is an argument for described scales and a deliberately designed table, not for abandoning the matrix.
When is a risk matrix no longer enough?
A matrix is no longer enough when the board compares investments in money and asks how much risk a specific expenditure will remove. Colours show order, but they do not let you calculate the return on a control.
NIST SP 800-30 Rev. 1 describes quantitative assessments as the ones that best support cost-benefit analyses of alternative risk responses. The same document warns that the benefits of quantitative rigour may be outweighed by the cost of expert time and tools, and that the precision of the numbers is illusory when subjective assumptions are buried inside them.
A sensible setup combines both approaches. The matrix orders the whole register and points to a few scenarios with the highest level, and quantitative analysis is used only where the decision concerns a large budget or a choice between solutions. The wider process framework this fits into is described in the guide to risk management.
How do you build a risk matrix step by step?
You build a matrix starting from definitions, not colours: first the horizon and the scales, then the combination rule, and finally the thresholds and the decisions assigned to each zone. The table below lists the decisions that have to be made and documented.
| Step | Decision to make | Who decides | Evidence in documentation | Mistake to avoid |
|---|---|---|---|---|
| Time horizon | over what period likelihood and impact are assessed | methodology owner | entry in the risk management policy | scoring “ever” |
| Likelihood scale | number of levels, frequency thresholds, descriptions for attacks | security team | table of definitions with examples | levels described in one word |
| Impact scale | dimensions and thresholds in each dimension | process owners and the DPO | table of impact dimensions | only the amount of loss |
| Combination rule | table, formula or minimum conditions | methodology owner | written risk-level table | default product without justification |
| Thresholds and zones | what each risk level means | board | resolution or approved policy | colours without assigned decisions |
| Calibration | whether two people score the same way | assessment team | trial scoring of sample scenarios | launch without a test |
| Review | when to change the scales and when the scores | methodology owner | schedule and review triggers | undated scores |
Calibration is the step that is easy to skip. It is enough for two people to score the same five scenarios independently. A difference of more than one level points to a definition that needs fixing before the matrix reaches the whole organisation.
Key takeaways:
- Build order: horizon, scales, combination rule, thresholds, calibration.
- The board approves thresholds, because they define the risk accepted without action.
- Trial scoring of a few scenarios by two people exposes imprecise definitions.
How can nFlo help you build a risk matrix?
In the “Governance, risk and compliance” area, nFlo builds risk matrices as part of the ISO/IEC 27005 – Information Security Risk Management service: it tailors the likelihood and impact scales to the organisation’s context and sets the risk acceptance thresholds together with the board. The result is a matrix linked to the risk register and the risk treatment plan.
When a company needs an assessment of a whole area, the Risk Assessment Review and Advisory service covers the ISO 27005, NIST RMF and FAIR methodologies, and FAIR is used when the board expects risk to be expressed in money rather than colours. If you want to check whether your matrix gives repeatable results, contact us.
What else is worth knowing about the risk matrix?
Can you multiply likelihood by impact?
You can, but the result can mislead. On an ordinal 1–5 scale the distances between levels are not equal, and a product of 4 comes both from the pair 1 and 4 and from 2 and 2. NIST SP 800-30 Rev. 1 does not prescribe any combination algorithm and gives an example table in which impact weighs more than likelihood.
How many levels should a risk matrix scale have?
As many as assessors can tell apart from the definitions. NIST notes that the narrow range of a qualitative scale makes prioritisation difficult, so with many risks a semi-quantitative scale helps, for example 0–100 with described bins.
What is the difference between inherent and residual risk on a matrix?
Inherent risk is assessed before planned controls are taken into account, residual risk after they are in place. Both scores should sit side by side in the register so that everyone can see how much risk a given control removed.
Do the GDPR or NIS2 require a risk matrix?
As of 19 September 2026. Neither the GDPR nor the NIS2 Directive mentions a risk matrix. The GDPR does, however, require risks of varying likelihood and severity to be taken into account, and NIS2 requires Member States to ensure that management bodies approve cybersecurity risk-management measures; in each country this applies through national transposition law.
How often should you update a risk matrix?
The scales and thresholds change rarely, ideally during a methodology review, while individual risk scores change with every significant change. NIST SP 800-30 describes maintaining an assessment as ongoing monitoring of risk factors such as threats, vulnerabilities and adversary capabilities.
