In our Standards Committee meeting this week, one of our members shared something that the rest of the committee seemed to recognize: someone in his organization had added an entry to their technology risk register with the title, "Unknown Risk." It was rated medium-high. Our member noted that this kind of entry is not as rare as you would hope.

Another committee member asked the question everyone was already thinking: "What's the mitigation plan for that?" That got some chuckles, but it’s not really funny: the underlying problem is a real one. Our member still has to sit down with the submitter and work out what is actually behind the entry, and it may well turn out to be significant or even material.

So the conversation turned quickly to a better question: how does something like this happen? The entry was not completely devoid of detail. There was something to it. But the person who submitted it clearly struggled to articulate what they were worried about. I suspect the submitter was not a risk management professional, or at least not an experienced one. They knew enough to sense a problem and to know it belonged on the register. They did not have the vocabulary or the structure to say what the problem actually was.

This story points at two very different lessons. The first is a lesson about discipline. The second is a lesson about humility.

Lesson One: You Cannot Assess What You Cannot Articulate

A risk register exists to support decisions. Every entry on it should eventually lead somewhere: mitigate, transfer or share (insurance is the common example), escalate, or accept. None of those four paths is available for "Unknown Risk," which is exactly why the mitigation-plan question was so hard to answer. The entry was undecidable by construction.

The harder truth is that most risk register entries are only marginally better. Walk through a typical register and you will find titles like "lack of enforced MFA on user accounts," "third-party vendors introduce cybersecurity risks," or "phishing is a big risk to our organization." These read as more substantial than "Unknown Risk," but they suffer from the same defect. They are control deficiencies, audit findings, vulnerabilities, or vague concerns. They are not treatable risks. They are missing the elements you need in order to estimate how often something bad will happen and how much it will cost when it does.

This is the problem the FAIR Cyber Risk Scenario Taxonomy was written to solve. It gives practitioners a best-practice structure for turning a concern into a scenario, built on four elements:

• Threat. Anything or anyone capable of acting against an asset in a way that results in loss. The taxonomy enumerates ten threat actor types, along with intent, which is either malicious or accidental.
• Asset. Anything of meaningful business value that can be affected in a way that results in loss. Note the word "business." A server is rarely a satisfying asset definition. The revenue-generating process running on it usually is.
• Method. The specific attack vector used to access or affect the asset. Method matters because two scenarios with identical threats and assets can carry wildly different levels of risk, and require entirely different controls, depending on how the attack is carried out.
• Effect. How the loss actually materializes for the business, expressed through the confidentiality, integrity, and availability impacts on the asset and mapped to loss categories drawn from FAIR-MAM.

Assembled, those four elements produce a sentence anyone in the organization can read: "[Threat] impacts [asset] via [method], causing [effect]."

So "third-party vendors introduce cybersecurity risks" becomes something like: "A nation-state-backed espionage group impacts a cloud-based supplier management platform via malicious software updates, causing production disruption and exposure of supplier contracts."

That second version can be analyzed. You can ask how often it is likely to occur, what your controls actually do about it, how much it would cost, and whether the cost of reducing it is worth paying. The first version lacks the specificity needed to answer those questions.

There is also a diagnostic benefit here that I think gets undersold. When someone cannot fill in all four elements, that is information. If a submitter can name a method and an asset but not an effect, the organization probably has not connected its technology estate to its business value. If they can name an effect but not a method, they may be reacting to a headline rather than to their own environment. The taxonomy does not just improve the writing. It identifies the gap and provides a means to fill it.

Which brings me to the second lesson.

Lesson Two: Risk Management Is the Discipline of the Unknown

Here is the uncomfortable part. The person who wrote "Unknown Risk" was, in a certain sense, being more honest than most of us.

Everything on your risk register is partly unknown. That is what makes it risk rather than accounting. If you knew the frequency and the magnitude with certainty, you would not need a risk function. You would need a checkbook.

Most readers will remember Donald Rumsfeld's much-mocked and much-quoted distinction from a 2002 Defense Department briefing. He separated the things we know we know from the things we know we do not know, and then added a third category: the "unknown unknowns," which he described as the ones we do not know we do not know. He was talking about intelligence gaps regarding Iraqi weapons programs, and the phrasing was widely ridiculed at the time. But it has aged rather well because it describes the nature of our work.

Cyber risk management operates across all three categories:

• Known knowns. The scenarios you have scoped, the controls you have inventoried, the incidents you have experienced. This is the smallest category, and it is the only one most risk registers reflect.
• Known unknowns. The scenarios you have identified but whose factors you cannot pin down. How capable is this threat community, really? How often does contact actually occur? What would three days of downtime cost? This is where quantitative risk analysis lives. FAIR does not eliminate these unknowns; it gives you a defensible way to reason about them using ranges, distributions, and calibrated estimation rather than pretending to a precision you do not have.
• Unknown unknowns. The threat actors, assets, methods, and effects you have not thought of at all. No amount of estimation rigor helps here, because the scenario is not on your list to estimate.

That third category is the one that should keep risk leaders up at night, and it is the one our profession addresses least well. A mature risk program can be exquisitely rigorous about the scenarios it has scoped and completely blind to the one that eventually shows up. Rigor within a frame does nothing about the frame.

Risk management must do more than manage the known. It has to be built to absorb the unknown. Here are three ways to do that.

One: Audit Your Surveillance and Intelligence

