Skip to content
The Cyber Security Place

Reference

Security calculators: the assumption is the answer

The multiplication is never the hard part. Every figure these things produce rests on one or two inputs nobody can verify, and the interesting question is which ones — because everything else on the form is decoration.

Last reviewed August 25, 2026

A calculator in this field is an argument wearing arithmetic: the sums are trivial and the assumptions carry the result. In a typical incident cost model, varying days of disruption across a defensible range moves the answer further than every other input combined, and it is usually presented as a plain field with a sensible-looking default. Vendor tools are rarely wrong arithmetically and reliably favour buying, because whoever chose the defaults had an interest and defaults are what most people submit. There is no single breach cost: published averages differ by an order of magnitude depending on what was included. The test of a tool is whether every input is visible and adjustable. These 32 state what they assume, and work without JavaScript.

What is a calculator actually for?

Not for producing a figure. For making somebody state a belief out loud, at which point it becomes possible to disagree with them.

Consider the conversation these things replace. Somebody says an outage would be expensive, somebody else says the fix is expensive, and both are correct in a way that leads nowhere because neither has said a number. The calculator's real function is to force the first person to commit to a duration and the second to a cost, after which the disagreement is about something specific.

That reframing changes what a good one looks like. If the point were the output, precision would matter and hidden sophistication would be a virtue. If the point is the argument, then every input must be visible and adjustable, because the adjustment is the conversation. A tool that produces an impressive figure from fields you did not choose has removed the only useful thing it does.

It also explains why a calculator is worth building for a decision that has already been made emotionally. Writing down the assumption that made the answer obvious is how you find out whether it survives being written down — and a surprising proportion do not.

Which input carries the result

Vary each input of a typical incident cost model across a range you could defend, and see how far the answer moves.

Days of downtime+148%Whether backups restore+96%Revenue per day+41%Staff cost per hour+14%Notification and legal+11%Forensic engagement+7%how far the answer moves when one input varies

One bar is wider than the three below it put together. In nearly every incident cost model the duration of disruption dominates, because it multiplies through everything else: lost trading, staff time, contractual penalties, the temporary arrangements that keep a business running. Change it from two days to five and the total does not rise by half, it more than doubles.

That bar is also, almost always, the field with the least discussion behind it. It arrives as a number somebody chose because it looked reasonable, sits between two fields that have been argued over, and carries the result. If a meeting has an hour for a cost model, fifty minutes belong to the top bar.

The narrow bars at the bottom deserve a word, because they attract effort out of proportion to their influence. Forensic engagement costs and notification expenses are knowable, quotable and satisfying to research, and getting them exactly right changes the total by a rounding error. Precision is worth spending where the sensitivity is, and almost nowhere else.

Why do vendor calculators always favour buying?

Not by cheating on the arithmetic, which is usually correct and checkable. The conclusion is set in the defaults.

Every field arrives pre-filled, because an empty form is abandoned. Somebody chose those values, that somebody works for the company selling the remedy, and research on every kind of form shows that most people submit the defaults with at most one or two changes. The output is therefore mostly a function of decisions made before you arrived, presented as a calculation you performed.

Two other mechanisms recur and are worth recognising by sight. Some inputs are absent altogether — the ongoing cost of operating the thing, the staff time to tune it, the migration off whatever it replaces — and an omitted cost is a cost set to zero. And the benefit side is frequently expressed as a percentage reduction in a loss you have not established you would have suffered, which multiplies an assumption by an assumption and reports the product as a saving.

None of this requires anybody to be acting badly, and the tools are often genuinely useful for structuring a first estimate. The correct use is to take the model, put your own numbers in every field including the ones nobody asked about, and notice how far the answer travels. If it still supports the purchase, that is now a real finding rather than a marketing artefact.

What does a breach actually cost?

There is no single figure, and quoting one without saying what it contains is the commonest error in this whole field.

Published averages differ by an order of magnitude, and the variation is almost entirely definitional rather than empirical. A narrow figure counts direct response: the responders, the overtime, the notification, the legal advice. A wide one adds lost business, reputational damage modelled from share price movements, customer churn attributed to the event, and staff time valued at salary. Both are defensible and they are not the same measurement.

The distribution is worse than the averages suggest. Most incidents cost very little and a small number cost enormously, so the mean sits well above what a typical organisation would experience and describes almost nobody. Quoting an average as though it were a forecast for your next incident is a statement about the tail dressed as a statement about you.

