Skip to main content
Bureau of AI
Category: Risk Assessment & Analysis

Risk Analysis

Simply put

Risk analysis is the process of identifying risks, estimating how likely they are to occur, and judging how serious their consequences could be. It helps organizations understand where safeguards or mitigations are needed. It is typically one component of a broader risk management effort rather than a standalone activity.

Formal definition

Risk analysis is an analytical process that identifies risks, estimates their probabilities and expected consequences, and determines their magnitude in order to identify areas requiring safeguards. As commonly defined, it forms a part of risk management and provides information regarding undesirable events to support subsequent assessment and mitigation decisions. The specific methods, scope, and terminology vary by domain and framework; for example, in some security-oriented usages (such as NIST's) it emphasizes identifying security risks and determining their magnitude, while in other fields it centers on estimating probabilities and expected consequences. Note that risk analysis is distinct from, though often paired with, risk assessment, and the boundary between the two terms is not defined uniformly across sources.

Why it matters

Risk analysis matters because it converts vague concerns about what could go wrong into structured information that supports decisions about where to allocate safeguards. Without a disciplined process for identifying risks and estimating their likelihood and consequences, organizations tend to respond to whichever threats are most visible or recent rather than those that are most significant. As commonly defined, risk analysis provides information regarding undesirable events, which allows subsequent assessment and mitigation efforts to be prioritized rather than applied uniformly.

In the context of AI governance and model risk management, risk analysis is one input among several rather than a complete control in itself. It helps surface where a model or system may produce undesirable outcomes and how severe those outcomes could be, but it does not, on its own, eliminate risk; at best it supports measures that reduce or manage it. Professionals should be careful not to treat the output of a risk analysis as a settled verdict, because the estimates it produces depend on assumptions, available evidence, and the methods chosen.

A further reason it matters is definitional discipline. Because the boundary between risk analysis and risk assessment is not defined uniformly across sources, and because security-oriented usages differ from usages centered on estimating probabilities and expected consequences, teams that adopt loose terminology risk miscommunicating scope. Being explicit about which definition and framework is in use helps avoid disputes over whether a given step counts as analysis, assessment, or mitigation.

Who it's relevant to

Model Risk Managers
Those responsible for identifying, measuring, monitoring, and controlling model-related risks use risk analysis to estimate the likelihood and consequences of undesirable model outcomes and to identify where safeguards are needed. They should treat it as one input into broader risk management rather than as a control that removes risk.
AI Governance and Compliance Officers
Professionals designing oversight structures and policies rely on risk analysis to prioritize where organizational controls and accountability mechanisms should concentrate. They benefit from being explicit about which framework's definition of risk analysis is in use, given that terminology and scope vary across domains.
Auditors and Second-Line Reviewers
Reviewers assessing whether risks have been adequately identified and addressed examine risk analysis outputs to evaluate the basis for mitigation decisions. Because the boundary between risk analysis and risk assessment is not uniform across sources, auditors should confirm how each term is scoped in the materials they review.
Security and Data Science Practitioners
Teams working on model or system security may encounter security-oriented usages, such as NIST's, that emphasize identifying security risks and determining their magnitude. This usage can differ from probability-and-consequence-centered usages found in other fields, so practitioners should be aware of which definition applies to their work.

Inside Risk Analysis

Risk Identification
The process of surfacing sources of potential harm or loss associated with a model or AI system, such as data quality issues, model limitations, misuse, or unintended outcomes. Identification typically precedes measurement and does not by itself quantify or rank the risks surfaced.
Risk Measurement or Assessment
The estimation of likelihood and potential impact of identified risks, often expressed qualitatively (e.g., high/medium/low) or quantitatively. Measurement approaches vary by framework and context, and the precision achievable is frequently constrained by data and modeling limitations.
Inherent Risk
The level of risk present before controls or mitigating measures are applied. Analysts commonly assess inherent risk to understand the raw exposure of a model or system independent of governance controls.
Residual Risk
The level of risk remaining after controls and mitigations are applied. Residual risk is distinct from inherent risk, and no set of controls should be described as eliminating risk entirely; controls reduce or manage it.
Risk Prioritization and Rating
The ranking or tiering of risks, often informed by a model's inherent characteristics and materiality. This supports proportionate oversight, though rating schemes differ across organizations and frameworks and are not standardized universally.
Contextual and Scope Framing
Definition of what the analysis covers, including the model or system boundaries, use case, and applicable jurisdiction or sector. The meaning and rigor of risk analysis can differ between banking model risk management and general enterprise AI contexts.

Common questions

Answers to the questions practitioners most commonly ask about Risk Analysis.

Is risk analysis the same thing as risk assessment or risk management?
Not exactly, and professionals frequently blur these terms. Risk analysis is typically understood as one component within a broader risk management process—the step focused on understanding the nature of identified risks and estimating their likelihood and potential impact. Risk assessment, in many frameworks, is a wider activity that encompasses risk identification, risk analysis, and risk evaluation. Risk management is broader still, adding treatment, monitoring, and governance. Treating these as interchangeable can obscure where a given activity sits in the overall process and who is accountable for it.
Does completing a risk analysis mean the risk has been reduced or eliminated?
No. Risk analysis is an analytical activity that characterizes and estimates risk; it does not by itself reduce or eliminate anything. Risk is typically reduced only through subsequent controls, mitigations, or treatment decisions that flow from the analysis. It is also worth distinguishing inherent risk—the level of risk before controls—from residual risk—the level remaining after controls are applied. Analysis informs these judgments but does not change the underlying exposure on its own, and no control set should be described as eliminating risk entirely.
How does risk analysis differ when applied to model risk versus broader AI governance?
In a model risk context, historically informed by supervisory guidance such as SR 11-7 in U.S. banking, risk analysis often centers on risks arising from model use—such as errors in development, inappropriate use, or performance degradation—and feeds into validation and ongoing monitoring. In broader AI governance, risk analysis may also address organizational, ethical, legal, and oversight concerns beyond a single model's behavior. The two overlap but should not be collapsed: one focuses on managing risks from model outputs and use, the other on the structures and accountability governing AI systems. Scope the analysis to the framework you are operating under.
What inputs are typically needed to perform a meaningful risk analysis?
As commonly defined, risk analysis draws on a documented list of identified risks, information about the system or model in scope, data on its intended use and context, and some basis for estimating likelihood and impact—whether qualitative, quantitative, or a combination. The quality of the analysis depends heavily on the quality of these inputs. Where data is incomplete or uncertain, the analysis should state those limitations rather than present estimates as precise. What is out of scope for the analysis itself, such as decisions about acceptable risk thresholds, should be clearly delineated.
Who should be responsible for conducting and reviewing risk analysis?
Responsibility varies by organization and framework, but many governance structures separate the parties who conduct analysis from those who independently review it. In a three-lines-of-defense model, the first line typically owns and analyzes the risks in its activities, the second line provides independent oversight and challenge, and the third line offers independent assurance. The specific allocation should reflect your organization's policies and any applicable supervisory expectations. The point is to preserve independent challenge rather than have the same party both perform and validate its own analysis.
How often should risk analysis be updated?
There is no single universally required cadence; appropriate frequency generally depends on the risk profile, the rate of change in the model or its environment, and applicable policies or guidance. In many frameworks, risk analysis is treated as an ongoing rather than one-time activity, revisited when material changes occur—such as changes to data, intended use, performance, regulatory expectations, or observed model behavior. Establishing triggers for reanalysis, alongside any periodic review schedule, is a common practice, but the specifics should be set in your governance framework rather than assumed.

Common misconceptions

Risk analysis and risk management are the same activity.
Risk analysis is typically a component within a broader risk management process. Analysis focuses on identifying and measuring risk, while management also encompasses monitoring, controlling, and governing risk over time. Collapsing the two obscures the distinct oversight and accountability functions involved.
A completed risk analysis eliminates the risks it identifies.
Risk analysis characterizes exposure; it does not remove it. Even after controls are applied, residual risk generally remains. Analysis should be described as informing decisions and reducing or managing risk, not as a means of eliminating it.
Measuring risk is the same as measuring model performance.
Model risk and model performance degradation are distinct concepts. Strong performance on current data does not by itself resolve risks such as misuse, data limitations, or unintended outcomes, which a risk analysis is intended to surface separately from performance metrics.

Best practices

Define the scope and context of the analysis explicitly, including model boundaries, use case, and applicable jurisdiction or sector, since the rigor and meaning of risk analysis can differ across banking and general enterprise AI settings.
Distinguish inherent risk from residual risk in your assessment so that stakeholders can see both raw exposure and the effect of applied controls.
Separate risk analysis from performance evaluation, treating model risk and performance degradation as distinct concerns rather than assuming good performance addresses all risks.
Use qualified, proportionate risk ratings and document the basis for prioritization, recognizing that rating schemes are not standardized across all frameworks.
Position the analysis as one input to broader risk management, ensuring that identification and measurement feed into monitoring, control, and oversight rather than standing alone.
Document limitations and uncertainty in the analysis, including data constraints and the boundaries of what was assessed, and avoid describing controls as eliminating risk.