Side-by-sideGlobalISO/IEC 27005

ISO/IEC 27005 FAQ Inherent vs Residual Risk

This comparison page helps choose the right risk-management approach by scope, evidence, approval, and review requirements.

Applied to this decision area, this page focuses on scope, ownership, evidence, review triggers, and escalation criteria supported by source-linked risk-management guidance.

Author
Sorena AI
Published
May 9, 2026
Updated
May 9, 2026
Questions
4

Structured answer sets in this page tree.

Primary sources
4

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated May 9, 2026
Overview

The comparison explains which method applies to your risk context, what evidence is needed, and how to apply review gates for ISO/IEC 27005.

Side-by-side comparison

Inherent vs Residual Risk: scope, duties, evidence, and decision rule

This comparison identifies when Inherent is the right operating model, when Residual Risk controls the analysis, and how to reuse evidence without mixing sources.

Review all sources
First framework
Inherent

Inherent is the starting point: assess the risk before security controls or treatment measures are applied, so the result shows the baseline exposure and what must be controlled.

Second framework
Residual Risk

Residual Risk is the follow-on result: assess what remains after controls or treatment measures are in place, so the result shows the exposure left to accept, monitor, or reduce further.

Comparison row 1

Scope and covered activity

Inherent

Inherent risk applies before controls are applied. It shows the baseline exposure for the asset, process, or scenario as it exists without treatment.

Residual Risk

Residual risk applies after controls are applied. It shows the exposure remaining for the same asset or scenario once the treatment plan and control effectiveness are taken into account.

Operational implication

Use Inherent to size the problem before treatment; use Residual Risk to confirm what remains after treatment and whether the remaining exposure is acceptable.

Comparison row 2

Who must act

Inherent

Inherent ownership sits with the team that defines the scenario, estimates the baseline likelihood and impact, and decides what treatment is needed.

Residual Risk

Residual Risk ownership sits with the control owner or risk owner responsible for the implemented treatment, because that person must show what exposure remains and whether further action is needed.

Operational implication

Do not use one owner for both sides unless the same person truly owns both the untreated scenario and the treated result; otherwise record separate owners and approvals.

Comparison row 3

Trigger or threshold

Inherent

Inherent work is triggered when you need the baseline: for example, at planning, scoping, or before selecting controls and treatment options.

Residual Risk

Residual Risk work is triggered after treatment decisions or control changes, when you need to confirm what remains, whether acceptance is still valid, or whether more treatment is required.

Operational implication

If the question is 'What should we do?', start with Inherent. If the question is 'What is left after we did it?', start with Residual Risk.

Comparison row 4

Core obligations

Inherent

Inherent risk requires you to identify the relevant scenario, estimate its baseline likelihood and impact, and choose a treatment path.

Residual Risk

Residual Risk requires you to verify that the selected controls actually reduced exposure, then decide whether the remaining risk is acceptable or needs more treatment.

Operational implication

Treat the two sides as different checkpoints in one workflow: baseline first, remaining exposure second. Do not collapse them into one generic governance task.

Comparison row 5

Evidence and records

Inherent

Inherent evidence should show the starting exposure: scenario description, assumptions, threat and vulnerability inputs, and the initial likelihood and impact rationale.

Residual Risk

Residual Risk evidence should show the ending exposure: implemented controls, control effectiveness, acceptance decision, exceptions, and review date for the remaining risk.

Operational implication

If the evidence only proves the baseline, it supports Inherent but not Residual Risk. If it only proves control operation, it supports Residual Risk but not the original baseline.

Comparison row 6

Timing and cadence

Inherent

Inherent review happens when the scenario changes or when you need a new baseline for planning, selection, or redesign.

Residual Risk

Residual Risk review happens after a control or treatment change, after an incident, or at a scheduled acceptance review to confirm the remaining exposure has not drifted.

Operational implication

Use the baseline to decide treatment timing; use the residual review to decide acceptance timing.

Comparison row 7

Enforcement or assurance route

Inherent

Inherent is usually checked in risk analysis, planning, design review, or treatment selection because it asks how exposed the organization is before controls.

Residual Risk

Residual Risk is usually checked in control assessment, authorization, or acceptance review because it asks whether the controls left the organization with an acceptable level of exposure.

Operational implication

Do not use the same decision test for both sides: baseline analysis answers whether treatment is needed, while residual analysis answers whether the remaining risk can be accepted.

Comparison row 8

Overlap and reuse

Inherent

Inherent can supply the baseline inputs for later treatment work, including the scenario, threats, vulnerabilities, likelihood, and impact rationale.