What works better is asking a narrower question with a checkable answer. Not what a breach costs, but what a week without a specific system costs — which finance can estimate, which is about your organisation, and which feeds directly into the input that the chart above says carries everything.

How should a calculator be read?

Four steps, in order, and most tools fail before the third.

Find the dominant input. Change one field at a time and watch the output. The one that moves it most is the model; everything else is presentation. This takes two minutes and is the whole exercise.

Decide whether you believe that number. Not whether it is plausible — whether you would defend it in front of somebody who disagreed. If you would not, the output is not usable and no amount of care elsewhere rescues it.

Look for what is missing. Ongoing operation, staff time, the cost of leaving, what breaks during migration. An omitted field is not a neutral simplification; it is a value set to zero by somebody who benefits.

Run the range, not the point. Put in your low and high figures for the dominant input and read both answers. If the decision is the same at either end, you have finished and precision was never needed. If it flips, you have found the thing actually worth investigating, which is a better outcome than a single number would have given you.

Is return on investment the right frame?

Rarely, and the reason is structural rather than a matter of doing the sums better.

A return requires a gain, and the gain here is an absence: incidents that did not occur. Absences cannot be counted, and the standard workaround — multiply an industry loss figure by an assumed reduction percentage — chains two unverifiable numbers and presents the product as a saving. That is not a measurement with error bars; it is a construction whose output is determined by the inputs somebody chose.

The frame that survives contact with a finance function is exposure rather than return. What would this specific failure cost us, how often might it happen, and what does closing it cost. All three are estimable, the first two badly and the third precisely, and the comparison remains meaningful even when the first two are wide ranges.

There is also a category of spending where any financial frame is the wrong instrument and pretending otherwise wastes everybody's time. Regulatory obligations are not optional, and backups are not a return-generating investment — they are the condition under which the organisation continues to exist. Trying to justify those with a calculator produces bad arithmetic in service of a decision that was never going to turn on it.

Estimating when you have nothing to go on

The usual objection to all of this is that the organisation has no data, which is true and less disabling than it sounds.

Start with what somebody in the building already knows. Finance can estimate a day without the ordering system. Operations know how long the last unplanned outage lasted, whatever caused it. Support know how many people call when a particular thing breaks. None of that is a security metric and all of it feeds the input that matters most.

Then estimate in ranges wide enough to be honest. A confident interval that spans a factor of three is more useful than a point estimate that is precisely wrong, because it can be narrowed later and because it survives scrutiny. People consistently underestimate how wide their genuine uncertainty is, and a range that feels uncomfortably broad is usually about right.

Then check whether the width matters. Most decisions turn out to be insensitive to precision: you rarely need to know whether an outage costs two hundred thousand or six hundred thousand to know it exceeds the cost of the backup arrangement that would prevent it. Where the decision does flip inside the range, you have located the one thing worth measuring properly, and that is a far better use of a week than measuring everything.

The classic formula, and where it breaks

Almost every quantitative model in this field is a variation on one expression: expected annual loss equals what a single occurrence costs, multiplied by how often it happens. It is decades old, it appears in every syllabus, and it is worth understanding precisely — including its two failure modes, which are not the ones people usually name.

The first failure is not that the frequency is hard to estimate, though it is. It is that the expression returns an average, and averages describe populations rather than organisations. An event costing five million pounds once a decade has the same expected annual loss as one costing five hundred thousand every year, and those two situations demand completely different responses. One is a solvency question and the other is a budgeting question, and the formula flattens the difference.

The second failure is that both terms are usually estimated from the same source, which makes their errors correlate. If the figure you used for cost came from a report that also supplied the frequency, an optimistic methodology has moved both numbers in the same direction and the product is wrong by more than either input. Independent errors partly cancel; correlated errors compound.

What the expression is genuinely good for is comparison rather than prediction. Two risks estimated with the same flawed method, by the same person, on the same afternoon, can be ranked against each other with reasonable confidence even when neither absolute figure means much. Use it to decide which of two things to do first, and stop before using it to decide what the year will cost.

Taking a range to people who wanted a number

The usual objection to everything above is practical: a board asked for a figure and will not accept an interval. That objection is real and mostly solvable by presentation rather than by abandoning the honesty.

Lead with the decision, not the estimate. The sentence that lands is we recommend spending this, because the alternative costs somewhere between these two figures. The range appears as support for a recommendation rather than as a request for somebody else to interpret it.

