Most risk registers score every risk on likelihood and impact, usually from one to five. Most of those scores could not be reproduced by anyone other than the person who wrote them. Ask two engineers to rate the same risk and you get different numbers, and neither can explain the gap.
That is the problem scoring has to solve. A score is only useful if it means the same thing each time it is applied, so that risks can be compared and the highest ones handled first. Auditors test exactly that property.
This article covers how to define the two scales, how to combine them, the difference between current and residual ratings, and the scoring habits that produce numbers nobody trusts. If you have not built the register itself yet, start with what a register needs to hold.
What the standards require of a score
The standards are specific about the properties of a score and silent about its form.
ISO/IEC 27001:2022 clause 6.1.2 requires you to establish criteria for performing risk assessments, and to make sure repeated assessments produce consistent, valid and comparable results. Clause 6.1.2 d) requires you to assess the potential consequences and the realistic likelihood of each risk, and determine its level. Nothing in the standard requires a five-point scale, a matrix, or numbers at all.
NIST SP 800-30 Rev. 1, the federal guide to conducting risk assessments, treats risk as a function of likelihood and impact. It describes qualitative, semi-quantitative and quantitative approaches, and its example scales use five levels running from very low to very high. It also splits likelihood into two parts: how likely a threat event is to occur, and how likely it is to cause harm if it does.
That split is worth borrowing even if you never use the rest. A phishing email arriving is near certain. A phishing email leading to a compromised production credential depends on MFA, privilege and detection. Scoring the second question is what makes controls show up in the rating.
Define likelihood in words someone else can apply
A likelihood scale fails when its levels are adjectives. "Possible" and "likely" mean different things to different people. Each level needs a description specific enough to settle an argument.
There are two common ways to anchor likelihood:
By expected frequency. For example, "expected to occur more than once a year" at the top and "not expected in the foreseeable future" at the bottom. This works well for events that recur, such as phishing, outages or lost devices.
By conditions. For example, "exploitable by an unauthenticated outsider with public tools" at the top and "requires insider access plus the failure of several independent controls" at the bottom. This works better for events with no useful history, such as a targeted intrusion.
Pick one approach per scale, or write both into each level and say which takes priority. Either way, rate the likelihood with the controls that exist today, not the ones planned. The word "realistic" in clause 6.1.2 d) is a quiet instruction not to inflate likelihood to win budget.
Define impact across the things you care about
Impact is easier to agree on when each level describes concrete effects across a few dimensions. The highest dimension sets the level. Here is an illustrative five-level scale for a hypothetical SaaS company:
| Level | Customer data | Service availability | Regulatory and contractual |
|---|---|---|---|
| 5 Severe | Exposure of sensitive data across many customers | Platform unavailable for days | Notifiable breach in several jurisdictions, contract terminations |
| 4 Major | Exposure of sensitive data for one or a few customers | Platform unavailable for most of a day | Notifiable breach, formal customer escalation |
| 3 Moderate | Exposure of internal or limited customer data | Degraded service for hours | SLA credits, customer audit request |
| 2 Minor | Exposure contained before any customer data left | Brief degradation most customers do not notice | Internal policy breach only |
| 1 Negligible | No data affected | No customer-visible effect | None |
Tune the descriptions to your business. If you set financial thresholds, set them relative to your own revenue and write them down, so the scale does not shift when someone new joins. Avoid a dimension you cannot assess. A "reputation" column with no description beyond "bad press" invites guesswork.
Combine the two without false precision
Most teams multiply likelihood by impact. That is convenient, and it hides a problem. The numbers on an ordinal scale are labels for ordered categories. They are not measurements, so arithmetic on them carries less meaning than it appears to.
The practical effect shows up at the extremes. A rare but severe event (one times five) and a frequent but trivial one (five times one) both score five. Most organizations would not treat those two risks the same way.
A lookup matrix avoids this. You decide, cell by cell, what level of risk each combination represents, and you can weight impact more heavily where your organization cares more about severity than frequency. NIST SP 800-30 Rev. 1 takes this approach in its example tables, combining qualitative likelihood and impact into a risk level through a lookup rather than a formula.
If you keep multiplication, at least review the cells where it produces results you disagree with, and override them in the method document. Either way, map each resulting level to a decision rule. A rating means little until it says what happens next: which levels can be accepted, which require treatment, and who has to sign.
Current, inherent and residual ratings
Teams argue about inherent risk more than it deserves.
Inherent risk is the rating before any controls. It is hypothetical, and it is hard to rate honestly, because nobody runs a system with no controls.
Current risk is the rating with the controls that exist today. It is the rating that reflects the realistic likelihood the standard asks for.
Residual or target risk is the expected rating once planned treatment is complete.
You do not need all three. Current and target are usually enough, and they make the effect of treatment visible: if the target rating is no lower than the current one, the treatment plan is not doing anything. Many methods also keep inherent ratings to show the value of existing controls. That is a reasonable choice, provided the scale is applied the same way.
Calibrating scores across a team
A method written well can still be applied badly. A few habits keep scores consistent.
Score in pairs or small groups. The risk owner and someone from security rate together. Disagreements expose vague scale wording, which you fix in the method.
Keep anchor risks. Pick a handful of well-understood risks and agree their ratings. New risks are compared against them: "is this more or less likely than the anchor?"
Write the rationale. One sentence per rating, naming the evidence or control that drove it. It lets an auditor re-perform the score and lets you compare this year with last year.
Look at the distribution. If nearly everything lands in the middle cell, the scales are not discriminating. If nearly everything is high, nothing is prioritized.
How auditors test a score
An auditor will usually pick a sample of risks, read the method, and ask the owner to explain the rating. They want to see three things: that the scale definitions cover the case, that the rating follows from them, and that the resulting level triggered the decision your method says it should.
They rarely challenge whether a risk is a four or a five. They do challenge a rating nobody can explain, a risk rated low with no controls linked, or a high rating that sat untreated with no acceptance. Those are failures of method, not judgment, and they are the ones that become findings.
Quantitative methods, such as FAIR, express likelihood and impact as ranges of frequency and loss. They answer different questions and need data most small teams do not have. None of ISO 27001, the risk assessment control in NIST SP 800-53, or SOC 2 requires a quantitative method. A qualitative one applied consistently is the common choice.
How TrustLynce helps
TrustLynce's risk management module stores your likelihood and impact scales with the method, applies the same matrix to every risk, and records the rationale and date for each rating. Current and target ratings sit side by side, so the effect of each treatment plan is visible at review.