The context is the story
CISOs live inside so many different types of technical data. It’s necessary to communicate with boards of trustees, but when boards don’t understand the technical details, a flood of data will not result in any “eureka” moments. So how does one “tell them a story”?
One strategy is to take a step back from your own head. You live inside all the current news about cybersecurity. It’s so omnipresent for you that it’s like air. It’s hard to remember that others don’t breathe that same air. In fact, it could be tempting to assume that the only way they can understand where you are is for them to be soaking in the cybersecurity life just like you are.
But they don’t have to be. Look behind you to see how you got where you are. Tell them that story, not just the upshot of where you’re currently standing.
Let’s say you need to expand a SAN for backups of your mission-critical data. Maybe ransomware attacks have increased dramatically in your industry in the last year. You know of a competitor who’s been hit, and how it has affected their business. You have already completed an assessment of your company’s “crown jewels” and you know what you have to protect. You’ve got a plan A, a plan B and a plan C and the associated estimates of residual risk that go along with each of them.
In such a situation you’re not just going to walk in and say “We need to expand the SAN and I need X dollars.” You’re going to tell them the story of how you arrived at the day where you walked in and said “We need to expand the SAN and I need X dollars.” Like any storyteller, you have to leave out details that are related but not critical. You don’t need to narrate that moment when you were brushing your teeth and suddenly realized that your top security threat was ransomware. You are going to tell a story in which your organization plays the lead character. Things were going great (or badly – your mileage may vary) when suddenly — Plot Twist. What occurred in the security environment to raise the size or the awareness of the threat? How did the opportunity to address it present itself?
If your current proposal is in line with, or a result of, your overall security strategy, that’s part of the story. “As you know, when last we visited our hero, …” Needs – and plans to address needs – don’t just appear out of the blue. To tell a story you need to explain how you and the organization got to this point, and what you suggest for a best possible resolution.
It may sound flippant but in fact both stories and project proposals require “resolutions” for a reason. There must have been a problem, or a plot twist, somewhere, or the story would be pretty boring – and the project would seem pretty unnecessary. Metrics can be compelling but out of context, they’re just floating on a page. Your story really is “how we got here — and what we’re going to do about it.” Bring the audience along for the ride by filling them in on the backstory.
It doesn’t have to be complicated. In our SAN example, we want to start with some data about the rise of ransomware over recent time, and a case study of that competitor who got hit. We fill in the plot that’s already happened: we have a plan for what to protect and how, thanks to security planning that was already underway. The story will end happily with a small investment in SAN storage (along with whatever your related business continuity/disaster recovery plans need). Of course it’s not happily ever after, because there’s no such thing in cybersecurity, but at least this story ends with our hero – Your Company – in a much better position than when the story began. And presumably you’ll be implying that perhaps some time will pass before the sequel comes out – requiring further investment.
Image is Forest Walk by CSeeby, via Flickr; Creative Commons license, some rights reserved.