How to estimate ARO when you have no incident data
You estimate the annual rate of occurrence the same way a hydrologist estimates a flood: start from a population base rate you did not invent, adjust it with a small number of factors you can defend in writing, and report the result as a band rather than a figure. For a business with no incident history the practical recipe is sector base rate × three to five explicit multipliers, sanity-checked as a “1 in N years” statement. The worked example below takes a 41-person accounting practice from a base rate of 0.25 to an ARO of 0.331 — about one breach every three years — and then shows what that rate is worth in dollars. Feed the result into the annual loss expectancy calculator; the rest of the ALE model is covered in annual loss expectancy explained.
Why the rate is the input that breaks the calculation
Annual loss expectancy is a product of two terms, and it is linear in both: ALE = ARO × SLE. That symmetry hides an asymmetry in how well the two terms are known. The single loss expectancy can be modelled from published per-record costs, component shares and your own record count — imperfect, but anchored in reported data and reproducible by anyone with the same inputs. The rate has no such anchor for an individual business. Most small firms have never had a reportable breach, which means their own history contains no observations of the event they are trying to count.
Because ALE is linear in the rate, the consequence is direct: a room that disagrees three-to-one about the rate disagrees three-to-one about the security budget. And unlike a disagreement about cost, which can be resolved by pointing at a benchmark, a disagreement about the rate tends to be resolved by whoever is most senior. That is the failure mode this guide exists to prevent. A rate built from a stated anchor and stated multipliers can be argued with on its merits; a rate someone simply asserts cannot.
There is also a trap in the absence of incidents itself. A clean five-year record feels like strong evidence of a low rate, and it is not. If the true rate is one in four years, the probability of seeing nothing at all across five years is around 24% — roughly one business in four with that exact risk profile will have a spotless history purely by chance. Treating that silence as proof of safety is the statistical equivalent of concluding a coin is weighted after four tails.
Step 1: name the event before you count it
The single largest source of disagreement about frequency is not the number; it is that two people are counting different things. “Security incident”, “intrusion”, “data breach” and “reportable breach of personal information” describe a nested set of events whose frequencies differ by an order of magnitude or more. A managed-service provider reporting dozens of “incidents” a year and a compliance lead reporting zero “breaches” can both be right, and the ALE built on either number will be wrong if the loss figure was modelled against the other.
So write the event down as one sentence, and make it the event whose cost you actually modelled. If your SLE came from a breach-cost model that assumes notification, credit monitoring and lost business, then your event is a confirmed breach of personal information requiring notification — not a blocked phishing email, not a malware detection, not a suspicious login. The base rates in the breach frequency by sector dataset are drawn from breach incidence rather than incident volume, which is what makes them the right anchor for that event and the wrong anchor for a broader one.
Step 2: anchor on a rate you did not invent
Start from your sector’s published incidence. The breach probability calculator carries indicative annual rates derived from the industry breakdown in the Verizon Data Breach Investigations Report, which analyses tens of thousands of incidents and confirmed breaches each year and splits them by industry. Those rates cluster between roughly 20% and 32% a year depending on sector.
Anchoring matters for two reasons beyond accuracy. The first is that a published base rate moves the argument from “what do you think?” to “why should we differ from the sector?”, which is a far more productive question and one that has answers. The second is calibration: the risk-assessment guidance published by the NIST Computer Security Resource Center and the quantitative literature maintained by the FAIR Institute both treat base rates as the correction for a known human bias — we estimate frequencies from how vivid or recent an example feels, not from how common it is. Somebody who read about a ransomware case last week will estimate high; somebody who has never seen one will estimate low. The base rate is the fixed point that keeps both from running away.
Two honest limits on the anchor. It describes an average organisation in your sector across a wide range of sizes and maturities, so it is a starting point rather than a verdict. And it is a rate for organisations that were observed, which skews towards those with the ability to detect a breach at all — a consideration that argues against adjusting far downwards just because you have never noticed anything.
Step 3: adjust only for what changes frequency
Now apply a short list of multipliers. The discipline that makes this defensible rather than decorative is a single rule: adjust the rate only for factors that change how often the event starts, and leave everything that changes how bad it gets to the loss side of the equation.
| Factor | Affects | Why |
|---|---|---|
| Phishing-resistant authentication on systems holding the data | ARO | Removes the most common initial access route, so fewer incidents start |
| Security-awareness training | ARO | Reduces the click-through that begins an intrusion |
| Number of third parties with access to the data | ARO | Each integration is an additional way in, none of which you control |
| Encryption at rest | SLE | Does not stop an intrusion; changes what an intruder can monetise and what you must report |
| Tested, isolated backups | SLE | Does not affect how often ransomware arrives; changes what it costs when it does |
| Rehearsed incident-response plan | SLE | Shortens containment, which is a cost lever, not a frequency lever |
Double-counting across that boundary is the most common defect in a home-made quantitative estimate, and it is invisible in the output. If tested backups shave the rate and the loss, a 10% benefit becomes a 19% benefit through the multiplication, and the control’s apparent return rises accordingly. The security control ROI calculator is only as honest as the discipline applied at this step.
Keep the list short — three to five factors — and size each one modestly. A multiplier of 1.15 or 0.9 is a claim you can defend; a multiplier of 3 is a claim that the sector base rate does not apply to you at all, which is occasionally true and usually not.
A worked example: a 41-person accounting practice
The firm holds 23,600 client records of personal and financial data, has no in-house security staff, runs multi-factor authentication on email but not on the practice-management system where the records actually live, has nine third-party integrations touching client data, and puts every member of staff through phishing training twice a year. It also keeps tested offline backups.
Its sector, professional services, carries an indicative base rate of 0.25 a year. Three adjustments follow, and one deliberate non-adjustment:
- × 1.25 — no second factor on the system holding the records. Credential-based access to the crown-jewel system is the single most frequently exploited route in, and the firm has closed it on email only.
- × 1.15 — nine third-party integrations, above what is typical at this headcount. Each is an independent path to the data whose security posture the firm does not set.
- × 0.92 — twice-yearly phishing training, consistently delivered. A real but modest frequency reduction.
- no adjustment — tested offline backups. They are among the firm’s strongest controls, and they belong entirely in the loss figure. Crediting them here would be the double-count described above.
The product: 0.25 × 1.25 × 1.15 × 0.92 = 0.331, or 33.1% a year — about 1 in 3 years. Stated as a recurrence interval that passes the sanity check: a small practice with unprotected access to a system holding 23,600 financial records, reached through nine integrations, expecting a serious incident every three years is neither alarmist nor complacent.
With a modelled single loss expectancy of $327,000 from the data breach cost estimator, the annual loss expectancy is 0.331 × $327,000 = $108,237 a year.
ALE at SLE $327,000: $108,237 per year
Reported band (×0.65 / ×1.40 on the rate): $70,305 — $151,401
Report a band, and use it to choose
Because the rate is an estimate, carry a low and a high version of it through to the end. Applying a factor of 0.65 and 1.40 to the adjusted rate gives rates of 0.215 and 0.463, and annual loss expectancies of $70,305 and $151,401. The spread of $81,096 is larger than the entire control package the firm is considering, which is not a flaw in the method but its most useful output: it tells the partners that precision about the rate is worth paying for, and that any control whose cost sits below the bottom of the band is worth buying without further analysis.
The band also ranks the fixes. Adding a second factor to the practice-management system removes the × 1.25 multiplier outright, taking the rate to 0.265 and the ALE to $86,655. That is a reduction of $21,582 a year against an annual cost of roughly $4,700 — a return no other item on the firm’s list approaches, and one that was invisible until the rate was decomposed into factors. This is the practical payoff of building ARO from multipliers instead of asserting it: the multipliers are the shortlist of things worth fixing, in order of size.
Three ways an ARO becomes indefensible
Counting incidents and pricing breaches. If the rate came from a monitoring dashboard and the cost came from a breach model, the two terms describe different events and their product means nothing. Align them at step one or the arithmetic is decorative.
Reading a vendor statistic as a base rate. Frequencies quoted in marketing material are usually drawn from a population selected for having a problem, or count attempts rather than breaches. A figure like “most small businesses are attacked every year” is probably true of attempts and irrelevant to the rate of a reportable breach. Anchor on a published incidence study and note where you got it; general-audience guidance from bodies such as CISA is useful for what to do, not for how often it happens to you.
Hiding the adjustment. A rate presented as a single decimal invites a fight about authority. The same rate presented as “sector 0.25, times 1.25 for missing MFA, times 1.15 for nine integrations, times 0.92 for training” invites a fight about the multipliers — which is the fight you want, because it is winnable, revisable and it produces a work list. If your risks are still recorded as colours rather than rates at all, quantitative versus qualitative cyber risk covers the translation first.
Frequently asked questions
What is a reasonable ARO for a small business with no breach history?
Having no breach history is weak evidence of a low rate, because a 1-in-4-years event is absent from a five-year window about 24% of the time by chance alone. The defensible starting point is your sector base rate, which for the sectors in this site’s dataset runs from roughly 0.20 to 0.32 a year, adjusted for the handful of things about your business that genuinely change frequency. A clean history justifies sitting at or slightly below the base rate; it does not justify a rate near zero.
Can ARO be greater than 1?
Yes, and for some loss events it should be. ARO is a rate, not a probability, so an event you expect three times a year has an ARO of 3. That matters because the events worth quantifying are not all rare: a business-email-compromise attempt, a lost or stolen device, or a ransomware attempt on a small fleet can each be multiple-times-a-year events. Rates below one happen to be the common case for full reportable breaches, which is why ARO and probability are so often conflated.
Should I adjust ARO or SLE for a control I already have?
Ask what the control actually does. Phishing-resistant authentication, patching discipline and email filtering change how often an incident starts, so they belong in ARO. Encryption, tested backups and a rehearsed response plan mostly change how bad an incident becomes once started, so they belong in SLE. Applying the same control to both inputs is the most common way a quantitative estimate ends up flattering — it compounds a single benefit twice through a multiplication.
How many multipliers should I apply?
Three to five, each with a written justification. The temptation is to build a scorecard with twenty factors, which feels more rigorous and is less so: every additional multiplier adds judgement rather than information, and a chain of ten factors can swing the result by a factor of five in either direction without anyone noticing. Keep the factors few, keep them large enough to matter, and keep the product visible next to the base rate so the size of your intervention is obvious.
How often should the rate be revisited?
Annually, and on any structural change — a new system holding personal data, a merger, a move into a new customer segment, or an actual incident. The base rate itself changes slowly, so most revisions come from the multipliers rather than the anchor. An incident, including a near miss, is the most informative event: it is real evidence about your own frequency, and it should move your rate more than any published statistic does.
Disclaimer. BreachCostLab provides cost and risk estimates for informational purposes only, based on published industry benchmarks (e.g. IBM/Ponemon Cost of a Data Breach, Verizon DBIR) and publicly available statutory figures as of the verification date shown (Jun 25, 2026). These figures are estimates for planning, not a prediction of the cost of any specific incident, and are not legal, financial, insurance, or compliance advice. Actual breach costs vary widely; for regulatory obligations consult qualified counsel. Always verify current figures with the cited sources.