If It Doesn't Improve the Decision, It Doesn't Belong.
Cybersecurity has become extraordinarily good at producing information.
Examples of this phenomena include:
Dashboards.
Risk registers.
Maturity assessments.
Vulnerability reports.
Threat intelligence.
Control assessments.
Compliance reports.
Metrics.
More metrics.
And dashboards containing those metrics.
Yet despite having more cybersecurity information than at any point in history, executives still struggle with some remarkably basic questions:
How much cyber risk do we have?
Where should we invest?
How much should we insure?
How much risk can we reasonably accept?
Perhaps the problem isn't that we need more information. There is an argument that says we actually need less. More precisely, perhaps we need to become much better at distinguishing signal from noise.
Every Question Has a Cost
In the previous papers on this subject, I've argued for starting with critical assets and estimating the financial consequences of two straightforward scenarios: outage and data breach. However, I believe that there is another important part of that philosophy.
Don't collect information simply because you can.
Every additional question in an assessment has a cost. This means that:
Someone has to understand it.
Someone has to answer it.
Someone has to validate it.
Someone has to maintain it.
And eventually, someone has to decide what to do with the answer.
Multiply that across hundreds of questions, dozens of systems and multiple business units and something supposedly designed to support decision-making can quickly become an industry in its own right. The assessment becomes the objective and it really shouldn't be.
The decision is the objective.
Information Versus Noise
This leads to a principle that has increasingly influenced the way I think about cyber risk:
Information that does not improve the decision being supported is noise.
Two words in this statement are particularly important: being supported.
Information is not inherently useful or useless. Its value depends on context.
A packet capture could be essential to a forensic investigator. A CVE list could be essential to a vulnerability manager. Firewall telemetry could be essential to a SOC analyst. But put all three into a Board report about cyber investment and they may contribute almost nothing. They may actually make the decision harder. The information hasn't changed. Its utility has.
Attention Is Also a Finite Resource
Cybersecurity tends to think about resources in terms of money, people and technology. There is another scarce resource that receives much less attention:
Executive attention.
A Board may have twenty minutes to consider cybersecurity within a packed agenda. A CFO may have multiple competing investment proposals to review. A CEO may be simultaneously considering growth, staffing, operations, regulation, customers and shareholders.
Giving those people a twenty-page cyber risk report doesn't magically create another hour in their day.
The report competes for their attention. And every piece of information that doesn't help support the decision consumes some of that finite resource. This is why brevity in executive reporting isn't cosmetic.
It is part of good risk engineering.
The Twenty-Page Report Problem
There is a strange tendency in professional services to associate length with rigour. A 70-page assessment somehow feels more substantial than a four-page one. Sometimes it is but sometimes it simply contains more words.
I've seen technically excellent reports whose most important conclusion is buried somewhere around page 37. That wordcount may satisfy the author but it doesn't necessarily help the decision-maker.
For executive cyber risk reporting, I favour a much harsher discipline. Imagine being told that your assessment of a critical asset must fit onto two sides of a single sheet of A4 for it to be useful for Board consumption. What would you include?
Probably not the entire vulnerability list or descriptions of every control. Probably not pages explaining the methodology. In such a case you would be forced to ask:
What does the decision-maker actually need to know?
That constraint can be incredibly useful.
What Does the Decision-Maker Need?
For a critical asset, the executive questions can actually be quite concise.
What is the asset?
Why does it matter?
How is it exposed?
What are the plausible financial consequences of an outage?
What are the plausible financial consequences of a data breach?
What has been done to reduce those risks?
What has been transferred?
What remains?
And what decision (or set of decisions) is required?
If we can communicate those answers clearly, we have probably provided more decision value than a report containing another fifty technical metrics.
That doesn't mean the supporting evidence disappears.
It still exists. Technical teams still need it, Auditors may require it and Analysts may need to interrogate it.
But the executive report is not the evidence repository. It is the decision interface that matters.
Simplicity Is Not the Same as Being Simplistic
Whenever I advocate simplicity in cybersecurity, there is an understandable concern. Cyber risk is complicated. So surely simplifying it risks losing important information?
Of course it can. Bad simplification throws away information indiscriminately. However, good simplification does something very different because it identifies which information materially influences the outcome and removes what does not.
That is an engineering problem. The objective isn't to make it simple. Instead it is to make it as simple as possible without materially degrading the decision. Those are very different ambitions. The aim is to make it optimal.
Complexity Should Be Behind the Decision
If we think about other systems we use every day.
A modern aircraft is extraordinarily complex. The pilot is not presented with every measurement being generated by every system simultaneously.
A car contains thousands of components and millions of lines of software. The driver receives speed, fuel, warnings and a relatively small number of other decision-relevant signals.
In these and other cases, the complexity hasn't disappeared. It has been engineered.
I advocate that the same principle should apply to cyber risk.
The analysis underneath may involve numerous assumptions, ranges, controls, calculations and dependencies. But the executive experience should remain focused on the information necessary to make the decision.
Complexity should exist within the methodology, not within the decision-maker's experience.
Every Field Should Earn Its Place
This philosophy shouldn't apply only to reports. It should apply to the assessment itself.
Every field should have a purpose, every question should measure something relevant and every answer should contribute to determining the risk or supporting the decision.
If removing a question doesn't materially change either, we should ask why we're collecting the information in the first place. I appreciate that this is a demanding standard but it produces important benefits:
The assessment becomes faster.
The participants remain engaged.
The information becomes more consistent.
The output becomes easier to understand.
Crucially, the methodology becomes something organisations can repeat rather than something they endure once every three years. Utility matters.
Better Decisions, Not Bigger Assessments
There will always be a place for detailed technical assessment. There will always be a place for comprehensive compliance reviews and there will always be occasions when hundreds of questions are entirely justified.
However, we should not confuse those objectives with executive cyber risk decision-making.
If the purpose is to decide how much risk to mitigate, transfer, accept or avoid, then every piece of information should be judged against that purpose.
Does it improve the decision? If yes, keep it. If no, perhaps it belongs somewhere else.
Because the sophistication of a cyber risk methodology should not be measured by how much information it collects. It should be measured by the quality of the decisions it enables.
In the next paper, I'll move from information to action and examine the four established ways in which risk can actually be treated: risk reduction or mitigation, risk transfer, risk acceptance and risk avoidance.
Thought for the week
"If it doesn't improve the decision, it doesn't belong."
