01.03 Risk Scoring Methodologies

Why this matters

A risk register is a list of things that could go wrong. A useful risk register is a list of things that could go wrong, ordered by how worried you should be. The ordering is what scoring produces, and the methodology is what makes the ordering defensible. Without a method, every score is opinion; with one, every score is opinion plus a paper trail showing how the opinion was reached.

The trap is treating the methodology as the program. A program with six perfectly-scored risks isn't more useful than one with sixty messily-scored ones. The point of the score is to support a treatment decision. If the score is precise but nobody acts on it, the precision is wasted; if the score is rough but it correctly puts the right risks in the "do something this quarter" bucket, the program is working.

SimpleRisk supports nine scoring methods because no single one fits every risk shape. A known software vulnerability scores naturally on CVSS; a "vendor goes out of business" risk doesn't. A web-application risk scores on OWASP; a strategic risk doesn't. Picking the methodology that matches the risk produces a useful score; forcing every risk through the same methodology produces a register where two-thirds of the rows are scored at "Medium / Medium" because the methodology doesn't have anything more useful to ask.

How frameworks describe this

Each of the nine methods traces back to a specific framework or community. Four of them are versions of the same standard, CVSS.

Classic (Likelihood × Impact) is the qualitative ordinal scoring most security programs start with. The lineage is NIST SP 800-30 Guide for Conducting Risk Assessments, which defines a 5×5 matrix of likelihood (Very Low through Very High) and impact (Very Low through Very High), with the resulting risk level coming from a published lookup table. Classic is what most non-quantitative GRC programs mean when they say "we score risks."
CVSS (Common Vulnerability Scoring System) is the FIRST.org community standard for scoring known software vulnerabilities. It produces a score from 0 to 10, and the score is the one the National Vulnerability Database publishes for CVEs. If your risk is a known vulnerability, CVSS is usually the right tool because the upstream score is already published and defensible. FIRST has released the standard in several versions, and the versions score differently, so SimpleRisk offers four of them as separate methods: CVSS v2.0, CVSS v3.0, CVSS v3.1, and CVSS v4.0. Pick the version your scanner or the NVD entry used, so your score matches the one you are comparing against.
v2.0 scores access vector, access complexity, authentication, and the impact to confidentiality, integrity, and availability.
v3.0 reworked the Base metrics. It added Privileges Required and User Interaction, replaced authentication with them, and added Scope, which says whether an exploit can reach beyond the component that has the flaw.
v3.1 is a clarification of v3.0. It uses the same metrics and the same vector layout, with sharper definitions and a refined Environmental calculation.
v4.0 replaces Scope with a clearer split. It adds Attack Requirements, and it scores the impact on the vulnerable system separately from the impact on subsequent systems. It also reorganizes the optional metrics into Threat, Environmental, and Supplemental groups, and it names the score by what went into it: CVSS-B (Base only), CVSS-BT (Base and Threat), CVSS-BE (Base and Environmental), or CVSS-BTE (all three).
DREAD is a Microsoft-origin scoring methodology (Damage, Reproducibility, Exploitability, Affected users, Discoverability) from the early 2000s threat modeling work. DREAD has critics — the "discoverability" axis in particular is frequently dropped — but it's still in active use in some application-security communities.
OWASP Risk Rating is the OWASP Foundation's methodology for application-security risks, which scores likelihood and impact each as the average of multiple factors (threat agent skill, motive, opportunity, size, ease of discovery, ease of exploit, etc., on the likelihood side; loss of confidentiality/integrity/availability/accountability and financial/reputational/non-compliance/privacy damage on the impact side). It's the right tool when a risk is application-shaped and the team has the time to walk through the factor list.
Custom isn't a methodology in the framework sense — it's a single numeric score the program defines for itself. Custom is the right answer when an organization has its own scoring rubric (for example, a quantitative methodology like FAIR computed in a separate tool) and just needs SimpleRisk to hold the resulting number alongside the rest of the register.
Contributing Risk breaks the impact side into multiple "subjects" (categories like financial, operational, reputational, regulatory, etc.), each carrying its own impact score and its own admin-configured weight. The overall score is a weighted average — likelihood plus the sum of each subject's weighted impact — not a maximum across subjects and not a straight likelihood-times-impact calculation. Useful when your program needs to track multi-dimensional impact without committing to a full quantitative analysis.

