ISO/IEC 27005:2022 describes inherent risk as the level of risk without considering any controls, current risk as the level allowing for controls already implemented, and residual risk as risk remaining after treatment. State which basis each rating uses.
The standard supplies guidance rather than a mandatory scoring model, legal rule, or standalone certification scheme.
Structured answer sets in this page tree.
Cited legal and guidance references.
Use only when a no-controls baseline helps the decision. ISO/IEC 27005:2022 says organizations can consider inherent risk or when determining risk levels, and notes that information security methods most commonly assess current risk. is what remains after treatment and is the basis for the risk owner's acceptance decision.
ISO/IEC 27005 describes an inherent level without controls, a current level that credits effective existing controls, and after treatment. Compare them only when the scenario, criteria, units, time horizon, and control assumptions are explicit.
The level of risk without considering any controls. Use this no-controls baseline only when it helps the decision and the hypothetical assumptions can be explained.
Risk remaining after treatment. Determine it through a follow-up assessment that considers proposed or implemented controls and their effectiveness.
| Dimension | Inherent | Residual Risk | Operational implication |
|---|---|---|---|
| Scope and covered activity | Assess the defined scenario without crediting any controls. State where this is a hypothetical condition because the activity has embedded controls. | Assess the same scenario after the relevant treatment, proposed controls, and expected or verified effectiveness are considered. | Use for a no-controls comparison when useful. Use for today's operating exposure and for the remaining exposure after treatment. |
| Who must act | The method owner defines the no-controls convention; analysts apply it; the risk owner confirms that the comparison supports the decision. | The same accountable risk owner approves treatment and accepts or escalates the remaining exposure under authorized criteria. | Keep ownership of the same risk consistent across stages. Separate the risk owner from analysts, treatment owners, and control owners. |
| Trigger or threshold | Use an inherent baseline when the approved method needs a no-controls comparison for prioritization, design, or reporting. | Assess after a treatment decision or control change to determine what remains and whether further treatment is required. | Assess for today's treatment decision and for acceptance after treatment. An inherent baseline does not replace either assessment. |
| Core obligations | Describe the scenario, no-controls assumptions, consequence, likelihood, method, and rationale. ISO/IEC 27005 recommends considering inherent or depending on the situation. | Consider treatment and , reassess likelihood and consequence, compare the result with acceptance criteria, and record acceptance or further treatment. | Treat inherent, current, and residual ratings as labeled views of one risk workflow, not interchangeable scores. |
| Evidence and records | Evidence should show the scenario, no-controls assumptions, threat and vulnerability inputs, time horizon, likelihood, consequence, and uncertainty. | Evidence should show the approved treatment, controls credited, expected or tested effectiveness, follow-up assessment, acceptance decision, conditions, and review date. | A planned control supports an expected residual estimate. Only implementation and effectiveness evidence can support a verified post-treatment rating. |
| Timing and cadence | Review when the underlying no-controls scenario, scope, objectives, criteria, or time horizon changes. | Review as treatment progresses, after control tests or incidents, and at scheduled or event-driven acceptance reviews. | Set separate triggers for the underlying scenario, current control operation, treatment progress, and residual-risk acceptance. |
| Assurance limits | An inherent-risk rating is one method option under ISO/IEC 27005, not proof of certification, compliance, or . | Residual-risk evidence supports ISO/IEC 27001 treatment and acceptance decisions, but ISO/IEC 27005 is guidance rather than a standalone certification standard. | Use the approved criteria and authority model for decisions; neither rating creates legal permission to retain a risk. |
| Overlap and reuse | can supply the scenario, threats, vulnerabilities, likelihood, consequence, and assumptions for later analysis. | can reuse unchanged scenario facts but must add treatment, controls, effectiveness, and current evidence. | Preserve the baseline and version later assessments so reviewers can see which facts and controls changed. |
| Practical decision rule | Use when a no-controls view improves prioritization and its assumptions can be supported. | Use to determine whether treatment is sufficient and whether the remaining exposure can be accepted. | If the no-controls state is too artificial to support, assess instead and document the effective existing controls. |
Assess the defined scenario without crediting any controls. State where this is a hypothetical condition because the activity has embedded controls.
Assess the same scenario after the relevant treatment, proposed controls, and expected or verified effectiveness are considered.
Use for a no-controls comparison when useful. Use for today's operating exposure and for the remaining exposure after treatment.
The method owner defines the no-controls convention; analysts apply it; the risk owner confirms that the comparison supports the decision.
The same accountable risk owner approves treatment and accepts or escalates the remaining exposure under authorized criteria.
Keep ownership of the same risk consistent across stages. Separate the risk owner from analysts, treatment owners, and control owners.
Use an inherent baseline when the approved method needs a no-controls comparison for prioritization, design, or reporting.
Assess after a treatment decision or control change to determine what remains and whether further treatment is required.
Assess for today's treatment decision and for acceptance after treatment. An inherent baseline does not replace either assessment.
Describe the scenario, no-controls assumptions, consequence, likelihood, method, and rationale. ISO/IEC 27005 recommends considering inherent or depending on the situation.
Consider treatment and , reassess likelihood and consequence, compare the result with acceptance criteria, and record acceptance or further treatment.
Treat inherent, current, and residual ratings as labeled views of one risk workflow, not interchangeable scores.
Evidence should show the scenario, no-controls assumptions, threat and vulnerability inputs, time horizon, likelihood, consequence, and uncertainty.
Evidence should show the approved treatment, controls credited, expected or tested effectiveness, follow-up assessment, acceptance decision, conditions, and review date.
A planned control supports an expected residual estimate. Only implementation and effectiveness evidence can support a verified post-treatment rating.
Review when the underlying no-controls scenario, scope, objectives, criteria, or time horizon changes.
Review as treatment progresses, after control tests or incidents, and at scheduled or event-driven acceptance reviews.
Set separate triggers for the underlying scenario, current control operation, treatment progress, and residual-risk acceptance.
An inherent-risk rating is one method option under ISO/IEC 27005, not proof of certification, compliance, or .
Residual-risk evidence supports ISO/IEC 27001 treatment and acceptance decisions, but ISO/IEC 27005 is guidance rather than a standalone certification standard.
Use the approved criteria and authority model for decisions; neither rating creates legal permission to retain a risk.
can supply the scenario, threats, vulnerabilities, likelihood, consequence, and assumptions for later analysis.
can reuse unchanged scenario facts but must add treatment, controls, effectiveness, and current evidence.
Preserve the baseline and version later assessments so reviewers can see which facts and controls changed.
Use when a no-controls view improves prioritization and its assumptions can be supported.
Use to determine whether treatment is sufficient and whether the remaining exposure can be accepted.
If the no-controls state is too artificial to support, assess instead and document the effective existing controls.
ISO/IEC 27005:2022 describes as the level without considering any controls and as the level allowing for the effectiveness of controls already implemented. It defines as risk remaining after treatment. These are different assessment bases, so label the basis and control assumptions on every rating.
A no-controls inherent baseline can be useful for prioritization or comparing gross exposure, but it can be unrealistic for a process that has never operated without embedded controls. is often the more decision-useful starting point for information security treatment. After selecting or implementing treatment, reassess likelihood and consequence with the proposed controls and their effectiveness to determine .
is the level assessed without considering any controls. is what remains after treatment. Between them, is today's exposure after crediting the effectiveness of controls already implemented. Keep the scenario, time horizon, criteria, and units constant and label which controls are excluded, credited, proposed, or verified.
No. ISO/IEC 27005:2022 recommends considering or depending on the situation and says information security methods most commonly use current risk. Use a no-controls baseline only when it supports the decision and its hypothetical assumptions can be explained.
Planned controls can support an expected residual-risk estimate for treatment planning. They do not support a verified post-treatment rating until the controls are implemented and evidence shows how effectively they modify likelihood or consequence. Label the estimate accordingly and perform the follow-up assessment.
The risk owner decides whether is acceptable under the organization's approved acceptance criteria and delegated authority. If the remaining risk exceeds that authority or normal criteria, the decision should be escalated or explicitly justified and approved as the authority model requires.
ISO/IEC 27005:2022 Clauses 6.4.3.4 and 6.5 distinguish inherent and current risk; the residual-risk definition and Clause 8.6.3 explain risk remaining after treatment.
Keep the scenario, scope, criteria, time horizon, consequence and likelihood evidence, rating basis, included and excluded controls, , uncertainty, owner, date, and rationale together. For , add the approved treatment plan, follow-up assessment, acceptance decision, conditions, and review trigger.
ISO/IEC 27005:2022 Clauses 6.5, 8.3, and 8.6.3 support documented methods, evidence-based control credit, and follow-up assessment of residual likelihood and consequence.
Define owner, evidence requirements, evidence requests, and the next review date before approval.
Create tasks, evidence requests, and review checkpoints for inherent, current, and residual risk.
Review your current scope, evidence gaps, and next implementation steps.
Keep one accountable risk owner for the same risk across its inherent, current, and residual views unless the risk itself moves to a different organizational owner. Analysts can calculate the ratings and treatment owners can implement controls, but the risk owner approves the plan and decides whether is acceptable.
ISO/IEC 27005:2022 Clauses 7.2.2 and 8.6 assign risk management, treatment-plan approval, and residual-risk acceptance to accountable risk owners.
Reassess the relevant view when the scenario, criteria, evidence, controls, or treatment changes. changes when the underlying no-controls scenario changes; changes when the operating environment or existing- changes; changes as treatment is implemented, tested, changed, or fails.
ISO/IEC 27005:2022 Clauses 5.2, 8.6.3, and 10.8 support follow-up assessment and regular and change-driven review of risk, controls, treatment, and criteria.
"Information security management systems — Requirements"
"Guidance on managing information security risks"