Inherent risk and residual risk: definitions and calculation

Residual risk is the risk that remains once security controls are applied; inherent risk is the risk you would face with no controls at all. Comparing the two shows what your controls really achieve, and it is residual risk, not inherent risk, that management must knowingly accept.

Inherent risk, also called gross risk, is the risk level of a scenario before the organisation takes any action to reduce it. The glossary of NIST, the US National Institute of Standards and Technology, uses the definition from the COSO enterprise risk management framework: the risk to an entity in the absence of any direct or focused action by management to alter its severity.

In practice, you ask: “if we had nothing in place, what would happen and how likely is it?”. For an accounting firm that keeps its clients' files on a file server, the scenario “ransomware encrypts the server and its backups at the height of tax season” has maximum severity and, without specific protection, very high likelihood. On scales from 1 to 4, it scores 4 x 4 = 16.

Rating inherent risk may seem theoretical, since no organisation starts from scratch. It is still useful for two reasons: it highlights the scenarios that would be catastrophic if a control failed, and it lets you measure what each control contributes. A high inherent risk brought down to a low residual risk points to a critical control that needs close monitoring.

Residual risk is defined by ISO Guide 73:2009, long the reference risk management vocabulary (since replaced by ISO 31073:2022), and by the 2018 edition of ISO/IEC 27000, the information security vocabulary, as the risk remaining after risk treatment. Both add two notes: residual risk can contain unidentified risk, and it can also be known as “retained risk”. NIST describes it as the portion of risk remaining after security measures have been applied.

Three points follow. First, residual risk is never zero: no control removes a threat entirely, short of giving up the activity. Second, it depends on controls that are actually in place and effective, not those in next year's budget. Third, it includes an unknown part, which is why the analysis must be reviewed regularly.

There is no official formula: neither ISO 27005 nor EBIOS Risk Manager imposes a scale. The most common approach, and the easiest to defend in front of an auditor, is to re-rate the scenario taking controls into account. It takes four steps.

• Rate the inherent risk. Estimate the severity of consequences and the likelihood of the scenario without controls, then combine them, often as a product on a risk matrix.
• List existing controls. For each scenario, list the controls that act on it. A control works either on likelihood (it makes the attack harder) or on severity (it limits the damage), sometimes on both.
• Check that they work. A declared control is not an applied control. A backup that has never been restored, or multi-factor authentication that leaves out admin accounts, should not lower the rating.
• Re-rate and justify. The new severity-likelihood pair gives the residual risk. For every step gained, record the control that justifies it.

The diagram below uses the accounting firm example. Tick the controls and watch the dot move down the matrix: preventive controls slide it to the left (likelihood), protection and recovery controls move it down (severity).

Calculating residual risk is not enough: someone has to decide to keep it. ISO/IEC 27001:2022 requires this explicitly. Clause 6.1.2 asks you to set risk acceptance criteria in advance, and clause 6.1.3 asks you to obtain the risk owners' approval of the treatment plan and their acceptance of residual risks. Since the 2022 edition, ISO 27005 also presents acceptance as a decision taken at the end of treatment rather than a separate stage.

The EBIOS Risk Manager method, published by ANSSI, the French national cybersecurity agency, takes the same line. Its workshop 5, on risk treatment, aims to identify residual risks and set up the framework for monitoring them; according to ANSSI's guide, it produces a summary of residual risks. In the French public sector, this summary feeds the security accreditation file, and the accreditation authority accepts residual risks when it signs the decision.

A useful acceptance has four elements

• A level: the residual rating and the criterion it is compared with.
• An identified decision-maker: the risk owner, who has the authority to commit resources.
• A justification: why going further is not reasonable today (cost, time, business constraint).
• A deadline: the date of the next review, or the event that will trigger it.

Inherent and residual risk shape every risk analysis. They appear in three places.

• In the matrix. A single risk matrix can show each scenario twice, before and after treatment, with an arrow between the two. This is often the clearest view for an executive committee.
• In the risk map. A risk map presented to management should always say whether it shows gross or net risks: they do not tell the same story.
• In monitoring. Residual risk is not fixed. A control that degrades (an unapplied patch, a supplier that changes subcontractor, see our article on third-party risk management) pushes it back up. This is why monitoring is part of the ISO 27005 process.

Finally, rating severity depends on the security needs of what you protect. Stating them first, for example with the DICP criteria, makes inherent and residual ratings more consistent from one scenario to the next.

• Counting planned controls as done. Until it is deployed, a control does not lower residual risk. It belongs in the action plan, with a “target” residual risk.
• Lowering everything by one notch. A control acts on a specific scenario. Email filtering reduces phishing, not a hosting provider outage.
• Forgetting inherent risk. Without it, you cannot spot the controls whose failure would be catastrophic.
• Accepting without a decision-maker. A high residual risk marked “accepted” in a spreadsheet, with no name or date, is not an acceptance.
• Never reviewing the rating. Threats evolve: a risk accepted three years ago may no longer be acceptable.

In a spreadsheet, residual risk quickly becomes a column nobody updates. The Phinasoft risk analysis module links each analysis, whether run with EBIOS RM through a module labelled by ANSSI, with ISO 27005 or with your own method, to your action plan: the risk level changes as controls are implemented. Review and approval workflows formalise decisions, automatic reminders keep action plans moving, and each scope is reassessed from its previous version, which keeps the history of ratings. To see it on your own scenarios, you can request a demo.