Security Risk Rating Using Likelihood and Impact Criteria

Your data-flow diagram from the last lesson gives you the context needed for a meaningful risk rating: valuable assets, inbound entry points, important data flows, and trust boundaries. A risk rating now turns that technical picture into a decision aid. It answers, in a consistent way: how likely is a harmful scenario to succeed under current conditions, and how serious would the consequences be?

In this lesson, you will rate a backend-service risk with defined likelihood and impact criteria, combine those ratings using a matrix, and document the reasoning so that another reviewer can understand—or challenge—your conclusion. This is foundational for security engineering, vulnerability management, incident triage, and Security+ style risk questions.

---

Rate scenarios, not isolated vulnerabilities

A vulnerability alone is not yet a complete risk statement.

For example, “the payment webhook lacks signature verification” identifies a weakness. It does not say:

• who might take advantage of it;
• how they would do so;
• which asset or business function would be affected; or
• what harmful outcome could result.

A useful risk statement connects those elements:

An anonymous internet attacker could submit a forged payment-status webhook to the public OrderHub endpoint because the endpoint does not verify a provider signature, causing fraudulent orders to be marked as paid and potentially shipped.

This statement contains a complete chain:

Element	In the OrderHub scenario
Asset / business function	Accurate payment status and order fulfilment
Threat actor	Anonymous internet attacker
Entry point	Public payment-webhook endpoint
Vulnerability	No signature verification
Threat event	Forged webhook submission
Consequence	Fraudulent payment state and fulfilment loss

Risk analysis is therefore not “how bad is this bug?” It is an assessment of a plausible event in a defined system context.

A compact model is:

$$\text{Risk rating}=M(\text{likelihood},\text{impact})$$

Here, $M$ is the organization’s chosen matrix or scoring method. Although some matrices are introduced as “likelihood times impact,” do not treat ordinal labels such as Low, Moderate, and High as precise numbers. The matrix is a prioritization policy, not a scientific law.

Before rating a scenario, state:

1. Scope and timeframe — for example, “OrderHub production service over the next 12 months.”
2. Current controls — controls that are actually deployed and operating.
3. Assumptions and evidence — such as public API documentation, endpoint logs, previous incidents, code review findings, or security advisories.

This keeps a risk assessment from becoming a collection of personal impressions.

---

Define likelihood before assigning it

Likelihood is the chance that the specific harmful scenario will occur successfully within the stated scope and timeframe. It is not merely the chance that someone will try.

For example, internet-facing login endpoints are routinely targeted by password guessing. The likelihood of an attempt may be very high. But the likelihood of a successful account compromise could be lower if strong MFA, rate limiting, credential monitoring, and secure password storage are operating effectively.

A defensible likelihood rating considers both sides of the scenario:

• Threat-agent factors: capability, motivation, access, and size of the potential attacker population.
• Vulnerability factors: how visible the weakness is, how easy it is to exploit, whether automation exists, and whether exploitation is likely to be detected.
• Current control effectiveness: whether relevant safeguards materially prevent, block, detect, or limit the event.
• Evidence: past incidents, attack telemetry, penetration-test findings, vendor advisories, and experiences of comparable organizations.

For this course, use the following qualitative criteria. In a real organization, these criteria should be tailored to its systems and risk appetite.

Likelihood	Defined criterion
Very Low	Successful exploitation requires exceptional circumstances, unusual privileged access, or capabilities not realistically available to likely attackers. Relevant controls are strong and verified.
Low	Exploitation is possible but requires meaningful preconditions, special access, or uncommon effort. Existing controls make success unlikely.
Moderate	A credible attacker could exploit the issue with some effort or favorable conditions. Controls may exist but have gaps, limited coverage, or uncertain effectiveness.
High	Likely attackers can reach the target and exploit the weakness with commonly available knowledge or tools. Relevant controls are weak, absent, bypassable, or inconsistently applied.
Very High	Exploitation is straightforward, broadly accessible, readily automated, or already observed. Little prevents a likely attacker from succeeding.

Two discipline rules matter here:

• Rate the risk scenario as written. Do not quietly change it from “a forged webhook changes payment status” to “any external request reaches the API.”
• Include existing controls, not planned controls. A control that is scheduled for the next release has not reduced today’s risk.

