Category: Risk Assessment and Treatment

Likelihood

Also known as: Probability of Occurrence

Simply put

Likelihood is a measure of the chance that something will happen. In a security compliance context, it describes how probable it is that a particular threat or risk event will occur.

Formal definition

In risk assessment, likelihood expresses the estimated chance that a given threat event or scenario will occur, typically evaluated alongside impact to determine an overall risk rating. It is generally captured either qualitatively (for example, low, medium, or high) or quantitatively (for example, an assigned probability or frequency), with the specific scale and criteria depending on the organization's risk methodology and scope. In statistics more broadly, the term carries a distinct technical meaning as a function measuring how plausible a set of parameter values is given observed data; practitioners should note that risk-assessment usage refers to the everyday sense of chance or probability rather than the formal statistical likelihood function.

Why it matters

In a security compliance program, likelihood is one of the two dimensions, alongside impact, that drive nearly every risk-based decision. Whether an organization is prioritizing remediation work, allocating budget, or deciding which threats warrant a formal control, an estimate of how probable a threat event is provides the basis for that judgment. Without a defensible sense of likelihood, teams risk treating remote and imminent threats identically, which wastes resources on unlikely scenarios or leaves probable ones underprotected.

Both SOC 2 and ISO 27001 depend on likelihood as an input to their risk processes, though they approach it differently. Under ISO/IEC 27001, the ISMS requirements in clauses 4 through 10 call for a risk assessment that informs the selection of Annex A reference controls via the Statement of Applicability, and likelihood is typically a core factor in that assessment. In a SOC 2 examination, the service organization's risk assessment supporting the Common Criteria similarly considers the probability that identified risks will materialize. In both cases, the specific scales and criteria depend on the organization's chosen methodology rather than a single mandated formula.

A subtle but important pitfall involves terminology. In risk assessment, likelihood means the everyday sense of chance or probability that an event will occur. In statistics more broadly, the term carries a distinct technical meaning, a function measuring how plausible a set of parameter values is given observed data. Conflating the two can lead to misunderstandings when technical and risk teams collaborate, so practitioners should be explicit about which sense they intend.

Who it's relevant to

GRC and Risk Managers

These practitioners define the likelihood scale and criteria within the organization's risk methodology and apply them consistently across assessments. They are responsible for ensuring likelihood estimates are documented and defensible, since these ratings drive prioritization and treatment decisions.

ISO 27001 ISMS Owners

Those maintaining an ISMS use likelihood as an input to the risk assessment required under clauses 4 through 10, which informs the selection of Annex A reference controls recorded in the Statement of Applicability. The chosen approach to estimating likelihood should align with the organization's overall risk methodology and defined scope.

SOC 2 Compliance Teams

Teams preparing for a SOC 2 examination consider likelihood when assessing risks that support the Common Criteria (Security) and any additional Trust Services Criteria selected for scope. They should be prepared to demonstrate a consistent, repeatable basis for how likelihood is assigned.

Auditors and Assessors

CPA firms performing SOC 2 examinations and certification body assessors evaluating an ISMS review how the organization estimates and applies likelihood. In most engagements they focus on the consistency and defensibility of the methodology rather than mandating a specific scale or value.

Inside Likelihood

Probability of Occurrence

Likelihood expresses the chance that a given threat will exploit a vulnerability within a defined timeframe. In an ISO 27001 risk assessment, it is one of the two dimensions (alongside impact or consequence) typically combined to estimate risk level, though the specific scale and method are defined by the organization's risk assessment methodology.

Qualitative or Quantitative Scale

Likelihood is commonly rated using a qualitative scale (for example, low/medium/high or a numbered range) or, in some engagements, a quantitative frequency estimate. ISO 27001 clauses 6.1.2 and 8 require a defined and repeatable approach, but the standard does not mandate a particular scale, so the granularity depends on scope and methodology.

Threat and Vulnerability Inputs

Estimating likelihood typically draws on threat intelligence, historical incident data, the presence and strength of existing controls, and known vulnerabilities. Existing Annex A controls (selected via the Statement of Applicability in the ISO/IEC 27001:2022 revision) can reduce assessed likelihood, which is why likelihood is often evaluated both before and after control application (inherent versus residual).

Role in Risk Prioritization

Combined with impact, likelihood helps rank risks so that treatment decisions can be prioritized. It informs the risk treatment plan required under ISO 27001, but the resulting risk level and acceptance thresholds are set by the organization's risk criteria rather than prescribed by the standard.