For the related deeper methodologies, Factor Analysis of Information Risk (FAIR) is worth knowing about even though SimpleRisk doesn't ship a native FAIR scoring methodology. FAIR is a quantitative methodology that expresses risk as a probability distribution of dollar loss, and it's the right choice when leadership wants risk reported in monetary terms. Many SimpleRisk customers run FAIR in a separate Monte Carlo tool and use the Custom methodology to capture the resulting expected-loss number in the register.

How SimpleRisk implements this

The methodology is selected per risk on the Risk Scoring Method dropdown of the Submit Risk form (see Submitting a Risk). There is no system-wide default method, so agree on one with your team; Classic is the right starting point for most programs. (Administrators choose the formula that Classic uses in the Risk Configuration settings.) Switching methodology on an existing risk is supported; the previous score is recorded in the audit trail before the new methodology's inputs replace it.

Each methodology has its own set of input fields:

Classic asks for Current Likelihood and Current Impact as Very Low / Low / Medium / High / Very High dropdowns. The mapping from the 5×5 matrix to a numeric score is published in the admin settings.
CVSS v2.0 renders inline as a card with the Base, Temporal, and Environmental metric fields from the official standard. The stored score cascades: Environmental takes priority once its fields are set, then Temporal, then Base. Filling in more of the metric groups refines the score rather than competing with it. When none of the optional metrics are filled in, the Temporal and Environmental scores read 0.
CVSS v3.0, v3.1, and v4.0 share one layout, described in the next section.
DREAD asks for the five DREAD factors (Damage, Reproducibility, Exploitability, Affected Users, Discoverability) on a 0–10 scale and computes the average.
OWASP asks for sixteen factors total, each on a 0–10 scale: eight average into a Likelihood category (four Threat Agent factors, four Vulnerability factors) and eight average into an Impact category (four Technical Impact factors, four Business Impact factors). The two categories feed a likelihood × impact severity matrix that produces the OWASP risk rating.
Custom takes a single numeric score from 0 to 10 with no further breakdown.
Contributing Risk asks for one overall likelihood score plus an impact score for each subject your program has configured. Each subject carries an admin-assigned weight (the weights across all subjects must add up to 1), and the score is the normalized likelihood plus the sum of each subject's weighted, normalized impact — a weighted average, not a maximum across subjects and not the same likelihood-times-impact pattern Classic uses.

Scoring with CVSS v3.0, v3.1, or v4.0

Pick the version from Risk Scoring Method and the scoring widget appears right under the dropdown. It has the same pieces for all three versions.

