What Is Risk? The NIST Definition and Why It Changes How You Assess

Ask ten cybersecurity professionals to define "risk" and you'll get ten different answers. Some will say it's a threat. Some will say it's a vulnerability. Some will conflate it with impact, the bad thing that might happen. The word is so overloaded in professional conversation that it often obscures more than it reveals.

In the NIST framework, risk has a precise definition. Understanding it, really understanding it, not just recognizing the formula, changes how you design and conduct assessments, and how you write findings that hold up to scrutiny.

The NIST Definition

NIST SP 800-30 Rev 1 defines risk as a measure of the extent to which an entity is threatened by a potential circumstance or event, typically a function of the adverse impacts that would arise if the circumstance occurs, and the likelihood of occurrence. Note the word function: NIST does not prescribe a specific arithmetic. In semi-quantitative practice the relationship is often expressed as:

SP 800-30 Rev 1 · Section 1 · Risk Definition

Risk = f(Likelihood, Impact)

A function of likelihood and impact, not a strict multiplication. The qualitative Table I-3 lookup isn't an arithmetic product at all. What matters is that both inputs are precisely defined, not eyeballed.

LIKELIHOOD

The probability that a threat event occurs AND adversely affects the system. Combines threat source capability, intent, and vulnerability susceptibility.

IMPACT

The magnitude of harm if the threat event occurs. Measured across Confidentiality, Integrity, and Availability with reference to mission impact.

What Risk Is Not

Before going deeper, it's worth clearing up the terms that get confused with risk in everyday practice:

Term	What It Is	What It Is Not
Threat	A threat source (who or what) paired with a threat event (what they might do). Example: external adversary attempting phishing.	Not a vulnerability, not an impact, and not risk by itself.
Vulnerability	A weakness that could be exploited. Example: MFA not deployed on email.	A vulnerability without a threat is not risk. There must be something that would exploit it and something at stake if it does.
Impact	The harm that results if a threat event occurs. Example: credential theft leads to data exfiltration.	Impact without likelihood is not risk. Low-probability/high-impact events carry fundamentally different risk profiles than high-probability/low-impact ones.
Risk	The combination of likelihood (threat + vulnerability) and impact. A function of all three elements above.	Not a synonym for any one of threat, vulnerability, or impact. None of those terms alone describes risk.

The Three Tiers of Risk

NIST SP 800-39 distinguishes risk at three organizational levels, and this distinction matters for how you scope and communicate findings:

Tier 1, Organization

Risk to the mission and business functions of the entire organization. Risk tolerance decisions, governance structures, and enterprise security strategy live here. An authorization decision is made at the system level (Tier 3), but it is judged against the risk tolerance set at this tier, so a single-system ATO is ultimately weighed in organizational terms.

Tier 2, Mission/Business Process

Risk to the specific mission processes and business functions that rely on information systems. Security architecture, enterprise security services, and common control programs operate at this tier.

Tier 3, Information System

Risk to the confidentiality, integrity, and availability of specific systems and their information. This is where most assessments operate, identifying specific threats, vulnerabilities, likelihood, and impact for a defined system boundary.

Why this matters: A Tier 3 finding only informs the authorization decision when it's connected to Tier 2 and Tier 1 impacts. "This server has 47 unpatched CVEs" is an observation. "An exploit of this server could compromise the CUI processed on our DoD contract, exposing us to DFARS 7012 reporting obligations and potential contract termination" is a risk statement.

Inherent Risk vs. Residual Risk

Inherent risk is the risk that exists before any controls are applied. It reflects the threat environment and the underlying vulnerabilities of the system, assuming nothing has been done to mitigate them. Inherent risk is the right input for prioritizing where to invest security resources.

Residual risk is the risk that remains after controls have been implemented. It's what the authorizing official is actually accepting when they sign an ATO. A system may have High inherent risk, an aggressive threat environment, sensitive data, but Moderate residual risk if effective controls have been put in place and verified.

riskposture.tools/app/ra · Risk Summary · HRIS Platform

Risk Register Summary, 6 Identified Risks

Inherent Risk

2 V.HIGH 3 HIGH 1 MOD

Controls Applied

across 6 risks

Residual Risk

1 HIGH 3 MOD 2 LOW

Controls reduced 2 Very High risks to High and Moderate. 1 High remains due to partially implemented MFA, tracked as an open POA&M item.

Risk Tolerance and the Authorization Decision

Risk tolerance is the organization's predetermined threshold for acceptable risk, the answer to "how much is too much?" It's set at the organizational level (Tier 1) and applied to individual authorization decisions (Tier 3).

When an AO reviews an authorization package, they're comparing the system's residual risk profile against the organization's stated risk tolerance. If residual risk is within tolerance, the ATO is issued. If it exceeds tolerance, the AO either denies authorization or issues conditions requiring specific remediation.

This is why the ATO decision is a risk management decision, not a compliance checkbox. An organization could, in principle, accept a system with a known High-severity finding if the mission value outweighs the risk and remediation is being actively tracked. That's a legitimate risk management judgment, as long as it's documented and the AO owns it explicitly.

Why Precise Language Matters

When an assessment report says "the system is at risk from phishing," it's technically incomplete. Which threat source? What specific threat event? What vulnerability does it exploit? What's the likelihood given current controls? What's the impact to which CIA dimensions?

The SP 800-30 framework structure isn't pedantic for its own sake. It makes risk statements auditable, comparable across assessments, and defensible when an AO asks "why did you rate this High?" The Risk Assessment tool structures every entry through this lens: threat source, threat event, vulnerability, intermediate likelihood, CIA-decomposed impact, and control-adjusted residual. The result is a register that can be defended step-by-step, not just eyeballed.

Frequently asked questions

How does NIST define risk?

NIST SP 800-30 Rev 1 defines risk as a measure of the extent to which an entity is threatened by a potential circumstance or event, typically a function of the adverse impacts that would arise if the circumstance occurs and the likelihood of occurrence. NIST says a function of likelihood and impact, so it does not prescribe a specific arithmetic. What matters is that both inputs, likelihood and impact, are precisely defined rather than eyeballed.

Isn't a threat, a vulnerability, or an impact the same as risk?

No. A threat is a threat source paired with a threat event. A vulnerability is a weakness that could be exploited. An impact is the harm that results if a threat event occurs. Risk is the combination of likelihood (threat plus vulnerability) and impact, a function of all three elements. None of those terms alone describes risk: a vulnerability without a threat is not risk, and an impact without likelihood is not risk.

What is the difference between inherent risk and residual risk?

Inherent risk is the risk that exists before any controls are applied, reflecting the threat environment and the underlying vulnerabilities assuming nothing has been done to mitigate them. Residual risk is the risk that remains after controls have been implemented, and it is what the authorizing official is actually accepting when they sign an ATO. A system may have High inherent risk but Moderate residual risk if effective controls have been put in place and verified.

Why is issuing an ATO a risk management decision rather than a compliance checkbox?

When an AO reviews an authorization package, they compare the system's residual risk profile against the organization's stated risk tolerance. If residual risk is within tolerance, the ATO is issued; if it exceeds tolerance, the AO either denies authorization or issues conditions requiring specific remediation. An organization could, in principle, accept a system with a known High-severity finding if the mission value outweighs the risk and remediation is being actively tracked, as long as it is documented and the AO owns it explicitly.