Two weeks ago I had the pleasure of attending the Gartner Security & Risk Management Summit 2017. One theme in particular stood out to me:
"Risk Reporting Must Be Relevant to the Business"
This statement should not be a surprise to you if you're already using RiskLens. The entire premise of the FAIR model and the RiskLens platform is to represent risk in business terms. Instead of presenting risk by traditional qualitative means, quantification encapsulates business impact. Instead of a 'High' or 'Red' risk you're able to present your risk in financial terms, such as $42,000 of potential loss.
The presentations I attended (which were all quite packed) take this a step further. Gone are the days where executives will accept a report that only provides counts. Counts of vulnerabilities mitigated. Counts of ransomware blocked. Counts of systems patched.
Instead risk managers must present risk in a manner that is relevant to the business. Yes, that means reporting in terms business leaders can relate to, mainly financial terms. But it also means in ways that are relevant to the business.
Business leaders need risk reporting they can relate to and is relevant to their goals.
That means that reporting in financial terms is half of what leaders need. There must be a narrative that articulates risk in a meaningful way to the business' objectives. (It also means reporting must support decision making, but I'll save that for another post.)
In practice, this means risk leaders must understand what their companies' objectives are. Once you understand those, it becomes a practice of alignment.
Here are a few examples for various industries.
A manufacturing company has stated this year's goal is to increase supply chain efficiency. A risk manager can support this goal with reporting on associated availability risk.
An e-commerce company knows that downtime equals lost revenue. So reporting on initiatives to reduce availability based loses is warranted.
For a hospital, the integrity of healthcare systems is of upmost importance. Thus, reporting should have a focus on potential integrity issues.
Notice that for each of the above examples, reporting would not be simple counts of X, Y, or Z. Instead, each one relates to a goal or core competency of the respective business.
This Includes Risk Metrics...
This does not preclude the need for metrics. It means a count is not a useful metric (and arguably isn't a metric in the first place). Instead, business relevancy, makes a metric more useful.
Finally, let's use our manufacturing company, to unpack a metric on vulnerability prevention. A relevant metric on vulnerability mitigation would be tied to the supply chain. What might this look like?
First let's look at something that may have been reported on before; the number of Windows server vulnerabilities. How does preventing a vulnerability on a Windows server matter to the business? If their automation runs on Windows servers, an exploit can cause down time. So mitigating Windows server vulnerabilities lowers availability based risk. Which supports the company's goals of increased supply chain efficiency.
But a simple count of vulnerabilities would be insufficient. In this case, a useful metric would be on the InfoSec initiatives that are reducing vulnerabilities, and reporting on their efficacy in terms of possible risk reduction (in monetary terms). Then it can provide meaningful reporting for both sides of the business.