Before you ask how well you are managing risk, ask how you become aware of anything in the first place. Awareness is itself a control function, and like any control it can be capable, covered, and reliable, or it can be none of those things.

The FAIR Controls Analytics Model (FAIR-CAM) is useful here because it treats awareness as a system rather than a vibe. Situational awareness sits within the Decision Support Control domain and depends on three data sub-functions:

• Asset data. Do you know what you have, what it is worth, and what liability it carries? The unit of measurement in FAIR-CAM is elegant and uncomfortable: the probability that the asset data used to support a decision is accurate. Ask yourself what that probability is in your organization. Then ask how you know.
• Threat data. How do you learn that the threat landscape has changed? FAIR-CAM measures threat intelligence by elapsed time between a change in the threat landscape and your awareness of that change. Not by feed count. Not by dollars spent. By latency.
• Controls data. Do you know the current condition of your controls, or only their intended design? These are very different things, and the gap between them is where most loss events live.

Add to this the Variance Management side of the house. Control monitoring exists to identify when controls have drifted from their intended state. Threat intelligence exists to identify when the landscape has shifted underneath controls that have not drifted at all. Both are detection functions aimed at the unknown, and both have an AND relationship with correction. Identifying a variance you never fix buys you nothing.

If you take one action from this section, make it this: pick a real change that occurred in your environment or in the threat landscape in the past year, and reconstruct how long it took you to find out. That number is a better measure of your exposure to unknown unknowns than any heat map.

Two: Think Like the Adversary, and Use the Taxonomy to Do It

Look at the major attacks (cyber or otherwise) of the past few decades. I will not list them, but you know the ones. What is striking is how many were simultaneously novel and, in hindsight, entirely predictable. Somebody could have thought of them. Often somebody did, but nothing was done about it.

Creativity is not a personality trait you either have or lack. It can be structured. A few approaches I would recommend:

Use the taxonomy generatively, not just descriptively. The scenario taxonomy has ten threat actor types, ten method types, five asset types across ten categories, and ten loss categories. Treat that as a grid rather than a checklist. Most organizations' registers cluster in a handful of cells and leave the rest empty. Walk the empty cells deliberately and ask whether each combination is implausible or merely unconsidered. Those are very different reasons for a blank.

Start from the asset and the effect, not the threat. Threat-first thinking inherits yesterday's adversaries and yesterday's tools, which is precisely the thinking that unknown unknowns defeat. Effect-first thinking is more durable: if this revenue-generating process were unavailable for five days, what would that cost, and how many paths lead there? Who would want to exploit the asset and what would they stand to gain? You will find paths you never mapped, and the analysis stays useful even when the attack method turns out to be one nobody had a name for yet.

Invite people who do not work in security. Your fraud team, your business process owners, your general counsel, your operations leaders, and your finance team all know about assets and dependencies your security organization has never inventoried. They also know about business changes ahead of you. Most novel exposure follows adoption curves, whether that is new AI tooling, a new third party, a new market, or an acquisition. Somebody in the building has an idea as to what is coming.

Study other people's incidents seriously. Not as news consumption, but as an exercise. For each significant public incident, ask specifically what the local version would look like here, and whether the register reflects it. External event data is one of the few honest windows into scenarios you have not experienced yourself.

Budget for novelty. Reserve some portion of your analysis capacity for scenarios with no internal history and no obvious data. These analyses will be less precise. That is not a defect. Precision on the wrong scenario is worth less than a rough range on the right one.

Three: Bet on Response and Recovery

We would all like to prevent 100 percent of attacks by eliminating every vulnerability. Of course, that’s a pipe dream. Given that, the ability to detect, contain, and recover becomes the most valuable capability you have, and here is the part I think deserves more attention than it gets: response capability is structurally better suited to the unknown than prevention is.

FAIR-CAM makes the reason precise. Loss Event Controls operate through three domains. Prevention works through avoidance, which reduces contact frequency between threats and assets; deterrence, which reduces the probability of action once contact occurs; and resistance, which reduces susceptibility to a successful action. Detection works through visibility, monitoring, and recognition. Response works through event termination, resilience, and loss reduction. Prevention reduces loss event frequency. Detection and response reduce loss magnitude.

Now notice the asymmetry. Preventive controls tend to be indexed to a specific threat actor, a specific method, or a specific vulnerability. A control that resists a known technique does nothing against a technique nobody has published yet. Response and recovery capabilities are far less method-dependent. Your ability to contain lateral movement, fail over a critical process, restore from clean backups, communicate with regulators and customers, and stand up a coordinated incident command works roughly as well against a novel attack as against a familiar one.

That is the closest thing our field has to a hedge against unknown unknowns. Prevention is a bet on the scenarios you named. Resilience is a bet on the ones you did not.

Give the Unknown a Name

I keep coming back to that register entry. It is easy to treat it as an oddity, but it was a signal, and the organization may be better off that somebody bothered to write it down at all rather than staying quiet. Someone will now do the work of figuring out what it means, and there is a reasonable chance it turns out to matter.

The failure was not that the submitter did not know enough. It may be that they didn’t have a structure for converting what they know into something the organization could act on. Give a person the four elements of a scenario and much of the time they can tell you what they are worried about. We should not expect someone to invent the structure themselves when filling out a form.

So build the structure. Use the scenario taxonomy to make your register decidable. Use FAIR to reason honestly about the known unknowns rather than pretending them away with a color. And design your program, especially your awareness functions and your response capability, so that it minimizes the impact when the unknown finally shows up.