Translating Breach Risk Into Numbers Executives Trust

"It's a security risk" is the sentence administrators reach for first. It is also the sentence budget holders have learned to hear as background noise. This is not because they do not care. It is because the sentence contains no number, no scenario, and no way to compare it with the other seven risks on their desk. Executives deal in risk all day: fire, fraud, a supplier going under, a key person leaving. What they are not comfortable with is a risk described as a feeling.

The translation is not complicated, and it does not require you to invent a figure. It requires two words, likelihood and impact, and a habit of using ranges instead of single numbers. It also requires one concrete scenario drawn from your own estate rather than from a survey. By the end of this article you will be able to write a one-card risk scenario. A finance director can read it in ninety seconds, argue with it fairly, and put it next to the cost of fixing it. The article is part of our Business Case series and feeds directly into the one-page business case.

Likelihood and Impact, in Plain Words

Likelihood is how often you expect a particular bad thing to happen. It is stated in words a person can picture: "about once a year," "once every few years," "less than once in ten years." Impact is what it costs when it does happen. It is stated as a range: "tens of hours," "hundreds of hours plus a partner penalty," "a regulator's letter and a week of the finance team." A risk, for our purposes, is the pair. Not a score, not a product of the two, just the pair, written side by side.

Why not multiply them into one number? Because the multiplication hides the part the reader needs. "Expected loss of forty hours a year" could mean a monthly nuisance or a once-a-decade catastrophe, and those deserve different responses. A finance director reads a pair and immediately knows which kind of problem it is. A single number makes them ask. Then you are explaining arithmetic instead of risk.

The pair also matches how the rest of the business already thinks. Insurers price policies on likelihood and impact. The fire risk assessment by the kitchen is a likelihood and an impact. Describe a transfer risk the same way and you are speaking a language the room learned years ago. Describe it as "critical" and you are speaking a language only IT uses, and IT rates everything critical. (Ask any help desk.)

One more definition: a control is anything that changes the likelihood or the impact. Encrypting a connection lowers the likelihood that a credential is captured in transit. Giving each partner its own login lowers the impact when one leaks, because only one partner's files are exposed. Your budget request is, at bottom, a request to buy a control. The case for it is the difference between the pair before and the pair after.

Why Ranges Beat Point Estimates

A single number invites an argument about the number. Say "a leaked supplier password would cost us four hundred hours" and the first question is "why four hundred?" The meeting is now about your arithmetic. Say "between two hundred and six hundred hours, and here is what sits at each end." The reader can agree with the bounds without agreeing with any point inside them. Agreement on bounds is usually all a decision needs.

Ranges are also more honest, and readers can tell. Nobody knows what a breach will cost to the hour. Pretending to know signals that you either have not thought hard or hope they will not look. I have watched a case survive a hostile question purely because of what the presenter could say. "The low end assumes we notice within a day; the high end assumes the partner notices first." The questioner nodded.

Use bands rather than free-form ranges, so that every scenario in the case shares a vocabulary. The table below is the set I use. Impact is in hours because hours are the unit you can defend from your own records. Finance converts them to money using the loaded hourly rate. That is the cost of one hour of a person's time including salary, tax, benefits, and overheads. Finance already has that rate, and you do not need to guess.

Notice what the impact column refuses to do: it never quotes a currency figure, and it never cites a study. Industry surveys consistently put the average cost of a serious breach in the millions. That sentence, in that deliberately vague form, is the only version you should ever use. Say "the average breach costs X, according to a report," and the finance director will ask which report. They will ask whether it covers organizations your size and why its number applies to you. Every one of those questions is fair.

The Grid

Once each scenario has a likelihood band and an impact band, it has a position on a grid. A grid is something a busy reader can take in at a glance. The diagram below is the grid with three of Meridian Parts' transfer scenarios placed on it. They are the shared supplier password leaking, a price file silently failing, and an order file sent to the wrong dealer. The arrow shows where the leaked-password scenario moves once each supplier has its own login and sessions are logged.

The shaded corner is where cases get funded, and the point of the grid is not to put everything there. It is to show, honestly, which of your scenarios are there and which one your request moves. A grid with every scenario in the top-right is a grid nobody believes. A grid with one scenario there and a clear arrow out of it is a decision waiting to be made.

Scenario-Based Reasoning

