Risk matrix: definition, example and method
Scales, criticality scoring, acceptance thresholds and a complete cyber example, with a free spreadsheet template.
A risk matrix is a two-way grid that combines the likelihood of a risk with its severity to give a criticality level, usually shown in colours. It is used to rank risks and decide which ones to treat first. Here is how to build its scales, calculate criticality, set acceptance thresholds and apply it to a complete cybersecurity example, with a template to download.
What is a risk matrix?
The risk matrix is the most widely used visualisation tool in risk management. It goes by several names: criticality matrix, probability impact matrix, likelihood severity matrix or heat map. The principle is always the same: one axis measures how likely a feared event is, the other measures how severe its consequences would be, and each cell of the grid corresponds to a risk level.
This logic comes straight from the definition of risk used in the standards. In ISO 31000 as in ISO/IEC 27005, the level of a risk is expressed as the combination of its consequences and their likelihood. The matrix simply makes that combination readable at a glance, for a board as well as for a technical team.
What is a risk matrix for?
- Prioritising: comparing very different risks (ransomware, outage, data leak) on the same grid.
- Deciding: linking each colour zone to a decision (accept, monitor, treat, treat urgently).
- Communicating: presenting the organisation's exposure to management without technical detail.
- Tracking: showing how a risk moves across the grid once security measures are in place (initial risk, then residual risk).
Do not confuse the matrix with the process that feeds it. The matrix is a scoring and reporting tool; risk mapping is the full process that identifies, assesses and prioritises the risks of a scope; the risk register is the detailed list that documents them. All three go together, and the matrix comes at the end, after a proper risk analysis.
Building the likelihood and severity scales
A risk matrix is only as good as its scales. If “serious” does not mean the same thing to the IT director and to the CFO, two people will put the same risk in two different cells. Each level must therefore be described by an observable criterion: length of interruption, number of people affected, financial impact, legal consequences or reputational damage.
The severity scale
Severity measures the extent of the consequences if the risk materialises. The ANSSI EBIOS Risk Manager guide proposes four levels, from G1 “Minor” to G4 “Critical”, ranging from no lasting operational impact to a situation where the organisation's survival is at stake. Here is a version suited to a small or mid-sized company; read it alongside the availability, integrity, confidentiality and traceability needs of the assets concerned.
| Level | Label | Indicative criterion |
|---|---|---|
| 1 | Minor | Occasional nuisance, easy workaround, no notable customer or financial impact. |
| 2 | Significant | Business degraded for a few hours, limited costs, internal incident with no public exposure. |
| 3 | Serious | Partial shutdown for several days, personal data breach to notify, significant financial loss. |
| 4 | Critical | Prolonged shutdown, people put at risk or the organisation's survival at stake. |
The likelihood scale
Likelihood (or probability) estimates the chance that the scenario occurs over a given period, often one year. In cybersecurity, historical frequencies are rarely reliable: the reasoning is based instead on the attacker's motivation and resources, the asset's exposure and the measures already in place. That is the approach of the ANSSI method sheet on assessing likelihood, which uses a scale from V1 “Unlikely” to V4 “Almost certain”.
| Level | Label | Indicative criterion |
|---|---|---|
| 1 | Unlikely | Scenario requiring significant resources, never observed in the sector. |
| 2 | Likely | Scenario already observed in the sector, asset little exposed or well protected. |
| 3 | Very likely | Common scenario in comparable organisations, partial protection. |
| 4 | Almost certain | Scenario already experienced or expected shortly, asset exposed on the internet. |
3x3, 4x4 or 5x5 matrix: which size to choose?
The number of levels sets how fine-grained the matrix is. The more levels, the better you can tell similar risks apart, but the more precision you ask of assessors. Compare the three most common formats:
3 x 3: the starter matrix
+Quick to explain and fill in during a workshop, ideal for a first risk map or a small organisation.
−Not very discriminating: many risks land in the same cell, and the centre cell becomes a catch-all.
4 x 4: the choice of cyber methods
+An even number of levels, so there is no safe “middle” cell. It is the format of the scales proposed by EBIOS RM.
−Needs written criteria for each level, otherwise two assessors will not put the same risk in the same place.
5 x 5: the fine-grained matrix
+More nuance, useful for a large portfolio of risks or consolidated enterprise risk management.
−False precision: the gap between two neighbouring levels is rarely defensible, and level 3 attracts cautious answers.
In cybersecurity, the 4 x 4 has become the norm. Its even number of levels forces a choice between “rather low” and “rather high”, and it matches the EBIOS RM scales, which makes consolidation with an EBIOS Risk Manager analysis easier. The 5 x 5 remains relevant for enterprise risk management that aggregates financial, operational and cyber risks.
Calculating criticality and setting acceptance thresholds
Criticality is the score that sums up a risk's position in the matrix. The most common rule is a simple product:
Criticality = Likelihood x Severity
On a 4 x 4 matrix, the score therefore ranges from 1 to 16. Ransomware rated very likely (3) and critical (4) scores 12; defacement of the corporate website, likely (2) and minor (1), scores 2. Some organisations prefer a lookup table to the product, so that severity weighs more: a risk of maximum severity should never end up green, even if it is unlikely.
Thresholds that trigger decisions
The score only matters if it leads to a decision. Acceptance thresholds express the organisation's risk appetite: they are set and approved by management before the assessment, not adjusted afterwards to turn a risk green. ISO/IEC 27005 asks for these risk acceptance criteria to be established upfront, along with the criteria for performing risk assessments.
| Criticality | Level | Expected decision |
|---|---|---|
| 1 to 3 | Low | Risk accepted, reviewed at the next analysis. |
| 4 to 6 | Moderate | Accepted under monitoring, or treated if the cost of measures is reasonable. |
| 8 to 9 | High | Treatment plan required, with an owner and a due date. |
| 12 to 16 | Critical | Priority treatment, decided and monitored by management. |
We add a simple adjustment rule: any risk of severity 4 is rated at least “High”. Without it, a scenario that could shut the company down but is deemed unlikely (4 x 1 = 4) would fall into the same category as a daily nuisance. Once the level is known, the treatment option remains to be chosen: reduce the risk with measures, transfer it (insurance, contract), avoid it by giving up the activity, or accept it and document it.
A cybersecurity risk matrix example
Take a 400-employee industrial company with an ERP hosted by a provider, cloud email, a SaaS CRM and a fleet of laptops. The assessment workshop, which brings together the CISO, the IT director, finance and a business representative, selects six risks. Here they are on the matrix: select a risk, then click another cell to see its criticality and level change.
Place the risks, the matrix works out criticality
Pick a risk from the list, then click a cell of the matrix to move it.
Adjustment rule: any severity of 4 is rated at least “High”.
The resulting ranking is as follows. Ransomware (R1, 12) is critical: it targets the file servers and online backups whose loss would halt production. The ERP outage (R4, 8) and payment fraud after phishing (R2, 9) are high and require a treatment plan. The data leak at the SaaS provider (R3, 6) and the theft of an unencrypted laptop (R5, 6) are moderate. The website defacement (R6, 2) is accepted, with a restore procedure.
Each line of the register then specifies the treatment, its owner and its due date. For R1: offline backups tested every quarter, detection on servers and network segmentation, owned by the IT director. For R3, treatment goes through the contract and third-party risk assessment; for R4, through a tested business continuity plan.
The file opens directly in Excel, LibreOffice or Google Sheets (semicolon separator, UTF-8 encoding). To go further, replace the criticality column with a formula (likelihood multiplied by severity) and add four-colour conditional formatting.
The limitations of the risk matrix
The matrix is simple, which is both its strength and its weakness. In a landmark paper, “What's Wrong with Risk Matrices?” (Risk Analysis, 2008), researcher Louis Anthony Cox showed that a matrix can give the same rating to quantitatively very different risks, and even rank a smaller risk above a larger one. He concludes that it should be used with caution, making the underlying judgements explicit. The IEC 31010 standard, which catalogues risk assessment techniques, presents the consequence-likelihood matrix as one technique among others, to be chosen according to the need.
- 01
Same score, opposite risks
An unlikely total loss of the information system and a harmless daily nuisance both score 4. Multiplication erases the difference.
- 02
The threshold effect
Going from 6 to 8 changes the colour, and therefore the decision, even though the gap is often smaller than the workshop's margin of error.
- 03
The safe middle cell
Without written criteria, hesitant assessors pick the middle. Risks pile up in the centre and the matrix no longer ranks anything.
How to limit bias
- Write down the criteria for each level and read them again at the start of the workshop.
- Assess as a group, each person alone first, then compare the gaps: they reveal the implicit assumptions.
- Keep severity visible next to the score, and never leave a maximum-severity risk in green.
- Justify each rating in one sentence in the register, so that the next review starts from reasoning rather than a number.
- Add scenarios: for high risks, describing the attack path helps choose the right measures, which the matrix alone does not tell you.
Risk matrix, ISO 27005 and EBIOS RM
The matrix is not a method in itself: it is a tool that risk analysis methods use at the evaluation stage. ISO/IEC 27005, whose fourth edition was published in October 2022, frames information security risk management: it requires defining assessment and acceptance criteria, identifying risks, analysing them, evaluating them and then treating them, without imposing any particular matrix format.
ANSSI's EBIOS Risk Manager method, updated to version 1.5 in 2024 and now aligned with ISO/IEC 27005:2022, goes further in the process. Its risk scenarios are positioned by severity and likelihood on a grid, a radar or a Farmer diagram, which the guide calls the risk map, before and after treatment. The matrix is therefore the end point of scenario-based reasoning, not a starting point. To see the method supported in a tool, visit our risk analysis module.
The same logic applies to data protection: the CNIL PIA method calls for a visual map of risks by severity and likelihood as part of a data protection impact assessment (DPIA).
From an Excel risk matrix to a risk management tool
A spreadsheet is enough for a first risk matrix: a few dozen rows, a formula, conditional formatting. The difficulties appear over time. Several versions of the file circulate, business teams do not contribute directly, action plans are tracked elsewhere and nobody remembers why a given risk went from orange to yellow last year.
A few signs show it is time to change tools:
- you run several analyses (projects, subsidiaries, sites) that need to be consolidated;
- your risks must be linked to compliance requirements (ISO 27001, NIS 2, DORA);
- the measures decided must be tracked with their owners and due dates;
- an auditor or regulator asks for the history of your assessments.
That is what the Phinasoft Risk & Compliance module offers: run your analyses with the EBIOS RM method, through a module certified by ANSSI, with ISO 27005 or with your own approach, integrating your scales and your risk and measure libraries. Action plans are tracked with reminders, risk levels can be updated as measures are implemented, and each scope can be reassessed starting from the previous version. You can request a demo using your own scales.
Summary
A prioritisation tool
A risk matrix combines likelihood and severity to rank risks and decide which ones to treat first. It does not replace the analysis, it summarises its outcome.
Write the scales first
A matrix is only as good as its criteria: each level of severity and likelihood must be described, and acceptance thresholds approved by management before the assessment.
A format that must live
A spreadsheet is enough to start. When risks number in the dozens and action plans need tracking, a tool avoids competing versions and keeps the history.
Frequently asked questions
How do you build a risk matrix?
First define a severity scale and a likelihood scale, with a written criterion for each level. Then list the risks, rate each one on both scales, place it on the grid, work out its criticality and compare it with the acceptance thresholds set by management. Finish with a treatment decision, an owner and a due date for each risk.
How do you calculate risk criticality?
The most common method multiplies the likelihood level by the severity level: on a 4 x 4 matrix, criticality ranges from 1 to 16. Some organisations use a lookup table rather than a product, to give more weight to severity. Either way, the rule must be written down and applied in the same way to every risk.
What is the difference between a risk matrix and a risk map?
The risk matrix is the scoring tool: a grid that combines likelihood and severity. Risk mapping is the wider process that identifies, assesses and prioritises all the risks of a scope, then displays them, often on a matrix. The matrix is therefore one of the outputs of risk mapping.
Should you use a 3x3, 4x4 or 5x5 matrix?
A 3 x 3 suits a first approach or a small organisation. The 4 x 4 is the most common format in cybersecurity: its even number of levels avoids a safe middle cell, and it matches the scales proposed by EBIOS RM. A 5 x 5 adds useful nuance for a large risk portfolio, at the cost of sometimes illusory precision.
How do you build a risk matrix in Excel?
Create a table with one row per risk and columns for the asset concerned, likelihood, severity, criticality calculated by formula, treatment, owner and due date. Add conditional formatting on criticality to colour the levels. The CSV template offered in this article already contains these columns, six examples and the scale key.
What is an acceptable risk?
An acceptable risk is one whose level falls below the acceptance threshold set by the organisation. That threshold is a management decision, made before the assessment, not the result of a calculation. An accepted risk must remain visible: it is documented, justified and reviewed regularly, because context and threats change.
What are the risk treatment options?
There are usually four options: reduce the risk by putting security measures in place, transfer or share it, for example through insurance or a contract, avoid it by giving up the activity that creates it, or accept it knowingly. ISO/IEC 27005 describes these options and requires the chosen option to be justified.
Sources (8)
- ANSSI — EBIOS Risk Manager guide, version 1.5 (2024, in French)
- ANSSI — ANSSI updates the EBIOS Risk Manager method (26 March 2024)
- ANSSI — Method sheet: assessing the likelihood of operational scenarios (workshop 4)
- ISO — ISO/IEC 27005:2022, Guidance on managing information security risks
- ISO — ISO 31000:2018, Risk management — Guidelines
- ISO — IEC 31010:2019, Risk management — Risk assessment techniques
- L. A. Cox Jr. — What's Wrong with Risk Matrices?, Risk Analysis, vol. 28, n° 2, 2008
- CNIL — Privacy impact assessment: the method (in French)
A platform and service that adapt to you
Our platform is designed for fine-tuned configuration and broad adaptability to your needs.