Score card. The card on the left shows the risk level and the score. For v3.0 and v3.1 it shows the Base, Temporal, and Environmental scores side by side. For v4.0 it shows a single score, labeled CVSS-B, CVSS-BT, CVSS-BE, or CVSS-BTE according to which metric groups you filled in. The card also shows the current vector, so the vector that produced the score is always visible next to it. Below it you will find the line "CVSS is owned by FIRST.Org, Inc. and used by permission." and a link to FIRST's specification for that version. The same sentence now appears on the CVSS v2.0 card too.
Metric cards. The Base metrics sit in cards next to the Score card, grouped by what they describe. Each metric has an info icon that explains what it measures and what each choice means, so you can score without the specification open in another tab.
Advanced Metrics. The optional groups (Temporal, Environmental, and the Modified Base metrics for v3.x; Threat, Supplemental, and the Environmental groups for v4.0, which split into Modified Base Exploitability, Vulnerable System Impact, Subsequent System Impact, and Security Requirements, the same way FIRST's calculator does) are collapsed under Advanced Metrics. Leave them closed if you only have the Base values, which is the normal case when you are copying a published score.
Vector. Above the cards is a Vector box. If you already have a vector string, for example CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H from a scanner report, paste it in and choose Apply. SimpleRisk fills in every metric, including the optional ones the vector sets. The pasted vector must belong to the version you selected, and CVSS vectors are case-sensitive. If the vector is malformed, SimpleRisk says what is wrong and leaves your metrics as they were.

You have to complete every Base metric before you can save the risk. If any are missing, the form does not submit. It shows the message "CVSS Base metrics are incomplete. Choose a value for every Base metric or paste a complete vector." and puts focus on the first metric that still needs a value. The optional metrics never block a save. Once a risk is saved, its page shows the same Score card and metric cards read-only.

The score, from 0 to 10, feeds the risk level the same way the other methods' scores do, and then flows into inherent and residual scoring, dashboards, and reports with everything else.

Each version keeps its own entries. If you score a risk with v3.1, switch to v4.0 to try it, and switch back to v3.1, your v3.1 entries are still there. The same goes for the other direction. Only the version selected when you save is stored as the risk's score.
There is no automatic conversion between versions. A v3.1 vector is not a v4.0 vector, and the scores are not interchangeable. Switching a risk to a newer version starts that version blank.
Existing CVSS v2.0 risks are unchanged. They keep their metrics and their scores.
Empty optional groups show "--" on v3.x. The Temporal and Environmental boxes read "--" when none of the metrics in that group are set. The overall score is then the Base score. CVSS v2.0 shows 0 in that situation instead.
Supplemental metrics never change the score. CVSS v4.0 Supplemental metrics (Safety, Automatable, Recovery, Value Density, Vulnerability Response Effort, Provider Urgency) are recorded with the vector for context, and the score stays the same whatever you pick.

Whichever methodology is in use, SimpleRisk produces both an inherent risk score (before mitigation) and a residual risk score (after the recorded mitigation reduces the impact by the mitigation percent). The default risk level (Very Low / Low / Medium / High / Very High) thresholds are configurable in admin settings; the dashboards and the prioritization views read from the residual score by default, with the inherent score available for trend analysis.

The thresholds and the matrix can be customized — the matrix in particular often needs adjustment for organizations whose impact scale doesn't fit a 5×5 grid (for example, because the highest plausible loss for a small organization is less than what the seeded matrix would call "Very High"). Both customizations live under Settings cog → Risk Configuration, on the Scoring and Classic Risk Formula tabs; the Contributing Risk subjects and their weights live on their own Contributing Risk Formula tab on the same page.

Common pitfalls

A few patterns recur across customers when scoring choice goes sideways.

Picking one methodology as the house standard for every risk. A program that mandates CVSS for everything will score most non-vulnerability risks at "Medium / Medium" because the CVSS axes don't have anything else useful to say about a "key person leaves" risk. The methodology should match the risk shape; choosing per risk costs a few seconds at submission and prevents meaningless scores from cluttering the register.
Scoring inherent and ignoring residual (or vice versa). Inherent risk tells you what the risk would look like with no controls. Residual risk tells you what it looks like with the controls you actually have. Both are useful for different conversations — inherent for "where would we be exposed if controls failed," residual for "where are we now, after the work we've done." Programs that report only one of them give leadership a partial picture.
Treating CVSS as a likelihood score. CVSS Base Score isn't a probability; it's a severity-of-the-vulnerability score that assumes the vulnerability is exploited. Translating "CVSS 9.8" to "very likely to happen" loses the meaning. CVSS measures how bad it would be if it happened; the likelihood of it actually being exploited in your environment is a separate analysis, which is why CVSS has Temporal and Environmental metric groups for adjusting the base score to context.
Calibrating once and never again. A 5×5 matrix calibrated when the program was twenty risks may not work when the register has two hundred. If the residual scores are clustering at one end of the matrix, the thresholds aren't separating the risks usefully — recalibrate in the admin settings rather than scoring everything against an outdated scale. Plan to revisit the calibration once a year minimum.
Confusing scoring methodology with risk methodology. "We use NIST 800-30" is a sentence customers say a lot and it doesn't pin down whether they mean the qualitative 5×5 matrix (which Classic implements), the broader risk-assessment process (which is most of the rest of the standard), or both. When a question is about how to assess a risk, the answer is usually about process, not about which scoring inputs to fill in.
Mixing methodologies in the same dashboard without normalizing. A register with fifty Classic-scored risks and ten CVSS-scored risks shown on the same prioritized list will rank the CVSS risks oddly because CVSS produces 0–10 scores with different distribution characteristics than a 5×5 matrix score. The dashboards do normalize to a common 0–10 scale internally, but if a particular report sums or averages raw scores across methodologies the result won't be meaningful. Filter to one methodology when running cross-risk comparisons.
Letting the methodology drive the program instead of the program driving the methodology choice. Picking CVSS because it's "more rigorous" without a vulnerability-management program to feed it produces the same outcome as Classic with extra steps. The methodology serves the work; pick the one that fits the work that's actually being done.