A scenario is one specific story of one specific flow going wrong. It is told from the moment it happens to the moment the last consequence lands. It is built from your own estate, not from a headline. It is the most persuasive object in a risk case because a reader can picture it.

1. Pick a flow you can name in business terms. "The supplier price file," not "job 17." The case needs to say what the file carries and who depends on it.
2. Pick one way it goes wrong. A credential leaks, a file is sent to the wrong partner, a job fails silently, a connection is intercepted, an insider copies the outbox. The catalog of ways is in common transfer attacks. The method for walking a single flow through them is threat modeling a transfer workflow. One scenario per card; resist the urge to stack them.
3. Walk the timeline. When does it happen, when is it noticed, and by whom? What must be done to contain it, to tell the people who must be told, and to recover? Who outside IT is pulled in, for how long?
4. Estimate hours per stage, as a range. Low end assumes you notice quickly and the damage is narrow; high end assumes the partner or the regulator notices first. Write the assumption next to each end.
5. Assign a likelihood band, and say why. "Likely, because the same password has been in use for four years, is known to six people at four suppliers, and travels unencrypted every night." The "because" makes the band defensible.
6. Name the control and re-place the scenario. Which band does it move to, and why? Say what the control does not fix.

If your estate has not had a serious incident yet, borrow the shape of one. Our war stories series exists partly for this. Stories such as the leaked credential and the misdirected file are told with timelines you can map onto your own flows. Replace the fictional organization with your own and estimate your own hours at each step. That is a scenario, and it is honest, because every hour in it is yours.

Template: The Risk Scenario Card

The card is one screen, one scenario. It goes in the appendix of the business case; one line from it goes on the one-pager. Fill in every field, because a blank one reads as a field you did not think about.

RISK SCENARIO CARD

Scenario:          [one sentence: what goes wrong, to which flow]
Flow carries:      [business content, who depends on it, cutoff]
Trigger:           [how it starts]
Noticed by:        [who, and how long after]  Low: [ ]  High: [ ]
Timeline:          [contain] -> [notify] -> [recover] -> [follow-up]
Hours, low end:    IT [ ]  Business team [ ]  Senior [ ]  Assumes: [ ]
Hours, high end:   IT [ ]  Business team [ ]  Senior [ ]  Assumes: [ ]
Other consequence: [partner penalty / notification duty / lost contract / none]
Likelihood today:  [band], because [evidence from your own estate]
Impact today:      [band]
Control proposed:  [what, in one line]
Likelihood after:  [band], because [what the control changes]
Impact after:      [band], because [what the control changes]
Not fixed by this: [what remains, honestly]
Outsider's words:  [insurer / auditor / partner sentence that refers to this]

Filled in for Meridian Parts' shared supplier password, the card looks like this. Every hour figure is a range with its assumption, and the likelihood has a reason a reader can check.

RISK SCENARIO CARD: MERIDIAN PARTS, SHARED SUPPLIER PASSWORD

Scenario:          The single password shared by four suppliers for the price-file
                   service is obtained by someone outside those suppliers.
Flow carries:      Supplier price lists and our purchase orders; purchasing and the
                   warehouse depend on it before 06:00 daily.
Trigger:           Captured on the unencrypted connection, reused from a supplier's
                   own breach, or kept by a supplier's ex-employee.
Noticed by:        Low: our review of the log within a week.
                   High: a supplier tells us their orders were read, months later.
Timeline:          Reset and re-issue to four suppliers -> check what was read or
                   altered -> tell affected suppliers -> re-verify prices.
Hours, low end:    IT 40  Purchasing 30  Senior 10   Assumes: noticed in a week,
                   nothing altered, no external notification needed.
Hours, high end:   IT 200  Purchasing 250  Senior 120  Assumes: a supplier notices
                   first, altered orders shipped, contractual notification to all.
Other consequence: Possible penalty under two supplier contracts; loss of a
                   preferred-supplier discount at worst.
Likelihood today:  Likely. Same password for four years, known to at least six
                   people at four companies, sent unencrypted every night.
Impact today:      Major.
Control proposed:  Encrypted service; one login per supplier; per-session logging;
                   password rotation on supplier staff changes.
Likelihood after:  Rare. No shared secret to leak; nothing crosses the wire in the
                   clear; a leaked login exposes one supplier's files only.
