A risk register that only shows one score per risk hides the most important question an auditor, a board or a CISO will ask: how much did our controls actually help, and is what's left acceptable? Answering it needs two numbers: inherent risk and residual risk.
Inherent risk: before controls
Inherent risk is the risk a threat poses with no controls in place. It reflects the nature of the asset and the threat: a public login page will always attract credential stuffing; a database of health records will always be valuable to criminals.
In practice, "no controls" is hard to imagine for a running system. Many teams use a practical version: the risk with only the baseline every system has (a framework, TLS, a firewall), before the specific mitigations being discussed. Whichever you choose, use the same definition for every entry.
Residual risk: after controls
Residual risk is what remains after controls are applied, assuming they work as designed. It is never zero: controls fail, attackers adapt, and some threats can only be made less likely, not impossible.
The simplest way to calculate it is to re-score the threat on the same scales:
Residual risk = Likelihoodafter controls × Impactafter controls
Re-scoring both factors is clearer than subtracting a "control effectiveness" percentage, and easier to justify to an auditor: you can say exactly why each factor changed.
Risk appetite: how much residual risk is acceptable
Residual risk only means something when compared with the organisation's risk appetite, the level of risk leadership is willing to carry in pursuit of its goals. On a 5×5 risk matrix this is often a simple threshold: residual scores of 9 or below may be accepted by the system owner; 10–15 need a director; anything higher must be reduced further.
Residual risk above appetite has three possible outcomes: add more controls, change the design to avoid the risk, or have someone with enough authority explicitly accept it, with a review date.
Worked example: Invoicely
Three threats from the Invoicely risk register, scored before and after their planned controls:
| Threat | Inherent (L×I) | Controls | Residual (L×I) |
|---|---|---|---|
| T2 IDOR on invoice endpoints | 4×5 = 20 | Ownership check in the data access layer; cross-tenant tests | 1×5 = 5 |
| T1 Credential stuffing | 4×4 = 16 | Rate limiting, breached-password check, optional MFA | 2×4 = 8 |
| T5 Admin console shared DB role | 3×5 = 15 | Separate read-mostly role; audit log with alerts | 2×3 = 6 |
Note the pattern. For T2 and T1, the controls only lower likelihood: a successful attack would be just as damaging, so impact stays the same. Only for T5 does the impact fall, because a separate role limits what a compromised console could reach. Controls that reduce impact (least privilege, segmentation, encryption) are rarer and often more valuable.
What auditors look for
Most risk-based standards require residual risk to be identified and accepted:
- ISO/IEC 27001:2022, clause 6.1.3, requires the organisation to obtain risk owners' approval of the risk treatment plan and their acceptance of the residual risks.
- SOC 2 criteria on risk assessment (CC3) expect risks to be analysed and responses chosen, which in practice means showing scores before and after mitigation.
- NIS2 Article 21 requires measures that are appropriate and proportionate to the risk, which is hard to show without both numbers.
The evidence is the same in each case: a register with both scores, the controls that explain the difference, the name of the person who accepted the residual risk, and when they'll look at it again.
Common mistakes
- Scoring residual risk with planned controls as if they were built. Record planned and implemented controls separately, or the register shows risk you don't actually have.
- Reducing impact for controls that only affect likelihood. MFA makes account takeover less likely; it doesn't make a takeover less damaging.
- Residual risk accepted by the security team. Security can recommend; the business owner of the system has to accept.
- Acceptance without expiry. Threats and systems change. An acceptance needs a review date.
Key takeaways
- Inherent risk is the risk with no controls; residual risk is what's left after the controls you have or plan.
- Score both with the same likelihood × impact scale, so the difference shows how much each control is worth.
- Residual risk is never zero. It must be compared with the organisation's risk appetite and accepted by a named owner.
- Most controls reduce likelihood, not impact. If the impact stays catastrophic, the residual risk may still be too high.
Frequently asked questions
What is the difference between inherent and residual risk?
Inherent risk is the risk before controls; residual risk is the risk remaining after controls. For example, credential stuffing against a login page with no protection might score 16; with rate limiting, breached-password checks and MFA, the residual risk might be 6.
How do you calculate residual risk?
Score the threat again on the same likelihood and impact scales, assuming the controls are in place and working. Some teams express it as inherent risk minus the effect of controls, but re-scoring both factors is simpler and easier to defend.
Who accepts residual risk?
A risk owner with the authority to accept that level of risk, usually a business or product leader rather than the security team. ISO/IEC 27001 requires risk owners to approve the risk treatment plan and accept the residual risks.
Can residual risk be higher than inherent risk?
Not in a correct assessment, since controls only reduce risk. In practice it happens when a control introduces a new risk, such as a security agent with its own vulnerabilities. That new risk should be recorded as a separate entry.