Risk matrix: how to score information security risk on likelihood and impact

The enterprise security questionnaire asks you to "describe how you assess and score information security risk". Or the ISO 27001 auditor asks why two people scored the same risk differently. Either way, the answer usually lives in a risk matrix, and a risk matrix copied from a health-and-safety template will not hold up.

A risk matrix scores each risk by likelihood and impact so you can rank risks and decide which to treat. For information security, the value is in the scale definitions, not the grid. Define each level in your own business terms, and set the score at which a risk stops being acceptable.

This guide is for founders, CTOs and security leads at UK firms of 25 to 250 people building their first risk method. It covers how the grid works, how to write scales an auditor will accept, how to score, where to draw the acceptance line and when to move beyond the matrix.

What is a risk matrix and how does it work?

A risk matrix is a grid with likelihood on one axis and impact on the other. Each risk sits in the cell where its two ratings meet, and each cell carries a risk level, usually shown as a colour band from green to red. The grid turns two separate judgements into one rating you can sort, compare and act on.

The axes are the inputs. Likelihood is how often you expect the event within a set period. Impact is what it would cost the business if it happened. The cells are the outputs: a rating such as low, medium, high or critical.

The colour bands are a communication device. Green tells a reader nothing needs to change; red tells them someone has to act. That simplicity is why the matrix is everywhere, and also why it is easy to misuse. For how the matrix fits the wider discipline, start with our risk management overview.

Should you use a 3x3 or a 5x5 risk matrix?

A 3x3 risk matrix uses three levels on each axis and suits a first assessment or a very small team. A 5x5 matrix uses five levels and suits most firms of 25 to 250 people, because it separates risks that a 3x3 lumps together. Pick one size and use it for every risk.

A 3x3 grid is quick to explain. Its weakness is that most risks land in the middle cell, so the ranking tells you little. The NCSC's basic risk assessment method uses simple 3x3 matrices on a Low to High scale for threat, vulnerability and risk, and presents the method as a starting point for organisations just beginning to manage cyber security risk.

A 5x5 grid gives you 25 cells instead of 9. That extra room lets you tell a likely, moderate risk apart from a rare, severe one, which is the distinction that drives treatment decisions.

We recommend a 5x5 grid for most firms in this size range. Keep a 3x3 only for a first pass, and move to 5x5 before an enterprise customer or a regulator reads your method.

How do you define likelihood and impact for information security risk?

Define likelihood as a frequency range over a fixed period, and impact as bands of money, downtime, data and customer harm. Write each level so two people reading it would place the same risk in the same cell. The labels matter far less than the definitions behind them.

The NCSC warns that matrices "can lead to errors and miscommunication of risk if not used carefully", and asks you to "carefully communicate the meaning of your scales and any labels used". NIST SP 800-30 makes the same point: unless each level is clearly defined, different experts can produce significantly different results.

A scale nobody can read the same way twice is not a scale.

What does a likelihood scale look like?

A good likelihood scale ties each level to how often the event is expected over a set period. NIST SP 800-30 does this for accidents, errors and natural events, anchoring its levels to frequencies from less than once every 10 years to more than 100 times a year. The example below adapts that approach for a smaller firm.

These bands are our illustration, not a requirement. Calibrate them against your own incident history and what peers in your sector report.

What does an impact scale look like for information security?

An information security impact scale needs more than one column, because a breach can cost money, stop a service, expose data and damage customer trust at once. Score each risk on every column and take the highest level reached. That stops a severe data impact being diluted by a low financial one.

The example below is written for an illustrative UK B2B tech firm turning over around £10 million. Scale the money and downtime bands to your own revenue and service commitments.

Notice what is missing: words like "negligible" or "catastrophic" with nothing behind them. Those are health-and-safety severity labels. They describe injuries, not lost deals or ICO reports.

Should you multiply likelihood by impact or use a lookup table?

Use a lookup table that maps each likelihood and impact pair to a risk level you have chosen on purpose. Multiplying the two numbers is common, but it treats rankings as measurements. The NCSC's guidance on risk quantification says that combining ordinal labels with mathematical operations "should be avoided", because they "don't measure the quantity of something".

A rating of 4 is not twice a rating of 2. It is just higher in the order. When you multiply, a rare but severe risk (1 x 5 = 5) and a frequent but trivial one (5 x 1 = 5) get the same score, even though they call for different responses.

