When articulating security metrics, executives risk unintentionally undermining their expertise. Context speaks louder than numbers, said Jeffrey Wheatman, research VP at Gartner, while speaking during the virtual Gartner 2020 Security & Risk Management Summit Tuesday. 

Numbers without the "why" context won't capture the story the metrics are there to support. When presenting security metrics and data to non-technical stakeholders, security leaders's messaging could get lost in translation.

Tech chiefs could get too technical or not technical enough to convey what they need. It takes balance and context to frame metrics. 

Data in context has meaning. Raw data might be dangerous and help reinforce the stereotype that technologists fail to understand the business because they're just "hacking away at black screens with white text on it," said Wheatman.

Security leaders need to know why they're presenting security metrics and numbers, what makes them relevant, and if they're even needed to get their point across to their audience: finance, legal, marketing, sales. 

"If we're just talking about a vulnerability or missing patch or something like an entitlement review, most business audiences don't know what those things are. They don't care. They don't understand how it's going to help them achieve the things that they are measured on," said Wheatman. "We need to make sure that we are telling them the right story."

Contextualized metrics has four benefits, according to Wheatman:

• Enables better understanding
• Promotes informed decisions
• Offers repeatability for input and output
• Gives executives defensibility

Each contextualized scenario helps answer questions around whether or not a decision was right and informed. 

Crafting a story

There are five different ways to contextualize data, to either showcase metrics or bypass them completely. And Wheatman wants security leaders to use at least two or three for a given scenario: 

• Technical and practicality
• Timing
• Location and its proximity to value
• Risk
• Business and the impact on overall goals

Even if a security leader uses appropriate context when presenting metrics, they want to make sure they're not only informing their stakeholders but educating them too. 

"We can tell them, 'Yes, we have a million missing patches,'" but education says, "'We have a million missing patches and here's why that's a problem for us,'" said Wheatman.  

Technical context is usually the "the one that we tend to be fairly good at," said Wheatman. It articulates how critical the issue security is trying to mitigate — low, medium or high. 

Timing speaks to how quickly security is meeting its targets. "We have to balance the need to invest with the need to protect" and run the business, said Wheatman. Security organizations could set out to patch every system in a week, but the time and resources used to achieve that goal are then taken from other projects. "Oftentimes, it's a zero sum game." 

Like timing and striking the balance of practicality, location depends on a business' crown jewels. Security leaders have to dive deeper than a bird's eye view of their company. If a company owns specific data in need of greater protection and encryption, but it's efforts are on network security, "we are actually protecting but we're not very close to the value," said Wheatman. 

Along those lines, risk context should be able to speak to controls or personnel needed for specific areas of exposure. 

But the most important type of context is business. This context gives security leaders the chance to answer whether or not security changes are impacting business objectives. "Are we getting in the way?" or spending too much money, said Wheatman. 

"If we protect ourselves against the million-dollar, million-pound, [or] million-euro risk, but it cost us six million to do that, that's not a good balance with our business," said Wheatman. 

Not all metrics are created equal

An ideal selling point is one that non-technical stakeholders can remember. And while context shapes metrics into a consumable narrative, not all data is worth becoming a metric. 

The data used for metrics has to be quantitative and objective, but "sometimes this is a bit of a cheat. Sometimes we only have qualitative information," said Wheatman. This means security leaders need to use quantitative structures, but if they do so, they have to do it consistently. 

For example, if a security leader says it took three days to patch 95% of their company's billing servers, they can conclude three days "was a good number," with a margin of error of about 5%. If they can iterate this process whenever patches become available, it speaks to the larger narrative of protecting business operations. 

"The board is now involved in the negotiation about what these targets could be," said Wheatman. The conversation will eventually evolve into the audience understanding future scenarios and impact if a patch update is missed. 

Good data also has low overhead. "If it takes us six weeks to gather data, to massage the data, to report the data, and we're reporting it once a month, either we're reporting too frequently, our tool's not right, or process needs to be fixed," said Wheatman. If a company is spending too much time processing metrics, the return on value is moot.