The OWASP methodology provides a useful set of prompts for making these judgments less subjective.

---

Define impact as the consequence of success

Impact asks a different conditional question:

If the scenario succeeds, how serious is the credible consequence to the organization?

Do not lower impact because an event seems unlikely. Likelihood and impact are deliberately separate dimensions.

A backend engineer may initially focus on the technical outcome: “the database was modified” or “an API returned customer records.” That is necessary evidence, but it is not the whole impact. Translate the technical effect into consequences for the organization:

• Confidentiality: Was personal data, a credential, a secret, or commercially sensitive information disclosed?
• Integrity: Could order values, permissions, payment states, audit records, or deployed code be changed?
• Availability: Could users, customers, or dependent services lose access to a service?
• Accountability: Would the organization be unable to determine who performed a sensitive action?
• Business effects: Could there be financial loss, fraud, contractual breach, regulatory exposure, operational disruption, or loss of customer trust?

Use this impact scale:

Impact	Defined criterion
Very Low	Negligible, contained effect. No sensitive data is exposed or altered; recovery is routine; little or no customer or operational consequence.
Low	Limited effect on a small internal function, non-sensitive data, or a small number of users. Recovery is straightforward and does not materially disrupt a core service.
Moderate	Noticeable operational disruption, limited sensitive-data exposure, or integrity loss requiring investigation and correction. A defined subset of customers or a business process is affected.
High	Material harm to a core service, significant financial or fraud exposure, major integrity loss, substantial sensitive-data exposure, or likely legal, contractual, or reputation consequences.
Very High	Organization-wide or potentially existential harm: prolonged critical-service failure, large-scale regulated-data exposure, extensive fraud, severe safety consequences, or major regulatory and business repercussions.

When multiple kinds of impact are possible, use the highest credible material impact under the defined assumptions. “Credible” is important. Avoid rating every flaw as Very High merely because an elaborate worst-case chain can be imagined.

A small outage can be High impact for an online retailer during a peak sales period, but Low impact for an internal tool used only occasionally. The same technical event can deserve different ratings in different organizations.

---

Combine the ratings consistently

Once likelihood and impact are defined, use the organization’s approved matrix. The following matrix is one example. Read the row for likelihood and the column for impact; the intersecting cell is the overall risk level.

Notice several implications of this matrix:

• A Very High likelihood event with Very Low impact can still be rated Very Low. Frequent but inconsequential events should not consume the same attention as serious incidents.
• A Moderate likelihood event with Very High impact is rated High. Serious outcomes deserve attention even when they are not the most probable.
• A Very High likelihood event with Very High impact is Very High risk.
• The labels are not universal. Another organization may classify the same intersection differently because its tolerance for outage, fraud, privacy loss, or regulatory exposure differs.

The purpose of a matrix is consistency. If two people apply the same criteria to comparable scenarios, their ratings should be broadly comparable. If a team changes the criteria or matrix for each risk, the resulting priorities cannot be trusted.

---

Worked rating: forged payment webhook

Return to the OrderHub architecture from the previous lesson.

Scenario

An anonymous internet attacker could submit a forged payment-status webhook to the public OrderHub endpoint because the endpoint accepts payment status based on request fields alone and does not verify a provider signature. This could mark unpaid orders as paid and trigger shipment or other fulfilment actions.

1. Establish the assumptions

Item	Assessment assumption
Scope	Production OrderHub service, next 12 months
Entry point	POST /payment/webhook reachable from the public internet
Asset	Payment-status integrity and fulfilment capability
Existing controls	HTTPS is enabled; request logging exists; no signature verification or replay protection
Evidence	Code review confirms the endpoint trusts a request field such as status=paid

HTTPS does not solve the central problem. It protects data in transit between the attacker and OrderHub, but it does not prove that the sender is the legitimate payment provider.

2. Rate likelihood

The likely threat actor is an anonymous internet user. The endpoint is public, and the attack requires only an HTTP request with chosen values. There is no signature verification to defeat, and the action is easy to automate.

Using the defined criteria, rate likelihood as Very High:

• no special access is needed;
• the weakness is directly exploitable through the intended endpoint;
• the attack requires ordinary web-request skills;
• current controls do not prevent forged status updates.

Logging may help discover the fraud later, but logging alone does not reliably prevent the event. It should not reduce likelihood as if it were a blocking control.