Residual Risk

Residual Risk can reuse those baseline inputs, but only after controls, treatment changes, and current evidence are added to show what remains.

Operational implication

Reuse the same facts only when they still describe the same stage of the workflow; otherwise keep the baseline record and the residual record separate.

Comparison row 9

Practical decision rule

Inherent

Use Inherent when you need to answer what the risk looks like before treatment and to decide what controls or responses are needed.

Residual Risk

Use Residual Risk when you need to answer what remains after treatment and to decide whether the remaining exposure can be accepted or must be reduced further.

Operational implication

If the question is about choosing treatment, start with Inherent. If the question is about accepting the result of treatment, start with Residual Risk. If both appear in one record, label them separately instead of blending them together.

Practical decision rule

How should teams decide between Inherent and Residual Risk for compliance planning?

  • Start with the trigger: certification, risk review, cloud/customer assurance, incident, supplier, privacy, AI governance, law, or framework mapping.
  • Identify the binding or chosen source for each claim before assigning controls or collecting evidence.
  • Reuse evidence only where the same owner, scope, time period, system, supplier, data type, and acceptance criteria apply.
Search this module

Find a question or answer quickly

4 of 4 questions
Question 1

How should teams distinguish inherent risk from residual risk under ISO/IEC 27005?

Start with one decision record: scope, required inputs, owner, evidence location, and review condition. Then route the result to treatment or acceptance gates.

For ISMS work, keep the traceability chain visible: scope, risk, treatment choice, SoA entry, control owner, evidence sample, exception, corrective action, and management review decision. This keeps the answer useful in audits, customer reviews, incidents, supplier reviews, and management review.

  • Name the accountable owner and reviewer for Inherent vs Residual Risk.
  • Record the scope, assumptions, decision, approval date, evidence location, exception status, and next review trigger.
  • Escalate when Inherent vs Residual Risk changes risk acceptance, service commitments, customer promises, regulatory duties, or certification evidence.
Citations
Question 2

What evidence should prove Inherent vs Residual Risk is current under ISO/IEC 27005?

The evidence should show the process operating. For this artifact, the strongest record usually includes risk criteria, scenarios, likelihood and impact rationale, treatment decisions, residual-risk approvals, and review records.

Avoid evidence that only repeats a requirement. A reviewer should be able to see the actual owner, date, system, supplier, AI system, service, incident, risk, or control sample behind the answer.

  • Use source records from the system of work, not screenshots created only for audit day.
  • Keep exceptions visible as risk acceptance, corrective action, or management-review input.
  • Update linked registers when the answer changes an owner, risk, control, service, supplier, or review date.
Citations
Question 3

Who should approve Inherent vs Residual Risk decisions under ISO/IEC 27005?

The person who can fund, operate, and correct the process should own the decision; governance should review consistency and exceptions.

For high-impact changes, approval should include the teams affected by the evidence: security, privacy, resilience, supplier management, AI governance, legal, risk, or business service owners as relevant.

  • Use a named owner, named backup, and named escalation forum.
  • Separate preparation work from risk acceptance and final approval.
  • Keep approval records with the evidence rather than in disconnected email threads.
Citations
Question 4

When should Inherent vs Residual Risk be reviewed under ISO/IEC 27005?

Review it at planned intervals and whenever the underlying scope, service, supplier, control, risk, AI system, personal data flow, incident process, or customer commitment changes.

A stale record is worse than a short record. If the facts change, update the evidence and mark what changed so the next reviewer can trust the page.

  • Set a planned review date and a change-trigger rule.
  • Use findings to update controls, procedures, contracts, risk registers, or training.
  • Carry unresolved items into management review or risk acceptance.
Citations
Primary sources

References and citations

iso.org
Referenced sections
  • Explains what ISO standards are and how organizations use them.
"Think of them as a formula that describes the best way of doing something."
iso.org
Referenced sections
  • Primary ISO listing for the current ISO/IEC 27001 ISMS requirements standard.
"Information security management systems - Requirements"
iso.org
Referenced sections
  • Primary ISO listing for the risk-management standard that frames how teams compare untreated scenarios, controls, treatment choices, and residual risk evidence.
"Guidance on managing information security risks"
nvlpubs.nist.gov
Referenced sections
  • NIST risk-assessment guidance used for comparison with ISO/IEC 27005.
"Guide for Conducting Risk Assessments"
Related guides

Explore more topics

