Communicating complex security issues quickly and clearly to a non-technical audience is a frequent challenge in our jobs. Dashboards illustrating a positive or negative change in the metrics we track are a common approach, showing trends for threats, attacks, and vulnerabilities. To dress them up, we use gauges, global maps, pie charts, trend lines, heat maps, and other visual cues instead of words and tables. However, in my experience working with customers, these visualizations are often not clearly understood by the intended audience. The executive team leaves a briefing more confused than when they walked in, and the security team often leaves the meeting with no tangible feedback, no sense of ownership, and no ability to take action.
While the data is correct, the message is not applicable to the executive audience. They cannot relate tactical topics such as threats with unusual names, issues with software patching tools, or device vulnerability levels to corporate objectives like growing revenue, managing risk, or specific strategic projects. So I work with our customers to develop dashboards that relate directly to corporate strategy.
For example, I often develop dashboards with customers that focus on managing business risk in four areas: revenue impact, operations impact, regulatory compliance, and end-user education. In one case, revenue was the top priority. So we factored revenue into the other risk areas. In operations, we produced a summary for each major project showing successes, problems, and potential risks to revenue. During the presentations, we could then drill down into details for each project as questions arose.
Similarly, for compliance we looked at what regulations were being met, what controls were in place, the areas of concern, and how these factors and overall compliance could affect revenue and risk. This was especially important for cross-border and cross-regulation issues, where employees could have been in violation just because they worked on data from different projects or different countries.
Finally, how were we doing with end-user awareness and education? Specifically, where was the company at risk from social engineering, and what was the progress and feedback from activities such as social engineering seminars? This approach generated far more discussion and ultimate buy-in from the executives than would have a collection of technical metrics.
In another example, a customer was presenting dashboards with 40 metrics highlighting the problems and issues their underfunded department was having, but they could not get support from the executives. We helped move them to a dashboard that matched 10 core strategic priorities. Possibly the most successful part of this presentation was clearly identifying three of the 10 priorities that could not be supported due to lack of data and funding, and the risk that this presented to the organization in areas of potential outages, security breaches, data theft, or bad press.
As we develop these dashboards, we keep a few points in mind:
- It is important to get the story across quickly, so we use big pictures and color to illustrate the key points and draw attention to a key issue or outcome.
- Dashboards are not always presented live, so they must be comprehensible and have enough context to communicate well when they are forwarded from one executive to another.
- Summaries are great, and sometimes the only part that is presented, but having the details to drill down when questions arise is critical.
Most people talk in the vocabulary of their own jobs, and we in the technology industry are certainly prone to developing a language that can be incomprehensible to outsiders. When presenting to execs, it is necessary to speak in their vocabulary, to align our reports with their priorities. In the end, the words of messaging expert and campaign manager Dr. Frank Luntz come to mind: “It’s not what you say, it’s what they hear.”