Risk Criticality and Confidence Scoring Automation: Severity and Trust Are Never the Same Number

Why probability times impact is not enough, and why severity is not the same as trust
A simple probability-times-impact score treats every risk with the same numeric product identically, even though a slow-moving, easily detected risk with plenty of warning time behaves nothing like a sudden, invisible one with the same nominal score — a team can prepare for the first and gets blindsided by the second. And a second, separate problem hides inside any single risk score: a risk can look genuinely severe on paper while resting on almost no real evidence, or look mild while being backed by solid data — conflating "how bad" with "how sure" produces a number that looks precise and is not defensible under questioning.
How the underlying problem shows up before you fix it
Two risks with the same probability-times-impact product get the same priority, even though one would materialize tomorrow with no detectable warning and the other would take months and give plenty of notice.
A control that exists only on paper — documented in a policy but never actually tested — gets treated as if it already reduced the exposure it was meant to address.
A risk with genuinely thin evidence behind it gets presented with the same apparent confidence as one backed by real indicators, signals, and a confirmed owner.
"Monitor the situation" becomes the entire response plan for a risk that is already rated high or critical, leaving nothing that would actually reduce the exposure if the situation worsens.
A risk is declared "within acceptable tolerance" when no one in the organization has ever actually written down what the tolerance is.
Why a single severity number and a documented-controls habit are the default
A single multiplied score is easy to compute and easy to sort by, which makes it the default even though it cannot represent a genuinely asymmetric case — a moderate risk moving immediately can deserve more attention than a severe one moving slowly, and a multiplication has no way to say that. And a control tends to get credited the moment it is written down in a policy, because verifying that a control actually works in practice takes ongoing effort that a static document never forces anyone to repeat.
How Centriu Oracle scores criticality, confidence and residual exposure separately
Inherent criticality — calculated BEFORE any controls are considered, deliberately, so a control can never quietly lower the starting point — comes from seven weighted criteria: probability and impact (weight 3 each), materialization speed, detectability and reversibility (weight 2 each), and degree of control plus how many other records depend on this risk (weight 1 each), combined into a single weighted percentage and mapped to one of five levels from low to extreme. On top of that weighted score, a set of hard floors can only ever raise the final level, never lower it, each recording its own explicit reason: existential impact floors at "critical," a critical impact combined with at least moderate probability floors at "high," an irreversible effect combined with high-or-greater impact floors at "high," an imminent probability combined with moderate-or-greater impact floors at "high," immediate materialization speed combined with zero advance detectability floors at "high," high-or-greater impact in one of five specific dimensions that never dilute by averaging (privacy, security, legal, data, continuity) floors at "high," and exposure declared outside a stated tolerance policy floors at "high." Only after inherent criticality is set does a documented control get evaluated: a control counts only if it is currently active, has actually been verified (not merely written down), and that verification is no older than 180 days — a stale verification is treated as no verification at all. Verified, effective controls can reduce the residual reading by at most ONE level, no matter how many controls exist or how effective they individually are — this methodology scores residual exposure, never risk elimination. A completely separate confidence score, built from seven different weighted criteria (declared probability basis, linked evidence, anticipatory signals, tracked indicators with actual readings, assessed impact dimensions, a confirmed owner, and a scheduled review), answers "how much should this specific assessment be trusted" rather than "how bad is it" — and it carries its own hard caps: zero evidence, zero signals and zero declared basis together cap confidence at the very lowest level regardless of every other criterion, zero evidence alone caps it at "moderate" even if every other number would compute higher, and the very top rating requires a human to have actually promoted the risk, not just a favorable score. A response evaluation separately flags "monitor" as the sole strategy on a high-or-greater risk, an irreversible or immediately-materializing risk with no contingency plan, and "accept" chosen for a severe risk without a recorded approver. And when no organizational tolerance policy is on file — the common case — the tool states plainly that tolerance is undefined rather than assuming the exposure is acceptable by default.
What is actually built today
A 7-criterion weighted criticality score (not a probability-times-impact multiplication), computed BEFORE controls are considered, confirmed directly in the scoring function's own source.
Seven distinct hard floors that can only ever raise the computed criticality level, each recording its own explicit stated reason in the output — never silently applied.
A verified-and-effective-only control model: a documented-but-unverified control counts as zero, and a verification older than 180 days is automatically treated as unverified again.
A hard one-level cap on residual-exposure reduction, regardless of how many effective controls exist — this is residual scoring, never risk elimination.
A completely separate, independently capped confidence-in-the-assessment score built from seven different criteria than criticality — answering "how much to trust this reading," not "how severe is it."
An automated response-adequacy check that specifically flags "monitor" as an inadequate sole response for a high-or-greater risk, and flags a severe risk with no contingency plan.
An explicit "tolerance undefined" state whenever no organizational risk-appetite policy is on file, rather than defaulting to an assumption of acceptability.
A hygiene pass confirming an owner is actually assigned (not just a job title), a review date is scheduled and not overdue, and a high-or-greater risk has at least one real response strategy on file.
Confirmed in the engine's own source: nothing in this scoring layer changes the OFFICIAL assessment automatically — a recompute only writes when a person explicitly requests it, and neither Run nor Orbit signal-collectors can silently alter it.
Two risks, the same rough odds, very different treatment (illustrative scenario, not a real client)
Two risks are logged for the same client in the same week. The first — a slow, gradual decline in a key supplier's service quality, moderate probability, moderate impact, easily detectable through routine check-ins — computes to a "moderate" criticality with no floor applied. The second — a possible sudden regulatory change affecting the client's core offering, also rated moderate probability and moderate impact on paper, but with immediate materialization speed and a "somente_apos_impacto" (only perceptible after the fact) detectability rating — trips the immediate-velocity-plus-undetectable floor and is elevated to "high" specifically because there is no warning window to react in, even though the raw probability and impact ratings started out identical to the first risk. A documented mitigation control exists for the second risk, but it was never actually verified — the residual reading stays at "high," unchanged from the inherent one, because an unverified control counts as no control at all.
What changes operationally
A fast, hard-to-detect risk gets the elevated attention a slow, easy-to-watch one with the same nominal probability and impact does not automatically deserve — because the score accounts for speed and detectability directly, not just probability and impact averaged together. A control someone wrote into a policy stops counting for anything until it is actually verified to work, and that verification has an expiration built in. And a severity number and a confidence number are never collapsed into one figure that hides which of the two — "how bad" or "how sure" — is actually driving the reading a client is being shown.
When this is not the right fit
An organization that wants a simple, single-number risk heat map with no distinction between severity and confidence, and no interest in verifying whether documented controls actually work, will find this scoring model more rigorous than it needs — it is built for a consulting practice defending its risk reads to a client's leadership, not a lightweight internal checklist.
A single probability-times-impact score vs. a weighted, floor-protected, dual-axis model
A simple multiplication collapses speed, detectability, reversibility, control verification, and confidence into one number that cannot represent any of them individually. Centriu Oracle instead computes a weighted, floor-protected criticality score, evaluates control effectiveness only after independent verification, caps residual reduction at one level regardless of control count, and keeps a fully separate confidence score — so a client always sees not just how bad a risk is rated, but how much that specific rating should actually be trusted.
Related systems
Main system: Centriu Oracle.
What it does NOT do
- Does not multiply probability by impact as the scoring method — criticality comes from seven weighted criteria plus explicit hard floors, confirmed directly in the scoring function's own source, specifically because a simple multiplication cannot represent materialization speed or detectability.
- Does not credit a control for existing on paper — only a control that is currently active AND has been verified within the last 180 days counts toward reducing residual exposure; an unverified or stale-verified control counts as zero.
- Does not let controls reduce residual exposure by more than one criticality level, no matter how many controls are registered — this is residual-exposure scoring, never risk elimination.
- Does not conflate confidence with severity — the confidence score answers a different question (how much to trust this assessment) using different criteria than the criticality score, and neither one is derived from the other.
- Does not automatically change the official risk assessment on its own — a recompute only writes a new official reading when a person explicitly requests it; automated signal-collectors from other systems can only raise an alert, never silently overwrite the assessment.
Security and governance
Every organization using Centriu Oracle sees only its own risk registers and controls; access is scoped by organization membership and re-checked on every write. Personal data follows Brazil's LGPD (Law No. 13,709/2018). Full detail on access control lives at /governanca.
Pricing and contracting
Available by monthly subscription, with tiered plans. Values and terms come from the official pricing table at /precos (Centriu's central source — never restated here).
Frequently asked questions
Why not just multiply probability by impact?
Because a moderate-probability, moderate-impact risk that would materialize immediately with no advance warning needs more attention than one with the same nominal score that would unfold slowly with plenty of notice — a simple multiplication cannot represent that difference, so criticality instead uses seven weighted criteria plus hard floors.
Does a documented control automatically reduce a risk's score?
No. A control only counts if it is currently active and has been independently verified within the last 180 days. A control that is only written into a policy, or whose verification is stale, counts as no control at all.
How much can controls reduce the risk rating?
By at most one criticality level, regardless of how many verified, effective controls exist — the methodology is explicit that this produces a residual reading, never a claim that the risk has been eliminated.
Is the confidence score the same as how severe the risk is?
No, deliberately. Confidence answers "how much should this specific assessment be trusted," built from different criteria (evidence, signals, indicators, a confirmed owner) than criticality, which answers "how bad is it." A risk can be rated severe with low confidence, or mild with high confidence.
What happens if no risk-tolerance policy exists for the organization?
The tool states explicitly that tolerance is undefined and that leadership needs to declare an appetite before any exposure can be called acceptable — it never defaults to assuming a reading is within tolerance.
What does Centriu Oracle cost?
It is sold by subscription with a published starting price — exact current values are on the central pricing page.
See how Centriu Oracle scores risk criticality and confidence separately
Reach our commercial team directly, or leave your details below — we'll follow up with guidance for your case.