Impact after:      Minor. Reset one login, tell one supplier, read one log.
Not fixed by this: A supplier's own systems being compromised; a wrong file
                   being sent by a correct login.
Outsider's words:  Auditor: "supplier files are exchanged over an unencrypted
                   service using a credential shared by multiple parties."

Look at the "Not fixed by this" line. It is the one administrators most want to leave blank and the one that does the most work. It tells the reader you are describing a control rather than selling a cure.

What Insurers and Auditors Already Ask

You do not have to invent the questions. Two outsiders your organization already pays have written them down, in language the budget holder accepts. Both sets of questions are sitting in someone's inbox.

The cyber-insurance questionnaire is the form your insurer sends at renewal. Somewhere on it are questions like "Is data encrypted in transit?" and "Do all external parties authenticate with unique credentials?" Another is "Are access logs retained and reviewed?" Each question is the insurer telling you what they think moves likelihood. If the honest answer for your transfer estate is no, that is a sentence for the card. For example: "Our insurer asks whether all external parties use unique credentials; for four suppliers the answer is no." Nobody will argue with the insurer's list, and the finance team usually filled in the form last time. (Ask them how it felt.)

The auditor's letter is the other source, and it has its own article, turning audit findings into budget language. For the card, the point is simpler. An auditor's sentence about the flow you are describing is the strongest support your likelihood band can have. It was written by someone with no interest in your budget. Quote it exactly.

We make transfer software, so read the next sentence with that in mind; the method works whatever you buy or build. The control that moves a leaked-credential scenario is a service that encrypts the connection, gives each partner its own login, and logs every session. That can be a commercial server such as Sysax Multi Server, which does those three things over SFTP, FTPS, and HTTPS. It can also be an open-source SFTP daemon configured carefully, or the existing server with its settings fixed. The card does not care which; it cares that the "after" bands are earned by a control that does what the line says.

The Honesty Rules

The numbers in a risk case are credible only as long as every one of them can survive a hostile question. These are the rules that keep them that way.

• Never quote a statistic you cannot source to the reader's satisfaction. The vague form ("surveys consistently put it in the millions") is allowed. A precise figure from a named study is not, unless the reader can read the study and it plainly covers organizations like yours. Made-up statistics presented as research end careers, and they should.
• Ranges, with a reason at each end. A range without assumptions is a guess with wider error bars.
• Put your assumptions where the reader can change them. If the finance director thinks purchasing would spend half the hours you wrote, let them halve it. Then let them see that the case still stands. A case that only works with your assumptions is not a case.
• Count each hour once. The hours in the scenario card are incident hours. The hours in the operational-cost worksheet are routine hours. If the same afternoon appears in both, the reader will find it.
• Say what the control does not fix. Every time.
• Include the boring outcome. "Likely" means about once a year, which means most days nothing happens. Say so. A reader who has heard "this could happen tomorrow" for three years stops listening. A reader who hears "roughly once a year, and it has not happened yet" hears a person who understands probability.

Northgate Retail's IT manager learned rule one in a single meeting. His case for replacing a shared-credential FTP drop opened with a breach-cost figure lifted from a vendor's slide deck, quoted to the nearest thousand. The finance director asked where the number came from, then whether the survey covered retailers of Northgate's size. Then came the question of whether any of the surveyed breaches involved file transfer at all. He did not know. The case was parked, not because the risk was unreal, but because the first number in it was somebody else's. After that none of his own were trusted either. The rewrite, six months later, opened with hours from Northgate's own incident log and was approved.

Putting It on the Page

The card is the appendix. On the one-pager, the scenario becomes a single line: the name, the pair today, the pair after, and the outsider's sentence. For Meridian Parts: "Shared supplier password leaks: likely and major today; rare and minor with option two; already noted by the auditor." That is the whole risk argument as the decision-maker will read it. It is enough, because the card behind it can answer any question the line raises.

Risk is one of three legs the case stands on. The second is the routine cost of failures and manual work, which the next article turns into a year of hours from your own logs. The third is what the auditor has already written. The one-page business case shows the three legs combined. The article why nobody funds file transfer explains why the case has to be written on a quiet Tuesday rather than the morning after. For the deeper method behind likelihood bands, see transfer risk assessment. For the risks that appear in no inventory because users built their own workaround, the shadow file sharing series is where they hide.

Frequently Asked Questions