Name the input that decides it. One sentence: this turns on how long we would be down, we have assumed four days, and here is why. That invites the challenge you want and forecloses the challenge you do not, which is a general question about where any of the numbers came from.

Show that the decision holds at both ends. Where it does, say so and the range stops being a weakness. Where it flips, that is genuinely the most important thing in the paper, and burying it under a point estimate is the failure the whole exercise exists to prevent.

Bring the arithmetic and offer it. Nobody will check, and having it changes the register of the conversation from persuasion to examination. The willingness to be checked is doing the work, not the checking.

Directors are, in general, considerably more comfortable with uncertainty than security teams expect. They spend their working lives making decisions on estimates with wide intervals. What they react badly to is not a range but a figure that turns out to have been a range wearing a disguise, discovered later — which is the outcome the single confident number reliably produces.

The tools on this site

32 of them, 29 producing a figure. Each states what it assumes, produces the same answer from the same inputs, and serves its full argument without scripting.

Building one that is worth using

Five properties, and the last is the one most tools miss.

Start from the decision, not the data. A calculator exists to inform a choice somebody is about to make. If you cannot name the choice, you are building a dashboard.

Expose the input that dominates, prominently. If duration decides the answer, duration belongs at the top with room to argue about it, not buried between two fields that change nothing.

Refuse fields that do not move the output. Every additional input makes the thing look more rigorous and less usable, and a field that changes the answer by one per cent is there to impress rather than to inform.

Make it deterministic. The same inputs must always give the same answer. Anything with randomness cannot be checked by the person reading it, and a figure nobody can reproduce is not a figure.

Write down what you assumed, where the reader can see it. Not in a methodology note nobody opens — beside the result. This is the property that separates a model from a claim, and it is the one almost universally omitted, because stating an assumption invites disagreement and disagreement is what the thing was built to avoid.

Common questions

What is a security calculator actually for?

Making an assumption visible and arguable. The arithmetic is trivial; the value is that a number forces somebody to state what they believe about downtime, probability or cost, at which point it can be disagreed with. A calculator that hides its inputs has removed the only useful thing it does.

Why do vendor calculators always favour buying?

Because the defaults were chosen by somebody with an interest in the result, and defaults are what most people submit. The arithmetic is usually sound and the conclusion is set before you arrive, in fields you were not invited to think about.

Which input carries the result?

In almost every incident cost model, the duration of disruption. Vary it across a defensible range and the answer moves further than every other input combined, which is why it deserves the argument and rarely gets it.

What does a breach actually cost?

There is no single number, and quoting one without saying what it includes is the commonest error in this field. Published averages vary by an order of magnitude depending on whether they count only direct response or add lost business, modelled reputational damage and staff time at salary.

How should a calculator be read?

Find the input that moves the answer most, decide whether you believe that number, and treat everything else as decoration. If that input is not visible or not adjustable, the tool is an argument rather than a model.

Is return on investment the right frame for security?

Rarely, because the return is an absence and absences cannot be measured. Cost of exposure works better: what would this specific failure cost, how likely is it, and what does removing it cost. That reframing keeps the argument about things somebody can actually estimate.

What do you do when you have no data?

Estimate ranges rather than points, state them, and act on the ones where the range does not change the decision. Most choices are insensitive to precision — you rarely need to know whether something costs £200,000 or £600,000 to know it costs more than the fix.

What makes a calculator trustworthy?

Every input visible and adjustable, the formula stated, the assumptions named, and the same inputs always producing the same answer. Anything with hidden fields, undisclosed multipliers or randomised outputs is presenting an opinion with a decimal point.

Should these numbers go in a board paper?

With the range and the driving assumption alongside, yes. A single figure invites the question of where it came from, and the honest answer is a better conversation than the figure was. Present the range and name the input that decides it.

Do the tools on this site need JavaScript?

No. Each one serves its full argument as text and tables, and the interaction adds a shortcut rather than the content. Anything that only works with scripting is unavailable to a reader, a search engine and an archive at the same time.

Are any of these figures measurements of your organisation?

None of them. Each tool states what it assumes, and several are explicitly illustrative of a shape rather than derived from a survey. They are instruments for thinking about a problem, not for reporting on your estate.

How do you build one that is worth using?

Start from the decision it should inform, expose the input that dominates, refuse to add fields that do not change the answer, and write down what you assumed where the reader can see it. Most calculators fail on the last of those.