Inherent Risk vs Residual Risk: Definitions, Scoring and a Worked Example

Short answer: Inherent risk is the level of risk before you account for any controls. Residual risk is the level that remains after your controls are applied and working. The gap between the two is a measure of control effectiveness, and residual risk is the number you compare against your risk appetite to decide whether to accept, treat or escalate a risk.

Related guides:

• Risk register
• ISO 27001 risk treatment plan
• Risk appetite vs risk tolerance

Key takeaways

• Inherent risk answers "how bad could this be if we did nothing?" Residual risk answers "how bad is it with the controls we actually run today?"
• Both are usually scored the same way, such as likelihood multiplied by impact, so the two numbers can be compared directly.
• The drop from inherent to residual should be justified by tested controls, not by policies that exist only on paper.
• Auditors and customers care most about residual risk, because that is what you are asking leadership to accept.
• Most scoring problems come from double-counting controls, using controls you have never tested, and skipping the inherent score entirely.

---

What is the difference between inherent risk and residual risk?

Inherent risk is risk with no controls in place, and residual risk is the risk left over after controls reduce likelihood, impact or both.

Inherent risk describes the raw exposure that comes with an asset, process or activity. A database full of electronic protected health information (ePHI) has high inherent risk simply because of what it holds and who would want it. You score it by imagining the scenario without your safeguards: no encryption, no access restrictions, no monitoring.

Residual risk is what remains once you factor in the controls you have actually implemented. Controls rarely eliminate a risk. They lower the chance that a threat succeeds (likelihood), limit the damage when it does (impact), or both. Whatever is left is residual risk, and someone with authority must decide whether that level is acceptable.

In short, inherent risk minus the effect of working controls equals residual risk. The effect of a control depends on control effectiveness: whether it is designed to address the specific threat and whether it actually operates as designed, every time.

Some teams also track a third value, target risk, which is the residual level you expect to reach after a planned treatment is finished. It is useful in a risk treatment plan because it shows leadership what the next investment will buy.

Inherent vs residual risk: side-by-side comparison

The two scores use the same scale but answer different questions and drive different decisions.

	Inherent risk	Residual risk
Question it answers	How exposed are we with no controls?	How exposed are we with our current controls?
When you score it	When the risk is first identified	After mapping and testing controls, then at every review
Inputs	Threat, vulnerability, asset value, likelihood, impact	Inherent score plus evidence of control effectiveness
Main use	Prioritizing which risks need the strongest controls	Deciding to accept, treat, transfer or avoid
Who reviews it	Risk analyst, security lead	Risk owner, leadership, auditors
How often it changes	Only when the business, threat or asset changes	Whenever a control is added, removed or fails

Both values belong side by side in your risk register. Keeping only the residual score hides how much you depend on your controls, which is exactly what you need to know when a control fails.

Worked example: scoring ePHI in a cloud database

Here is how a HealthTech SaaS company might score one risk end to end, using a 1–5 scale for likelihood and impact and multiplying the two for a score out of 25.

Risk statement: Unauthorized access to patient records stored in the production cloud database, leading to disclosure of ePHI.

Step 1: Score inherent risk

Imagine the database with no safeguards: it holds ePHI for thousands of patients, every engineer can reach it, and nobody reviews access.

• Likelihood: 4 (likely). Credential theft and misconfiguration are common attack paths for cloud data stores.
• Impact: 5 (severe). Exposure would trigger breach notification obligations, customer contract issues and serious reputational harm.
• Inherent score: 4 x 5 = 20 (critical).

Step 2: Map the controls that address this specific scenario

Control	What it affects	Tested?
SSO with phishing-resistant MFA for console and database access	Likelihood	Yes, configuration export and sample of login logs
Least-privilege IAM roles, no standing production access	Likelihood	Yes, quarterly access review evidence
Database in a private subnet, no public endpoint	Likelihood	Yes, automated cloud configuration check
Encryption at rest with managed keys	No reduction in this scenario (it only helps with stolen disks or snapshots)	Yes, configuration evidence
Audit logging and alerting on bulk record reads	Impact (faster detection and containment)	Partially, alerting has never been triggered in a test

Notice the encryption row. Encryption at rest protects stolen storage or backups, but an attacker with valid application credentials sees decrypted data, so it earns no credit in this scenario.

Step 3: Score residual risk

• Residual likelihood: 2 (unlikely). MFA, least privilege and network isolation are all tested and working.
• Residual impact: 5 (severe). Logging could shorten the exposure window, but the alerting has never been tested, so it earns no credit yet. Encryption does not apply to this scenario.
• Residual score: 2 x 5 = 10 (high).

Step 4: Decide

A high residual score usually needs a treatment plan rather than simple acceptance. The quickest treatment here is to test the bulk-read alert. Once a test shows it fires and someone responds, the team can credit it, drop residual impact to 4 and record a residual score of 2 x 4 = 8 (medium), which the risk owner may accept with documented sign-off. If the appetite says ePHI risks must be low, the plan goes further, such as adding just-in-time access approvals, and records a target residual score in the treatment plan.

Your numbers will differ. What matters is that every reduction from 20 to 10, and later to 8, is traceable to a control and to evidence that the control works.

How do inherent and residual risk show up in ISO 27001, SOC 2 and HIPAA?

All three expect a documented risk assessment, but they use slightly different language, so map your inherent and residual scores to each one's vocabulary.

