22 de maio de 2026 · 7 min · Carol
Como calculamos o risco em R$/ano (ALE) — fórmula, tabela e exemplo
A nota A–F responde "como está minha postura?". O ALE responde "quanto isso custa por ano?". Mostramos a fórmula, a tabela calibrada e um exemplo numérico real — com os números que você precisa preencher pra ativar.
Every ASM tool answers "how is my posture?" with a technical grade, CVSS score or finding count. None of them walks across the threshold of the boardroom. "We have 12 highs" doesn’t unlock remediation budget.
What unlocks it is "this costs $X per year if we don’t fix it." That number is called ALE — Annual Loss Expectancy. This post explains how Sentinela computes it, shows the raw formula, walks through a numeric example, and lists what you need to fill in for it to come off zero.
The formula in one line
Total ALE ($/year) = downtime cost + breach risk
Two legs. Independent. Each defensible on its own. The total is the sum — no magic weight, no hidden multiplier.
The difference from the rest of the market lives in leg 1: we use real uptime data from your domain, not industry benchmarks. That’s why it only makes sense with uptime and security on the same platform. EcoTrust, GAT, Unxpose — they do security. They don’t have your incident history.
Leg 1 — Downtime cost
downtime_cost = observed_incident_hours_365d × revenue_per_hour
In prose: we sum the duration of every incident the Uptime monitor linked to the target recorded over the last 12 months, and multiply by the revenue per hour you declared.
Two inputs, both yours:
| Field | Where you fill it in | What it is |
|---|---|---|
| Linked Uptime monitor | Target form (Security) | Which monitor is the "thermometer" for this asset. We auto-suggest when the host matches. |
| Revenue per hour | Same form | How much this asset loses per hour offline. |
If you don’t link a monitor, this leg stays at $0. We don’t guess. We don’t use an industry benchmark like "average retail loses $X". The number has to be yours to be defensible to leadership.
How to size revenue_per_hour if you don’t know it offhand? There’s a whole post with a calculator at how much one hour of downtime really costs. Spoiler: it’s usually 3 to 5× pure lost revenue once you add wasted CAC, penalized SEO and overloaded support.
Leg 2 — Breach risk
breach_ale = probability(risk_tier) × impact
impact = (lgpd_exposure + incident_recovery_cost) × reputation_factor
This leg is the classic actuarial ALE: probability times impact. The difference is where each term comes from.
The probability table
Annual incident probability comes from the target’s risk tier in its last audit (output of the contextual score: technical grade + business criticality + KEV/EPSS threat intel). Calibrated table:
| Asset risk tier | Annual probability |
|---|---|
| Low | 2% |
| Medium | 8% |
| High | 20% |
| Critical | 40% |
Why those numbers? Calibration based on public literature (Verizon DBIR, Ponemon reports) tuned to the scope of what an external audit observes. It’s opinable — which is why the table is an explicit constant in code, not a hidden neural net. If you have industry-specific data, we can discuss. But the ruler has to be the same across targets for comparisons to mean anything.
The impact inputs
Three fields you fill in once per workspace under Settings → Financial risk:
| Field | What it is | How to size |
|---|---|---|
lgpd_exposure |
What an applicable regulatory fine would cost this business | LGPD goes up to 2% of revenue, capped at ~R$ 50M per infraction. Use 5–50% of that as a reasonable estimate. |
incident_recovery_cost |
IR cost (forensics, crisis comms, recovery downtime) | Cyber-insurance coverage usually quotes R$ 50k–500k for SMB, R$ 1M+ for mid/large. |
reputation_factor |
Reputation-damage multiplier (0–N) | Well-known DTC e-commerce: 1.5–2.0. B2B SaaS with contractual SLAs: 1.5. Internal app: 0.5–1.0. |
Why you fill these and not us? Because the one who knows the business is you. Leg 1 is objective (our data). Leg 2 is your view of your impact. Transparency beats false precision.
Full worked example
Fashion e-commerce. Configuration:
- Uptime monitor: 6h12 of incidents over the last 365 days
- Declared revenue/hour: R$ 12,000
- Last audit: grade C, business criticality high →
risk_tier = high - Settings → Financial risk:
lgpd_exposure: R$ 50,000incident_recovery_cost: R$ 80,000reputation_factor: 1.5
Calculation:
Leg 1 — downtime
downtime_cost = 6.2h × 12,000 = R$ 74,400
Leg 2 — breach
impact = (50,000 + 80,000) × 1.5 = R$ 195,000
probability = 0.20 (high)
breach_ale = 0.20 × 195,000 = R$ 39,000
Total ALE = R$ 113,400/year
That’s the number that goes to the board meeting. Not "12 highs open" — R$ 113,400/year of expected exposure if nothing is done.
What changes when you fix things
Each axis moves differently:
- Fixing a critical finding → drops the technical grade penalty → drops leg-2
risk_tier→ probability table moves 1–2 steps → breach_ale falls to a fraction of what it was. - Linking the uptime monitor (if not yet linked) → leg 1 leaves $0 and becomes honest.
- Reducing real downtime (HA, better deploy, CDN) → fewer hours in the 365-day window → leg 1 drops.
- Raising
reputation_factor(big new client, tougher SLA) → leg 2 rises — you adjust the number to reality.
And the A–F technical grade stays untouched. By design. Technical grade is the comparison ruler between targets; financial risk is the prioritization ruler. Parallel axes, deliberately.
Threat intel still scales probability
Detail many people miss: if the last audit detected a finding with a CVE listed in CISA KEV (catalog of vulnerabilities under active exploitation) or EPSS ≥ 0.5 (high probability of exploitation in the next 30 days), risk_tier automatically goes up one notch.
In practice this means: a medium target with a KEV finding becomes high instantly — and breach_ale jumps from 8% × impact to 20% × impact. 2.5× the previous number, with no human action.
It’s the translation in dollars of "this isn’t theoretical, it’s being exploited right now".
The aggregated workspace view
Each target’s number sums to the workspace view. For an agency or team managing 30 clients, that becomes:
Aggregated portfolio exposure: R$ 2,847,000/year across 14 audited assets.
That’s the number leadership sees. When you drill in, you see which targets contribute the most — and which fixes have the highest dollar-removed-per-effort.
Where this lives in the product
- Security/Show card — target exposure (leg 1 + leg 2 split + total).
- Workspace dashboard — aggregate, with top contributors.
- Weekly report — exposure diff (up/down since last week).
- Audit PDF — the number appears in the report you hand to clients / leadership.
How to switch it on now (3 minutes)
- Settings → Financial risk — enable, fill LGPD/recovery/reputation. Once per workspace.
- Security → edit target — fill "Revenue per hour" and select the linked monitor (auto-suggested when the host matches). Per target.
- Run an audit (or wait for the weekly one). The number appears on the card.
If you already have an Uptime monitor for the same domain, we’ll pre-select it when you edit the target. If you don’t, create the monitor first — without it, leg 1 stays at zero and the moat becomes half of what it could be.
Why this only makes sense here
Every ASM tool can compute leg 2 (probability × impact). Some even try to estimate leg 1 by guessing "e-commerce sites lose on average $X/hour". But none of them has your incident history for the last year — because none of them is also your uptime tool.
We are. That’s why the number shows up. It’s not an industry estimate — it’s your spreadsheet.
To understand why the A–F technical grade doesn’t receive financial context (and why that’s a design decision, not an oversight), read pentest vs continuous auditing. To size revenue_per_hour if you don’t know it offhand, go to how much one hour of downtime really costs.
Continue lendo