---
title: "Inherent risk vs residual risk: what each score is for and how to use them"
canonical: https://www.grcmana.io/vault/risk-management/inherent-vs-residual-risk
published: 2026-10-21
updated: 2026-10-23
author: "Harry West"
framework: "Risk Management"
control: "Guide Inherent risk vs residual risk: what each score is for and how to use them"
journeyStage: fundamentals
---

# Inherent risk vs residual risk: what each score is for and how to use them

## Key takeaways

Inherent risk is the exposure before controls; residual risk is what remains once they work. Use inherent scores to decide where to look and which controls to test, and residual scores to decide what to accept, treat further or escalate. ISO 27001 requires risk owners to accept residual risk but, in our reading, no separate inherent score, and a residual score is only as honest as the operating evidence behind it.

- **Residual risk** — The portion of risk remaining after security measures have been applied (NIST glossary). It is the score compared with your acceptance criteria and the figure a risk owner signs to accept.
- **Inherent risk** — The risk to an organisation in the absence of any direct or focused actions by management to alter its severity (NIST, from COSO). It ranks exposure before controls are counted.
- **Residual risk acceptance in ISO 27001** — ISO/IEC 27001:2022 Clause 6.1.3 has risk owners approve the treatment plan and accept residual risks. The method is yours: in our reading, a separate inherent score is not required.
- **Ordinal risk scores** — Likelihood and impact ratings such as 1 to 5 are ordinal labels, not measured quantities. NCSC advises avoiding arithmetic on them, so residual risk is not inherent risk minus a percentage.

An enterprise customer's due-diligence questionnaire asks for an inherent and a residual rating against every risk, and your first ISO 27001 risk register has two score columns nobody can explain. Inherent risk vs residual risk is the distinction behind both.

The verdict: inherent risk is your exposure before controls, and residual risk is what is left once those controls work, so use inherent scores to decide where to look and what to test, and residual scores to decide what to accept, treat further or escalate.

This page is for founders, COOs and security leads at UK B2B tech firms building a first risk register for ISO 27001 or SOC 2, with a worked example on a 5x5 scale.

## Inherent risk vs residual risk: what is the difference?

Inherent risk is the risk to your organisation before any controls act on it. Residual risk is the portion that remains after controls have been applied. Inherent risk measures raw exposure; residual risk measures what you are actually carrying, and residual risk is the figure a risk owner signs to accept.