ISO/IEC 27005 Asset And Scenario Modeling FAQ
How should teams model assets and scenarios under ISO/IEC 27005 risk assessments? Practical answer with owners, evidence, review triggers, and external source references.
ISO/IEC 27005 Compliance Guide
ISO/IEC 27005 Compliance for ISO/IEC 27005 Information Security Risk Management: practical decisions, evidence, owners, review cadence, and source-linked implementation guidance.
ISO/IEC 27005 Impact FAQ
How should teams handle Impact under ISO/IEC 27005? Practical answer with owners, evidence, review triggers, and external source references.
ISO/IEC 27005 Likelihood FAQ
How should teams handle Likelihood under ISO/IEC 27005? Practical answer with owners, evidence, review triggers, and external source references.
ISO/IEC 27005 Qualitative vs Quantitative Method Comparison
Qualitative vs Quantitative Method for ISO/IEC 27005 Information Security Risk Management: practical decisions, evidence, owners, review cadence, and source-linked implementation guidance.
ISO/IEC 27005 Residual Risk Approval Guide
ISO/IEC 27005 Residual Risk Approval for ISO/IEC 27005 Information Security Risk Management: practical decisions, evidence, owners, review cadence, and source-linked implementation guidance.
ISO/IEC 27005 Residual Risk Approval Workflow
ISO/IEC 27005 Residual Risk Approval Workflow for ISO/IEC 27005 Information Security Risk Management: practical decisions, evidence, owners, review cadence, and source-linked implementation guidance.
ISO/IEC 27005 Review Cadence FAQ
How should teams handle Review Cadence under ISO/IEC 27005? Practical answer with owners, evidence, review triggers, and external source references.
ISO/IEC 27005 Risk Acceptance FAQ
How should teams handle Risk Acceptance under ISO/IEC 27005? Practical answer with owners, evidence, review triggers, and external source references.
ISO/IEC 27005 Risk Assessment Template and Workflow
ISO/IEC 27005 Risk Assessment Template for ISO/IEC 27005 Information Security Risk Management: practical decisions, evidence, owners, review cadence, and source-linked implementation guidance.
ISO/IEC 27005 Risk Criteria Guide
ISO/IEC 27005 Risk Criteria for ISO/IEC 27005 Information Security Risk Management: practical decisions, evidence, owners, review cadence, and source-linked implementation guidance.
ISO/IEC 27005 Risk Criteria Setup Workflow
ISO/IEC 27005 Risk Criteria Setup Workflow for ISO/IEC 27005 Information Security Risk Management: practical decisions, evidence, owners, review cadence, and source-linked implementation guidance.
ISO/IEC 27005 Risk Management FAQ
ISO/IEC 27005 FAQ for ISO/IEC 27005 Information Security Risk Management: practical decisions, evidence, owners, review cadence, and source-linked implementation guidance.
ISO/IEC 27005 Risk Owners FAQ
How should teams handle Risk Owners under ISO/IEC 27005? Practical answer with owners, evidence, review triggers, and external source references.
ISO/IEC 27005 Risk Register Workflow
ISO/IEC 27005 Risk Register Workflow for ISO/IEC 27005 Information Security Risk Management: practical decisions, evidence, owners, review cadence, and source-linked implementation guidance.
ISO/IEC 27005 Risk Treatment Plan Template
ISO/IEC 27005 Risk Treatment Plan Template for ISO/IEC 27005 Information Security Risk Management: practical decisions, evidence, owners, review cadence, and source-linked implementation guidance.
ISO/IEC 27005 Scenario Library Guide
ISO/IEC 27005 Scenario Library for ISO/IEC 27005 Information Security Risk Management: practical decisions, evidence, owners, review cadence, and source-linked implementation guidance.
ISO/IEC 27005 Treatment Options FAQ
How should teams handle Treatment Options under ISO/IEC 27005? Practical answer with owners, evidence, review triggers, and external source references.
ISO/IEC 27005 vs FAIR Comparison
ISO/IEC 27005 vs FAIR for ISO/IEC 27005 Information Security Risk Management: practical decisions, evidence, owners, review cadence, and source-linked implementation guidance.
ISO/IEC 27005 vs ISO 31000 Comparison
ISO/IEC 27005 vs ISO 31000 for ISO/IEC 27005 Information Security Risk Management: practical decisions, evidence, owners, review cadence, and source-linked implementation guidance.
ISO/IEC 27005 vs NIST SP 800-30 Comparison
ISO/IEC 27005 vs NIST SP 800-30 for ISO/IEC 27005 Information Security Risk Management: practical decisions, evidence, owners, review cadence, and source-linked implementation guidance.