Common questions

Answers to the questions practitioners most commonly ask about Likelihood.

Is likelihood in a risk assessment the same as the probability of a breach actually happening?

Not exactly. Likelihood is an analytical estimate of how probable a risk scenario is within the assessment context, not a guarantee or precise forecast of a breach. It is one input into rating risk, and it depends on the assumptions, threat context, and control environment considered at the time. Actual outcomes can differ from the estimated likelihood, which is why assessments are typically periodically reviewed and updated.

Does either SOC 2 or ISO 27001 require me to express likelihood as a specific numeric percentage?

No single format is mandated. ISO/IEC 27001 requires a defined risk assessment process in its clauses but does not prescribe whether likelihood is expressed qualitatively (for example, low/medium/high), semi-quantitatively, or numerically; the organization defines its own criteria. SOC 2 engagements likewise do not dictate a fixed scale. In most cases the chosen method depends on the organization's risk methodology and what the auditor or certification body considers consistently applied.

How do I define likelihood levels for an ISO 27001 risk assessment?

Organizations typically document likelihood criteria as part of their defined risk assessment process, describing what each level means (for example, in terms of frequency of occurrence or ease of exploitation). The levels should be applied consistently across identified risks so results are comparable. The specific number of levels and their descriptions vary by organization and are set within the ISMS methodology rather than fixed by the standard.

How does likelihood factor into selecting Annex A controls via the Statement of Applicability?

Likelihood is generally combined with impact to rate each risk, and the resulting risk levels help inform which reference controls from Annex A are selected or excluded. Those decisions are documented and justified in the Statement of Applicability. The selection is driven by the risk assessment and risk treatment decisions rather than by likelihood alone, and it should reflect the version of Annex A in use.

Should likelihood be reassessed over time, and how often?

Likelihood estimates typically change as the threat environment, controls, and business context evolve, so they are usually reviewed periodically and after significant changes. The frequency and triggers for reassessment are commonly defined within the organization's risk assessment process rather than fixed universally, and depend on scope and the organization's risk appetite.

How is likelihood treated differently in a SOC 2 engagement compared to ISO 27001?

In ISO 27001, likelihood is an explicit part of the ISMS risk assessment process required under the clauses. In a SOC 2 examination, risk assessment activities relate to how controls address the applicable Trust Services Criteria, with the CPA firm evaluating design and, for a Type II, operating effectiveness. While both frameworks consider risk, the terminology, structure, and documentation expectations differ, and using likelihood in one does not automatically satisfy the other.

Common misconceptions

Likelihood is an objective, precisely calculable number.

In most information security risk assessments, likelihood is an estimate informed by available data and expert judgment. Even where quantitative frequencies are used, they typically reflect assumptions and modeling choices that vary by organization, so the value should be treated as an informed approximation rather than a fixed fact.

ISO 27001 mandates a specific likelihood scale or scoring formula.

ISO/IEC 27001 requires a defined, documented, and repeatable risk assessment process (clauses 6.1.2 and 8) but does not prescribe a particular likelihood scale or calculation. The scale, criteria, and method are chosen by the organization and should be applied consistently.

A low likelihood rating means a risk can be ignored.

A low likelihood does not by itself justify inaction, because a low-likelihood event may carry high impact. Treatment decisions depend on the combination of likelihood and impact measured against the organization's risk acceptance criteria, and residual risk still needs to be documented and, where applicable, formally accepted.

Best practices

Define and document a consistent likelihood scale and its rating criteria as part of your risk assessment methodology, so that ratings are repeatable across assessors and over time as required under ISO 27001 clause 6.1.2.

Base likelihood estimates on identifiable inputs such as threat intelligence, historical incidents, and the strength of existing controls, and record the rationale so ratings can be reviewed and defended during certification audits.

Assess likelihood both before and after applying controls to distinguish inherent from residual risk, and reflect selected Annex A controls (from the applicable ISO/IEC 27001 version) through the Statement of Applicability.

Combine likelihood with impact against predefined risk criteria rather than treating either dimension in isolation, and avoid dismissing low-likelihood, high-impact risks without analysis.

Reassess likelihood periodically and after significant changes to the threat environment, systems, or scope, since likelihood estimates can shift and stale ratings undermine the ISMS.

Use qualified language in likelihood ratings and note where estimates depend on assumptions, so that stakeholders understand these are informed judgments rather than guarantees.