3. Rate impact

A forged payment status affects integrity, not confidentiality: records may say “paid” when no payment occurred. If fulfilment occurs automatically, the organization could ship goods, provide paid features, or incur service costs without receiving payment. Repeated exploitation could also require investigation and reconciliation.

Assume OrderHub handles meaningful customer orders but does not process massive payment volumes. A reasonable impact rating is High:

• the integrity of a core business process is compromised;
• there is plausible direct financial loss;
• customers and support staff may experience fulfilment errors;
• the incident may damage confidence in payment handling.

It is not automatically Very High. That would require evidence of consequences such as organization-wide fraud, major regulated-data exposure, or severe business disruption.

4. Look up the result

Using the illustrated matrix:

• Likelihood: Very High
• Impact: High
• Overall risk: High

A concise record could look like this:

Field	Recorded value
Risk ID	R-ORD-01
Risk statement	Forged webhook can mark unpaid orders as paid
Affected asset	Payment-status integrity and fulfilment capability
Likelihood	Very High
Impact	High
Overall rating	High
Key evidence	Public endpoint; no signature verification; easily crafted HTTP requests
Current controls considered	HTTPS and request logging
Assumptions	Fulfilment may follow payment status; production exposure exists

The rationale is as important as the label. “High” without a scenario, evidence, controls, and assumptions is merely an opinion.

---

Avoid common rating errors

Confusing a threat with risk

“Cybercriminals” is a threat source. “SQL injection” is a vulnerability class or attack technique. Neither is a complete risk rating until you describe the affected system, attack path, and consequence.

Treating internal as trusted

A service-to-database path may be internal, but an attacker who compromises the application service might use its database credentials. Rate the scenario based on actual privileges and segmentation, not the word “internal.”

Letting a control receive more credit than it earns

A firewall, encryption, or log collector may be useful while doing nothing for the scenario being rated. For example, TLS does not stop an attacker from sending a syntactically valid but unauthorized request to a public API.

Rating impact by technical drama alone

“Remote code execution” sounds severe, but its business impact depends on what the affected host can access, whether the service is isolated, and what disruption or exposure follows. Conversely, a simple authorization error can have High impact if it enables broad access to customer records.

Hiding uncertainty

Sometimes you lack key facts: number of affected customers, whether fulfilment is automatic, or whether an endpoint is truly exposed. Record that uncertainty. A useful assessment might say, “Impact is provisionally High; confirm maximum order value and automatic fulfilment behavior with the product owner.”

Mixing inherent and residual risk

• Inherent risk is rated before relevant controls are considered.
• Residual risk is rated after current controls are considered.

Either can be useful, but label which one you are recording. Most operational decisions should be based on the current residual risk, while still documenting which controls justify the reduced rating.

---

A repeatable rating workflow

For each scenario, follow this sequence:

1. Write the risk statement using threat actor, vulnerability or condition, attack path, asset, and consequence.
2. Set scope and timeframe so “likely” has a concrete meaning.
3. Identify current controls and evidence.
4. Rate likelihood against the agreed criteria.
5. Rate impact against the agreed criteria, considering both CIA effects and business consequences.
6. Use the matrix to assign the overall risk level.
7. Document the rationale, assumptions, and uncertainty so the rating can be reviewed later.

This is deliberately qualitative. For an early assessment, a consistent High/Moderate/Low-style method is often more valuable than false numerical precision. Higher-risk decisions may later justify quantitative analysis: estimated financial loss, downtime cost, frequency, or recovery duration.

---

Key takeaways

A security risk rating is a structured judgment about a specific harmful scenario, not a label attached to a vulnerability.

• Likelihood estimates the chance of successful exploitation within a stated context, considering threat actors, exploitability, evidence, and current controls.
• Impact estimates the credible consequence if the event succeeds, including technical CIA effects and business harm.
• A risk matrix combines defined likelihood and impact levels into a consistent overall priority.
• Record the scenario, controls, evidence, assumptions, and rationale alongside the final rating.
• Distinguish inherent risk from residual risk, and never let proposed controls reduce a present-day rating.

Next, you will shift from assessment to safe practice by writing rules of engagement for authorized lab work. Those rules establish exactly what systems, techniques, data, and time windows are permitted before any testing begins.