A lookup table avoids this. You decide, cell by cell, what each combination means. NIST SP 800-30 takes this route: its level-of-risk table combines likelihood and impact through a lookup, not a sum. The table below is our illustration for a 5x5 grid, with likelihood in rows and impact in columns.

Here a rare but severe risk lands in High, not Low, because the firm has decided it cannot shrug off a severe outcome however unlikely. That is a design choice you can explain to an auditor. A product of two numbers is not.

If your method already multiplies, you do not have to start again. Treat the product as a sort key, define the bands with a lookup, and record the reasoning.

Where should you set the risk acceptance threshold?

Set the risk acceptance threshold as a named level on the grid, such as "Medium or below may be accepted by the risk owner", and decide it before you score anything. The threshold should follow from your risk appetite, not from where this year's risks happen to fall.

ISO/IEC 27001:2022 Clause 6.1.2 expects you to set risk criteria, including risk acceptance criteria, in advance. It also expects repeated assessments to produce consistent, valid and comparable results. Our guide to ISO 27001 Clause 6.1 covers what the clause asks for and what auditors test.

The matrix is where those criteria become visible. A practical pattern for a firm of this size is:

1. Low: accepted and monitored by the risk owner.
2. Medium: may be accepted by the risk owner, with a recorded reason and a review date.
3. High: treated, or accepted only by a named director.
4. Critical: treated now, and reported to the board.

Where the line sits is a business decision. A firm that sells to banks may draw it lower than one selling to start-ups. Our guide to risk appetite shows how to set that position and turn it into acceptance criteria.

An acceptance line drawn after the scoring is a description, not a decision.

How do you use a risk matrix for inherent and residual risk?

Score each risk twice on the same risk matrix: once before controls (inherent risk) and once counting only the controls you can show working (residual risk). Compare the residual score with your acceptance threshold. Using one grid for both keeps the two scores comparable, so the gap between them shows what your controls achieve.

Keep the scales identical between the two scores. If impact bands shift between them, the movement is meaningless. Most preventive controls lower likelihood; impact usually changes only when a control limits the damage.

Our guide to inherent and residual risk covers what each score is for and how to justify the movement between them. Both scores then sit in your risk register, next to the owner and the treatment.

How do you report a risk matrix to the board?

Report the risk matrix to the board as a heat map: the same grid, with each risk plotted as a numbered dot. Show residual positions, and mark which risks moved since the last report. A board reads movement and outliers faster than it reads a list of fifty rows.

Keep three things on the page: the heat map, the few risks above the acceptance line with their owners, and what changed. The NCSC asks you to communicate risk in a meaningful way and to convey the uncertainty in your assessment. A short note on how confident you are in each top risk does that.

What are the most common risk matrix mistakes?

The most common risk matrix mistakes are borrowed severity labels, scales with no anchors, a grid where everything lands amber, and scoring once a year. Each one makes the matrix look complete while the ratings stop meaning anything. All four are easy to fix once you can see them.

• Health-and-safety severity labels. Words like "minor injury" or "fatality" do not describe a breach of customer data. Rewrite impact in money, downtime, data and customer terms.
• Unanchored scales. "High likelihood" with no frequency behind it lets every scorer use their own meaning. Anchor every level to a frequency or a band, as in the scales above.
• Everything lands amber. When most risks score medium, the matrix is not ranking anything. Usually the scales are too vague, or scorers avoid the extremes. Tighten the definitions and re-score.
• Scoring once a year. A risk scored in January can be wrong by March after a new supplier, product or threat. ISO 27001 expects assessments at planned intervals and when significant changes occur, so re-score when something changes.

Amber is where decisions go to wait.

When should you move from a risk matrix to quantification?

Move from a risk matrix to quantification when ratings stop separating the decisions you need to make. Typical triggers are two "high" risks competing for one budget, a board asking how much risk you carry in pounds, or a control that costs more than the risk it reduces. You can do this one risk at a time.

The NCSC observes that "it's hard to compare two risks both rated as 'high' or 5/5 and decide which one needs addressing first". Quantification expresses likelihood as a frequency and impact as money, hours of downtime or devices affected, with the uncertainty stated as a range.

You do not have to throw the matrix away. The NCSC says quantification can be introduced alongside an existing approach, and that quantitative standards such as FAIR are compatible with ISO 27005. Our entry on the Factor Analysis of Information Risk (FAIR) explains the method.

A well-anchored matrix is also the best preparation. If your likelihood levels are already frequencies and your impact levels are already pounds and hours, the step to ranges is short.

Frequently asked questions