Let's get this out of the way up front: I don't hate dashboards. I understand that practitioners need some sort of asset to help us translate what we're seeing on the ground to something that can be consumed by the board or the C-suite.
I also greatly appreciate the power of data visualization – there may not be a better way to help discover additional insights and track progress, but progress doesn't happen through, or even because of, the dashboard. Indeed, dashboards only reflect progress earned through hard work and difficult conversations.
It's time we recognize and acknowledge where the hard work of cyber risk management really takes place: in the grey areas, in challenging conversations and in those times when assumptions differ from reality.
A common narrative which echoes throughout the halls of conferences or on webinars goes something like this: "We just need additional visibility!" or "If only we had a single pane of glass..." or "All of our data is so siloed, we just need to get it all in one place."
While these may all be worthy goals and necessary parts of the risk management lifecycle, achieving these things alone will not improve your risk posture. They can also end up being very distracting – making your team feel like they’re working towards something, when really these projects end up more effectively making you look busy without moving the needle on managing any risks. Instead of starting with potentially distracting efforts like dashboards, here are several common conversations that practitioners should be having with their stakeholders.
"What are our minimum security requirements for X (where X could equal high risk vendors, confidential data, web applications, etc.)?"
Defining exactly what is in scope and what is acceptable is a deceptively difficult exercise. The conversation can't begin until you've identified the appropriate stakeholders. These often include not only the IT security side of the house, but the business or application owner, perhaps a representative of the central risk committee or General Counsel and someone from the technical side who may be needed to support the effort.
Conversations around minimum requirements tend to evolve similarly, with someone quickly commenting that these may be the minimum controls, but ideally (X) would go above and beyond to be secure.
Unfortunately, that's not how minimum standards work. If someone in these discussions desires higher performance than the proposed minimum standard, then figure out if it makes sense to set the higher expectations as the new minimum.
It's very difficult to ask internal stakeholders or external vendors to go above and beyond the minimum requirements once they've been established. These difficult conversations should hash out exactly what minimums are acceptable to your organization, and then they should be shared explicitly with those expected to meet them (if you or someone in your organization is not willing to share those requirements, there's another opportunity for a difficult conversation). Then, spend time getting your ecosystem – internal, external or both – up to that newly defined minimum level, rather than encouraging already strong performers to go above and beyond.
"Who owns this risk?"
Data drives discovery. Once risks are actively managed, or even prior to that point when the risks are being uncovered, it is worth asking "Who owns this risk?" Even if it should be clear who owns the risk, asking explicitly (and getting an explicit answer) forces us to opt-in to the risk management process.
Risk conversations need to be tangible: the risk assessment process is designed to create this validated level of understanding, and it's the same approach we've taken in building CyberClarity360.
Some organizations require risk owners to sign-off on accepted (i.e. "owned") risks on an ongoing basis (annually, for example). Since data is always helpful to inform these conversations, conversations can be enriched by providing actual examples of control gaps or recent findings to sharpen the question you’re really trying to ask the risk owner: "So, what do you want to do here?" If they don't feel like they have enough information to answer that question, then you’re able to get to work, find the requested information and continue to support your team in making better-informed risk-based decisions, which is ultimately what risk management is all about.
Once a few of these difficult conversations have been had, you should notice a couple of things. First, these conversations become less difficult. When you're approaching the challenges from a point of good faith, not trying to penalize or highlight shortcomings, but rather trying to bring abstract concepts to life, you will eventually be well-received.
Second, you’ll receive more replies along the lines of "Now I get it" or "Now I see." Your stakeholders will begin to appreciate how you're helping them understand the risks they need to manage, and it's at this point that you're finally ready to use dashboards. Feed them, build trendlines, make them splashy and attractive and easy to engage with. But, like your difficult conversations, make sure that there is substance behind them.
An ideal dashboard is one that makes you immediately want to dig in, drill down and explore to figure out why it's showing what it's showing and how it could be improved. This same process – finding an engaging element, exploring the underlying factors and deciding to better manage the identified risk – is exactly how you should structure your conversations.