The NIST glossary defines [residual risk](https://csrc.nist.gov/glossary/term/residual_risk) as the "portion of risk remaining after security measures have been applied". Its definition of [inherent risk](https://csrc.nist.gov/glossary/term/inherent_risk), taken from COSO's enterprise risk management framework, is the risk "in the absence of any direct or focused actions by management to alter its severity".

| Compared on | Inherent risk | Residual risk |
| --- | --- | --- |
| When it is assessed | When the risk is first identified, before any controls are counted | Once controls are in place, and again whenever they or the threat change |
| What it assumes about controls | That none are operating | That the controls you count work, as shown by evidence |
| What decision it drives | Where to look: which risks, suppliers and controls deserve scrutiny and testing | What to sign: accept, treat further or escalate |
| Who uses it | Whoever runs the assessment, plus anyone planning control testing | The risk owner, who approves the treatment plan and accepts what remains |
| What evidence backs it | Reasoning about threat, vulnerability and impact for the unprotected asset | Records that the controls operated: logs, tickets, review sign-offs and test results |
| Where ISO 27001 asks for it | Not required as a separate score, in our reading | Risk owners accept residual risk under Clause 6.1.3 |

## When should you use inherent risk?

Use inherent risk when you need to rank exposure without letting existing controls hide it: prioritising a new register, tiering suppliers, choosing which key controls to test, or answering a questionnaire that asks for it. A high inherent score marks a risk whose controls you cannot afford to get wrong.

- **Prioritising the register.** On a first pass, inherent scores show which risks would hurt most if your controls failed, so those areas get reviewed first.
- **Tiering suppliers.** A supplier that holds customer data carries high inherent risk whatever its certificates say, so it gets the deepest due diligence.
- **Choosing key controls to test.** Where high inherent risk drops to low residual risk, a few controls carry the weight. Test those first.
- **A customer questionnaire.** If a customer's form asks for both ratings, answer from your register's scales so the columns reconcile.

If nobody uses the inherent column for any of these decisions, it is ceremony. Scoring residual risk well beats scoring both badly.

## When should you use residual risk?

Use residual risk whenever someone must decide whether the exposure that remains is acceptable. It is the score you compare with your acceptance criteria and the figure a risk owner signs. It should also move when a control fails, a supplier changes or an incident shows a control was weaker than recorded.

- **The acceptance sign-off.** A risk owner accepts the residual position, never the inherent one. If the residual score sits above your acceptance line, the choice is to treat further or escalate.
- **After a change or incident.** A failed control, a new supplier or a near miss is the trigger to re-score.
- **A customer questionnaire.** If a buyer asks for one rating without saying which, we suggest giving the residual score and saying so: it is your position with controls in place.

On its own, a low residual score hides how much rides on its controls.

When the residual score is too high, choose a treatment: avoid, reduce, transfer or accept. Our [Clause 8.3 risk treatment guide](https://www.grcmana.io/vault/iso-27001/clause-8-3-information-security-risk-treatment) covers carrying it out.

## How do you score inherent and residual risk on a 5x5 scale?

Score the risk twice on the same likelihood and impact scales: once assuming no controls operate, then again counting only the controls you can show working. As a rule of thumb, preventive controls move likelihood. Impact moves only when a control limits the damage, so keep it steady unless one does.

Take one risk: customer data exposed through a cloud storage bucket made public by mistake. The 1 to 5 scales (5 is most likely or most severe), the scores below and the acceptance line of 10 are our illustration, not a requirement. Use your own anchored definitions.

| Stage | Likelihood | Impact | Score (L x I) | What justifies it |
| --- | --- | --- | --- | --- |
| Inherent | 4 | 5 | 20 | Buckets are created often; a public bucket of customer records is a personal data breach, reportable to the ICO if a risk to people is likely |
| Residual, by design | 2 | 5 | 10 | A policy blocks public buckets, and a daily scan flags any exception |
| Residual, on the evidence | 3 | 5 | 15 | Scan logs cover two of the three cloud accounts; the third has no records |

The designed controls would reach the acceptance line; the evidence says they do not yet. At 15 against a line of 10, the risk owner should not sign. Extend the scan to the third account, then re-score once logs exist.

Impact stays at 5 because none of these controls limits the damage once data is exposed.

## Why does "residual risk = inherent risk minus controls" mislead?

The subtraction treats control effectiveness as a number you can deduct, when it is a claim you have to evidence. Ratings on a 5x5 scale are ordinal positions, not measured quantities, and a control described in a policy reduces nothing until records show it operating. Residual risk is a fresh judgement, not arithmetic.

The NCSC's [guidance on cyber security risk quantification](https://www.ncsc.gov.uk/collection/risk-management/introducing-cyber-security-risk-quantification) says likelihood and impact labels are ordinal, and combining them with mathematical operations "should be avoided". Multiplying likelihood by impact to sort risks, as the worked example does, works only if everyone reads the product as a rank. Deducting a "control effectiveness percentage" from it compounds the problem.

The other problem is evidence. The NCSC's [guidance on gaining and maintaining assurance](https://www.ncsc.gov.uk/collection/risk-management/how-to-gain-and-maintain-assurance) describes assurance as "a means of providing confidence that security controls are working in the way you expect", and notes that many assurance activities give only a snapshot in time. A residual score built on design alone records what you hoped would happen.

A residual score is only as honest as the evidence behind the controls it counts.

## Can residual risk be higher than inherent risk?

Yes, in two cases. A control can add risk of its own, such as a security agent with privileged access to every laptop. Or the inherent score was wrong, for example because the assessor quietly counted existing controls. When residual risk exceeds inherent risk, investigate before anyone signs; it is a finding, not a rounding error.

In the first case, record the new risk as its own register entry with its own owner. In the second, re-score the inherent baseline with the controls genuinely set aside.

## What does ISO 27001 require for inherent and residual risk?

ISO/IEC 27001:2022 requires residual risk to be judged and accepted; in our reading, it does not require a separate inherent score. In outline, you set risk acceptance criteria under Clause 6.1.2, risk owners approve the treatment plan and accept the residual risks under Clause 6.1.3, and you keep records of treatment results under Clause 8.3.

The standard leaves the scoring method to you, so scoring both is a method choice, not an audit requirement. Setting the acceptance line is covered in our [Clause 6.1 guide](https://www.grcmana.io/vault/iso-27001/clause-6-1-actions-to-address-risks-and-opportunities). Re-assessing at planned intervals is covered in our [Clause 8.2 guide](https://www.grcmana.io/vault/iso-27001/clause-8-2-information-security-risk-assessment).

[ISO/IEC 27005](https://www.grcmana.io/vault/iso-27005) and [ISO 31000](https://www.grcmana.io/vault/iso-31000) give guidance on the risk process, but neither is a certification standard.

## What carries over between inherent and residual risk?

Almost everything carries over, because both scores belong in one risk register row. The risk statement, owner, scales and impact reasoning are shared. The controls column links the two scores, and the residual score meets the acceptance line. The work of scoring inherent risk tells you which controls to evidence for the residual score.

| Field | Entry |
| --- | --- |
| Risk | Customer data exposed through a cloud storage bucket made public by mistake |
| Risk owner | Head of engineering |
| Inherent score | Likelihood 4, impact 5: 20 |
| Controls relied on | Public-access block policy; daily configuration scan |
| Control evidence | Scan logs for two of three cloud accounts; none for the third |
| Residual score | Likelihood 3, impact 5: 15 |
| Acceptance line | 10 (illustrative) |
| Decision | Treat further: extend the scan to the third account, then re-score |

Read across the row and the acceptance decision follows. The same row answers a questionnaire that asks for both ratings.

## Common mistakes with inherent and residual risk

The common mistakes with inherent and residual risk each make one score meaningless: inherent scores that already count controls, residual scores that drop when a policy is approved rather than when evidence appears, and acceptance signed by whoever runs the control. Each is cheap to fix.

- **Counting controls in the inherent score.** The columns then agree and stop pointing at the controls that matter.
- **Lowering residual risk on approval, not evidence.** A signed policy is design. Re-score when records show the control operating.
- **The wrong person accepting.** Acceptance belongs to the risk owner named in the register, not the engineer who runs the control.

A residual score nobody has re-checked since the audit is a historical record, not a risk position.

## Frequently asked questions

### What is residual risk?

Residual risk is the risk that remains after controls or other treatments have been applied. NIST's risk management guidance (NISTIR 8286) adds a condition worth keeping: the responses must have been documented and performed, not just planned.

### Do you have to score inherent risk?

Not for ISO 27001, in our reading: it asks for residual risk to be accepted and leaves the scoring method to you. If you skip the inherent column, record which controls each residual score relies on, so a failure in any of them triggers a re-score.

### Who should accept residual risk?

The risk owner: the person accountable for that risk and with the authority to act on it. We recommend someone senior enough to fund further treatment, because accepting a risk you could not afford to treat is not a real choice.

### How often should you re-score residual risk?

Re-score at the planned intervals your method sets, and when a significant change is proposed or happens; ISO 27001 Clause 8.2 asks the same of risk assessments. Re-scoring before a change lands catches a control it will weaken. We suggest a quarterly check on your highest residual risks; that cadence is our guidance, not a requirement.