Unknown Unknowns

Not infrequently, we’ll be asked whether FAIR “accounts for” scenarios that are unforeseen. The answer is yes – and no, depending  on what’s meant by “unknown unknowns”. Allow me to explain, starting with the “no” answer and then the “yes”.  


Analyzing Loss Event Scenarios 

First of all, it’s important to remember that FAIR’s foundational design and purpose is to analyze loss event scenarios. That being the case, it is logically impossible to analyze a loss event scenario that you can’t or haven’t foreseen. So FAIR, just like every other analytic method I’ve ever heard of, can’t be used to analyze what hasn’t been conceived of.  

On the other hand, sometimes it isn’t the loss event itself that’s unforeseen (e.g., a database failure), but rather a specific unimagined contributing factor (e.g., that cramming too much electronic circuitry in a small enough space can result in a small wormhole being established, the energy from which disrupts normal database operations causing a failure). Or perhaps it’s not a single bizarre contributing factor but instead a combination of small contributing factors whose critical relationships or combined probability of occurrence hadn’t been considered. 

What Matters Are Relevant Outcomes 

In these cases, it’s useful to keep in mind that, for all its vast specific complexity (both known and unknown), the risk landscape has a limited number of outcomes that are relevant. In other words, although there may be limitless contributing factors (let’s think of them as sub-scenarios) that can potentially result in, for example, a database outage, ultimately we're still mainly worried about the database outage. Those outage scenarios can readily be analyzed using FAIR.  

Example: Let’s say that we have analyzed the common (“known”) database outage scenarios and now (to cover our bases) we want to account for unknown unknowns regarding a database outage. Simple, just do an outage analysis where the likelihood is extremely low, then spend time analyzing the loss magnitude. Or even simpler, just make a copy of one of the “known” database outage scenarios you’ve already analyzed and drop the frequency value to be really low. Voila! You’ve just accounted for unknown unknowns causing database outages.  

"Black Swan" Events

I should point out an important distinction between two varieties of "unknowns". The focus of this post is on "black swan" events. These are events that simply are not a part of the "analytic consciousness" of professionals in the space because they haven't occurred and are so improbable. This is importantly different from events that haven't been accounted for due to poor visibility into the risk landscape. 

For example, having the business experience a painful outage because a critical database had been overlooked and wasn't part of the asset management process doesn't qualify as an "unknown unknown". That's cluelessness. The way to tell the two types of "unknowns" apart is how people react to them. For true "unknown unknowns", the reaction should be, "Wow.  Who'd have ever imagined!?" For "cluelessness unknowns" the reaction should be, "How the h#@@ did we let that happen!?"

A Dose of Reality

If you have time in your schedule to be worrying about analyzing unknown unknowns, then you aren’t working for any of the organizations I encounter. Most organizations struggle to keep up with the analysis workload associated with the “known” problem space. 

From my perspective, organizations are far better served to create a solid taxonomy of their loss event space (see this prior blog post), so as to minimize overlooking scenarios they should have thought of, use triage to identify their most significant loss event scenarios, and then do solid risk analyses on those scenarios.

Learn How FAIR Can Help You Make Better Business Decisions

Order today
image 37