Referencing what you already know matters when estimating risk in the FAIR model

Outline you can skim before we dive

• Hook: Risk estimation isn’t about guessing; it’s about grounding your numbers in what you already know.

• Core idea: Referencing existing knowledge narrows the range of possible values in FAIR estimates.

• How to reference what you know: historical data, past incidents, industry insights, expert judgment.

• Real-world feel: quick examples (data breach impact, system downtime) to show the method in action.

• Pitfalls to watch: bias, stale data, cherry-picking—and how to avoid them.

• Practical methods: distributions, ranges, and small, transparent assumptions; how to document your reasoning.

• Why it matters for decision-making: clearer conversations with stakeholders, better risk management choices.

• Wrap-up: start with what you already know, and let it guide the rest.

Let’s anchor the estimate with what you already know

When you’re estimating risk in the FAIR framework, you’re not just pulling numbers out of thin air. You’re building a map from what’s already true in your organization—plus a few well-grounded inferences to cover the unknowns. The key move is this: reference what you know to narrow the possible values you might assign to frequency (how often a given risk event could occur) and impact (how bad it could be). Why does that help? Because it reduces guesswork, focuses the conversation, and gives everyone a shared starting point. In short, you’re not stacking guesses; you’re layering informed judgments on top of real-world experience.

Think about it like weather forecasting. A meteorologist doesn’t declare a rainstorm based on a hunch. They lean on past weather patterns, regional data, and current observations to limit the range of possible outcomes. FAIR works similarly. If you’ve seen similar events before—perhaps a prior data breach, a downtime incident, or a third-party disruption—you’ve got data points to calibrate your estimates. If you’ve tracked historical losses or observed how quickly teams recovered in the past, that’s valuable context. Even expert opinions, when gathered from the right people, act like a compass that helps you steer toward a plausible range rather than wandering in uncertainty.

Pulling from your own backyard: how to reference what you know

• Historical data: Start with what your organization has already experienced. How often have you faced outages? What were the losses, and how long did it take to recover? Document these figures and translate them into FAIR terms. If you’ve tracked incidents over several years, you might notice patterns—seasonality, event types, or affected assets. Those patterns are gold when you’re setting a baseline.

• Similar risk events: Look beyond your walls to how peers or within your industry have fared. If the industry saw a certain frequency of breaches or a typical severity range for a particular threat, you can adapt that signal to your context. It’s not about copying someone else’s numbers; it’s about borrowing a credible frame of reference.

• Expert judgment: No data? No problem—yet you still don’t fly blind. Gather input from people who understand your tech stack, business processes, and the risk landscape. A structured approach—like a quick expert panel or a focused Delphi-style question—the right kind of consensus can narrow the range meaningfully. Just be transparent about where that judgment comes from and how it shifts the numbers.

• Known controls and mitigations: If you’ve already deployed specific safeguards, their presence changes the likelihood and impact in predictable ways. Referencing these controls helps you adjust the estimates more accurately than if you ignored them. It also makes your risk picture more believable to stakeholders who rely on those controls.

• Historical severity and recovery data: Sometimes the surprise isn’t the event itself but the cost to recover. If past incidents showed a certain time-to-recovery or a typical remediation cost, you can fold that into your impact distribution. It’s a reminder that FAIR isn’t just about “how bad could it be” but also “how bad is the recovery path likely to be.”

A couple of quick, concrete examples

• Data breach scenario: Suppose your organization has seen a few minor breaches in the past year, with modest data exposure and quick containment. Those experiences let you set a reasonable lower bound for frequency and a capped upper bound for impact, instead of tossing a wide, fear-driven range into the model. You’ll still account for worst-case possibilities—perhaps a more severe event if attacker capabilities evolve—but your starting point isn’t pure speculation.

• System downtime: If historically outages have lasted minutes rather than hours and affect a small portion of users, you can anchor the initial impact estimate around those scales. If new dependencies or a critical system change is planned, you still reference past performance to prevent an overreaction or underestimation, bridging the gap between what’s known and what’s uncertain about the future.

What could go wrong—and how to avoid it

Let me be plain: referencing what you know isn’t a free pass to confident numbers. It’s a way to tighten the frame, not to pretend you’ve solved everything. Here are common traps and practical fixes:

• Bias creep: It’s easy to overweight familiar events just because they’re in front of you. Counter this by using a structured approach to gather data and by testing your assumptions with a small group of diverse voices. If a single pet scenario keeps showing up in your model, question whether you’re unfairly anchoring there.

• Data staleness: Old incidents aren’t useless, but they must be weighed against current realities. If your technology stack or threat landscape has shifted, explicitly flag what’s changed and adjust your estimates accordingly. Fresh data beats nostalgic nostalgia every time.

• Cherry-picking: Don’t only pull the incidents that support your desired outcome. Map the full spectrum of past events, including near-misses and benign incidents. If something looks underwhelming in your data, that might be a signal to widen your range rather than clamp it down.

• Misaligned context: A breach involving a different asset class or business unit isn’t automatically transferable. Always translate past lessons into the right context for your current risk environment. If you’re unsure, bring stakeholders into the conversation to validate the transfer.

A practical toolkit for narrowing the range

• Use ranges, not single points: Rather than a single number, present a plausible interval for frequency and impact. This conveys uncertainty without leaving stakeholders guessing.

• Embrace distributions: If you have enough data, fit a simple distribution (like a beta for probabilities or a log-normal for losses). Distributions reflect uncertainty more honestly than a flat guess.

• Document the chain of reasoning: A short note or diagram that shows how you moved from known data to your estimates helps others trust the numbers. Where did the data come from? What assumptions were made? How did past events influence the bounds?

• Iterate with sensitivity checks: Run a quick pass to see how changing a key assumption shifts the outcome. This isn’t a test of your memory; it’s a sanity check that your range isn’t fragile.

• Tie estimates to controls and business decisions: Show how your range informs risk governance, prioritization, and resource allocation. When leadership sees the link between numbers and action, it’s easier to gain buy-in for risk controls and response plans.

A simple, human way to talk about the idea

Here’s a way to frame it in a real-world chat with teammates or a stakeholder:

• “We’ve seen similar events in the past, so we’re starting with a realistic band for how often this could happen and how bad it could be. Then we adjust as new data comes in or as the threat landscape shifts.”

That kind language keeps the focus on evidence and context rather than “magic numbers.” It also invites collaboration: if someone has a data point that shifts the range, you’re already set up to listen and update.

Why this matters beyond the numbers

When you reference what you know to bound your estimates, you’re doing more than better risk math. You’re cultivating a shared understanding of what matters, where the real uncertainties live, and how the organization can respond with appropriate intensity. You’re turning vague fear into a plan, uncertainty into a strategy, and individuals into a team that can talk about risk in a common language. And that’s what good risk management is really about: making decisions with clarity, not bravado.

A closing thought: start with the facts you already have

FAIR is, at its heart, a practical approach to risk. It recognizes that knowledge—your history, the lessons learned, the insights from people who know the system—has real value. By grounding estimates in what you already know, you narrow the playing field. You focus discussions. You set more realistic expectations. You create a pathway for better decisions, faster responses, and a healthier conversation between tech, business, and leadership.

If you’re building risk judgments, don’t pretend you’re starting from scratch. Start from what you know, map it to the unknowns, and let the range you produce reflect both the certainty you’ve earned and the surprises you still might face. That balance is where FAIR shines—and where risk management starts to feel less like guesswork and more like guided, purposeful planning.