Driving Value Conversations in Cybersecurity and Technology

It is the rare situation where an organization will chose to spend on cybersecurity without some real sort of value driver. Gone are the days of "it's a firewall, you have to have one before you go online" and "antivirus is just a no-brainer, you need a good one." Those days went the way of Saturn, Pontiac, and Oldsmobile - at about the same time.

These days, whether you're lobbying inside your own company for improvements, or you're out to sell your fantastic solution to a customer, "you just have to have it" isn't good enough. Today, if your security improvement doesn't tie directly to value it just won't be implemented, full stop.

But as cybersecurity professionals we often let ourselves fall down a rabbit-hole where we mistakenly believe that the "cybersecurity" value we see should simply automatically resonate with leadership or our buyers. We often miss the translation between "cybersecurity value" and "business value," and that translation is so desperately important that it is the key difference between a win and a lost in most cases.

Your Value May Not Be Your Audience's Value

Cybersecurity people - and really, any technical people - tend to see value in technological terms and as intrinsic in the technology or solution in and of itself:

• Multi-factor Authentication makes us more secure, and we should always be more secure - the value is intrinsic.
• The latest Apple phone has value because it is the latest one - the value is intrinsic.
• We should be PCI compliant because we should - the value is intrinsic.

Business people don't see value the same way. If you'll forgive the oversimplification, they generally see value in the following ways:

• Will this reduce my costs (or prevent them from increasing)? If so, it has value.
• Will this improve my revenue (or prevent it from shrinking)? If so, it has value.
• Will this improve (or protect) my brand? If so, it has value.

(The parenthetical items are the weaker value proposition in each case)

Recognizing this problem is a first step to addressing it, for both sellers trying to make a sale and for practitioners trying to improve their environments. The situation is somewhat like trying to order dinner in English while in a restaurant in Paris: not speaking the native language means you may not be readily understood, and your order may be incorrectly taken down. Not even trying to speak the native language is more likely to annoy the server, and then all bets are off.

Translation Pitfalls

I can say from hard fought experience, there are plenty of pitfalls for the technical thinker as they try to learn to speak the language of Business Value. Here are a few of my favorites:

• Compliance - Complying with any regulatory or governmental requirements is very rarely going to be seen as a business value. Rather, compliance is generally seen as a reason to spend the least amount of money and effort. Compliance rarely reduces costs, it generally doesn't improve revenue, and when is the last time you chose a company based on whether or not they were PCI compliant? Use compliance as a "business value" driver sparingly, and with realistic expectations.
• Risk - Risk can be a very good business value motivator, however there's a serious gap between cybersecurity/technical risk and business risk. Even in the era of ransomware companies limit their cybersecurity spending, instead trusting insurance and PR plans to mitigate the risk of an event. The numbers suggest that strategy has been relatively successful - the percentage of companies that fold after a cybersecurity event is shockingly low. Discussing risk as a business value driver can be done, but you need to have the right argument.
• Market Advantage - This one hurts most of all. Generally consumers don't make choices based on privacy and security, they make choices based on price and brand name, primarily. Additionally, as a seller in the cybersecurity industry for over a decade I've never had a company refuse to buy from my organization because our security wasn't good enough, or somebody else's was way better. (I have had them pass us over because we didn't meet compliance needs - an exception to my first example) Traditional tech improvements have a better chance here, but they have to be well researched and generally have to be revolutionary improvements.

Translation Strategies

So what is a technical person to do if they want to talk business risk? Short of inserting a babel fish in their ear, there are some strategies that can improve communications and persuasion efforts.

Quantifiable Metrics

Hard to argue with numbers staring you straight in the face. The most valuable metrics are always ones derived directly from your actual environment - especially if you have before and after metrics from a proof of concept or a test of some sort. Industry statistics (with appropriate references) can be helpful as well. Metrics that can be tied directly to the three primary business drivers help as well. Some examples:

• Before: average weekly time spent chasing false positive alerts: 72 person-hours. After: average weekly time spent chasing false positive alerts: 22 person-hours, a 68% improvement.
• Per the Made Up Cybersecurity Insurance Industry Survey, organizations that protect all external access with MFA are 37% less likely to experience a successful ransomware attack.
• Changing to this new cloud hosting provider will cut our computation and storage bill by $23,000/month, or $276,000/year.

The difficult part with metrics is that there is a significant lack of trustworthy, ready made metrics for us to use. That means we have to find ways of creating our own metrics, or we have to search for reliable sources of metrics. Fair warning: there are some well known metrics providers who are considered to be, well, pretty bad at providing real metrics. Sometimes the best place to get 3rd party metrics are from the industry analysts, and you'll likely pay significantly for those.

Examples With Outcomes

Whether it is reminding your own business leaders about that major outage from last month and describing how your proposal will prevent that from recurring, or telling your prospect a story about how someone else achieved their goals through your solution, examples that tell a relatable story are useful. These are not necessarily as valuable as metrics, but they help when metrics aren't available or when the metrics aren't telling the whole story.

Tie Activity To Approved Initiatives

Existing initiatives are already approved and already expected to provide business value. That's a great opportunity to tie your effort/improvement/capability to that already approved initiative. If it is time to migrate ISPs for all the remote offices, perhaps that firewall standardization project should be performed at the same time. If your systems are moving to a new cloud provider, perhaps changing your SSO solution should happen at the same time. Again, this is a weaker value proposition, but these are still better than no value proposition at all.

Focus On Simplification and Reducing Complexity

One of the inherent value propositions that business value thinkers generally respect is that simple is generally better, by being less costly, less likely to interrupt business, etc. Most business value thinkers worry about things like shelfware - they don't want complex systems that are intended to solve for very specific needs. They prefer simpler systems that can address a variety of needs. As with the approved initiatives approach, this isn't necessarily the strongest argument, but it may be the strongest one you have available.

Making the Effort To Describe Business Value

Just like learning a foreign language, practice will make perfect with regard to this topic. There is no time like the present to begin making more persuasive value based arguments.