Relevant Contents
Need Tailored Business Continuity Insights?
Contact Us Now for Personalized Guidance!
This post is part of BCM Basics, a series of entry-level articles on key concepts in business continuity management.
If you spend time in business continuity or risk management, you will eventually encounter two related terms: inherent risk and residual risk.
The difference is straightforward. Inherent risk describes the exposure associated with a risk scenario before existing controls or treatments are taken into account. Residual risk describes the exposure that remains after the organization considers the effect of its current controls and treatments on that same scenario.
The important question comes next: Is the remaining exposure acceptable, or does the organization need to do more?
In short
- Inherent risk is assessed before current controls and treatments are considered.
- Residual risk is what remains after those measures are taken into account.
- Both assessments should refer to the same underlying risk scenario.
- Controls should receive credit based on evidence that they actually work.
- Residual risk is not the same thing as risk acceptance.
What Is Inherent Risk?
Inherent risk is the exposure associated with a risk scenario before existing controls or treatments are taken into account.
For example, imagine a critical customer-service process that depends entirely on one cloud communications provider. Before considering backup procedures, contractual protections, alternate routing, or other safeguards, the organization would assess the underlying exposure created by that dependency.
Looking at inherent risk helps the organization understand the significance of the original exposure before giving credit to the measures intended to reduce it.
What Is Residual Risk?
Residual risk is the exposure that remains after current controls and treatments are considered.
Those measures might include:
- redundant systems
- alternate suppliers
- cross-trained employees
- manual workarounds
- backup power
- recovery procedures
- contractual or insurance protections
- tested recovery strategies
The existence of a control does not automatically mean it reduces risk as expected.
A recovery plan that has never been exercised, an alternate supplier that cannot support the required volume, or a backup employee without the necessary system access may provide less protection than the organization assumes.
That is why residual-risk assessment should consider evidence of control effectiveness, not simply whether a control exists on paper.
Inherent Risk vs. Residual Risk
| Inherent Risk | Residual Risk | |
|---|---|---|
| When assessed | Before current controls and treatments are considered | After current controls and treatments are considered |
| Purpose | Understand the underlying exposure | Understand what exposure remains |
| Evidence considered | Scenario, likelihood, dependencies, vulnerabilities, and potential consequences | Controls, treatments, test results, procedures, recovery capability, and other evidence of effectiveness |
| Next question | What should we do about this exposure? | Is what remains acceptable? |
Residual Risk Is Not Simple Subtraction
You may sometimes see residual risk described with a formula like this:
Inherent risk – controls = residual risk
That can be useful as a conceptual shortcut, but it should not be treated as a universal calculation method.
Organizations use different risk-assessment methods. Some reassess likelihood and consequence after considering controls. Others use qualitative ratings, matrices, quantitative models, or combinations of these approaches.
The important point is consistency. The inherent and residual assessments should address the same scenario, and the organization should use its approved scoring criteria for both.
Evidence also should not be treated as a number that is simply subtracted from inherent risk. Test results, exercises, procedures, supplier confirmations, and other evidence help determine how much confidence the organization can place in the controls when reassessing the exposure.
A Business Continuity Example
Consider a customer-support operation that depends on a cloud communications provider.
Inherent risk: If the provider becomes unavailable during a high-volume period, customer calls and incident intake could be interrupted.
Current controls: The organization has a service-level agreement and a documented manual escalation procedure.
Those controls may reduce the exposure, but the organization still needs evidence that they are sufficient.
If the manual procedure has never been exercised and essential customer information is available only through the provider’s platform, meaningful exposure remains.
The organization might reduce that residual risk by establishing an alternate routing method, maintaining access to essential contact data, training backup personnel, and exercising the workaround.
Once those measures are implemented and tested, the organization can reassess the same scenario and determine what exposure remains.
Where Does the BIA Fit?
A business impact analysis is closely related to risk and recovery decisions, but the BIA itself should not automatically be treated as a mitigation control.
The business impact analysis helps the organization understand critical processes, dependencies, impacts over time, and recovery requirements.
That information helps guide recovery strategies and treatment decisions. The recovery capabilities developed as a result of that analysis may reduce exposure, but completing the BIA does not by itself make the organization less vulnerable.
What Do You Do With Residual Risk?
If the remaining exposure is not acceptable, the organization may need additional treatment.
Common treatment options include:
- Avoid: Stop the activity or remove the dependency creating the exposure.
- Reduce: Add controls that lower the likelihood or consequence.
- Transfer or share: Allocate part of the exposure through insurance, contracts, outsourcing, or another arrangement.
- Accept: Retain the exposure through an informed decision by someone with the authority to do so.
Transfer requires some caution. Transferring financial or contractual responsibility does not necessarily eliminate the operational consequences of a disruption. Insurance may offset part of a financial loss, but it will not restore an unavailable system or supplier.
For more detail on the treatment options, see What Is Risk Mitigation? The Four Types and How to Apply Them.
Residual Risk Is Not the Same as Accepted Risk
This distinction is important.
Residual risk describes what exposure remains after controls and treatments are considered.
Risk acceptance is a decision to retain some or all of that exposure.
Those are not the same thing.
An organization can identify residual risk and decide that further treatment is required. It can also determine that the remaining exposure falls within its approved criteria and authorize acceptance.
If the decision exceeds the current owner’s authority, it should be routed to the appropriate decision-maker. Escalation is a governance step, not another type of risk treatment.
For more on this distinction, see Risk Acceptance vs. Residual Risk Explained.
The Practical Difference
Inherent risk helps you understand the underlying exposure before current controls and treatments are taken into account.
Residual risk tells you what remains after those measures are considered.
The purpose is not simply to produce two scores.
The useful question is whether the organization’s controls actually reduce the exposure enough to support the business requirement and whether the remaining risk is acceptable to the people authorized to make that decision.
If you need a broader view of how those decisions fit into the overall process, see The Risk Management Process.
Need a Clearer View of Your Current Risk Exposure?
MHA Consulting can help assess disruption risks, evaluate current controls, and connect risk findings to your BIA, recovery strategies, and continuity plans.
Contact MHA Consulting to discuss your current approach.
Further Reading
Richard Long
Richard Long is one of MHA’s practice team leaders for Technology and Disaster Recovery related engagements. He has been responsible for the successful execution of MHA business continuity and disaster recovery engagements in industries such as Energy & Utilities, Government Services, Healthcare, Insurance, Risk Management, Travel & Entertainment, Consumer Products, and Education. Prior to joining MHA, Richard held Senior IT Director positions at PetSmart (NASDAQ: PETM) and Avnet, Inc. (NYSE: AVT) and has been a senior leader across all disciplines of IT. He has successfully led international and domestic disaster recovery, technology assessment, crisis management and risk mitigation engagements.