ISO 27001

ISO 27001 requires you to define risk assessment criteria, including risk acceptance criteria, then identify, analyze and evaluate information security risks. Risk treatment follows: you select controls, compare them with Annex A, produce a Statement of Applicability and write a risk treatment plan. Risk owners must approve the treatment plan and accept the residual information security risks.

Auditors look for consistent scoring criteria, a clear link from each treated risk to controls in your Statement of Applicability, and evidence that risk owners formally accepted the residual risk. The standard does not force you to record a separate inherent score, but doing so makes your treatment decisions far easier to defend. Our ISO 27001 audit risk assessment guide covers what auditors ask for in more detail.

SOC 2 (CC3)

The SOC 2 common criteria include a risk assessment series, CC3, based on COSO principles. It expects you to specify objectives clearly, identify and analyze risks to those objectives, consider the potential for fraud, and assess changes that could significantly affect your system of internal control. Auditors typically ask to see the risk assessment itself, evidence that it is performed on a regular cycle (the criteria do not set a frequency, but most teams and auditors work to at least once a year), and how identified risks map to your controls.

Inherent and residual scoring fits naturally here: the inherent score shows honest analysis, and the residual score, backed by controls the auditor already tests, shows the remaining exposure is understood.

HIPAA risk analysis

The HIPAA Security Rule requires an accurate and thorough risk analysis of potential risks and vulnerabilities to the confidentiality, integrity and availability of ePHI, followed by risk management measures that reduce those risks to a reasonable and appropriate level. HHS guidance describes assessing likelihood and impact and documenting current security measures.

The rule does not use the terms "inherent" and "residual," but the structure lines up: assess the threat, document current safeguards, determine the level of risk that remains, and then decide what further measures are reasonable and appropriate. Our guide on how to conduct a HIPAA risk assessment walks through each step.

How do you compare residual risk against risk appetite?

You compare the residual score to thresholds that leadership has agreed in advance, and each threshold triggers a defined action.

Without written thresholds, residual scores are just numbers. A workable approach for a small team:

1. Set bands on your scoring scale. For a 1–25 scale, for example: 1–4 low, 5–9 medium, 10–14 high, 15–25 critical.
2. Attach an action to each band. Low: accept and review annually. Medium: risk owner may accept with written justification. High: treatment plan required with a deadline. Critical: escalate to leadership immediately.
3. Set stricter bands for sensitive data where needed. Many HealthTech teams choose a lower acceptable level for risks involving ePHI than for internal tooling.
4. Record the decision. Log who accepted the risk, when, and the review date.
5. Revisit when anything changes. A new product, a new data type or a failed control should trigger a fresh look at the residual score.

If you are unsure how appetite and tolerance differ, read the risk appetite guide linked at the top of this article before setting your bands.

What are the most common risk scoring mistakes?

The biggest mistakes are double-counting controls, crediting controls nobody has tested, and scoring inherent risk with controls already in mind.

Use this checklist when reviewing your register:

• Double-counting controls. If you reduced the inherent score because "we use a cloud provider" and then reduced it again for the same provider's encryption, you counted one control twice. Each control should reduce the score once, for the scenario it actually addresses.
• Not testing control effectiveness. A policy that says "access is reviewed quarterly" is not the same as completed quarterly reviews. Only give full credit to controls with recent evidence that they operate.
• Scoring inherent risk with controls in mind. If your inherent and residual scores are always close together, your team is probably picturing today's environment when scoring inherent risk.
• Ignoring which factor a control affects. MFA mainly reduces likelihood. Backups and incident response mainly reduce impact. Lowering both factors for every control overstates the benefit.
• Vague risk statements. "Data breach" is too broad to score. Name the asset, threat and consequence.
• Never updating residual scores. Residual risk is not a one-time number. A control failure should raise it immediately, not at next year's review.

If you are choosing between qualitative, semi-quantitative and quantitative scoring, our overview of seven risk assessment methodologies compares the options.

How SecureSlate helps

Residual risk is only as reliable as the evidence behind your controls. SecureSlate helps SMB and HealthTech teams keep that evidence current with continuous control monitoring and automated evidence collection, so you can see when a control stops working and update the related risk. You also get multi-framework mapping across ISO 27001, SOC 2 and HIPAA, policy templates, vendor risk management and a trust center for sharing your posture with customers.

Start your free SecureSlate trial

FAQ

Can residual risk be higher than inherent risk?

Not in a well-scored register. Residual risk should be equal to or lower than inherent risk, because controls only reduce exposure. If residual comes out higher, a control is introducing a new risk that should be logged separately, or the inherent score was too low.

Can residual risk ever be zero?

Practically, no. Controls can reduce risk a great deal, but some chance of a threat succeeding almost always remains. The goal is to bring residual risk within your risk appetite, not to eliminate it.

Do auditors require an inherent risk score?

Not always. ISO 27001, SOC 2 and HIPAA require a documented risk assessment and treatment, but they do not all mandate a separate inherent score. Recording one is still good practice, because it shows how much you rely on each control.

Who should accept residual risk?

The risk owner, meaning a person with the authority and budget to act on the risk. For high or critical residual risks, acceptance should usually go to senior leadership, as defined in your risk acceptance criteria.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory or professional advice. Requirements vary by framework, industry and jurisdiction. Consult qualified advisors for your specific obligations.