In a research world where we collect data on security technology (and services!) adoption, security spending, workforce attitudes about security, and more, there’s one type of data that I get asked about from Forrester clients in inquiry that makes me pause: breach cost data. I pause not because we don’t have it, but because it’s pretty useless for what S&R pros want to use it for (usually to justify investment). Here’s why:
- What we see, and what is publicly available data, is not a complete picture. In fact, it’s often a tiny sliver of the actual costs incurred, or an estimate of a part of the cost that an organization opts to reveal.
- What an organization may know or estimate as the cost (assuming they have done a cost analysis, which is also rare), and do not have to share, is typically not shared. After all, they would like to put this behind them as quickly as possible, and not draw further unnecessary attention.
- What an organization may believe is an estimate of the cost can change over time as events related to the breach crop up. For example, in the case of the Sony PlayStation Network Platform hack in April 2011, a lot of costs were incurred in the weeks and months following the breach, but they were also getting slapped with fines in 2013 relating to the breach. In other breaches, legal actions and settlements can also draw out over the course of many years.
That’s why I refer to breach data as unicorn data; I’m always on the hunt for it, have to remind myself that what I see is one thing and what I’m looking to really get is a fantasy, but that’s okay because I love it anyway! I don’t think we should stop trying to estimate and collect breach cost data. We do need to change our expectations for how we use it by understanding what we’re actually looking at (and what may be missing from this) when we see these types of numbers. S&R pros need to rethink how they can best justify and prioritize security investments and rally the business behind them. Forrester has previously published research on information security economics that can help: 101, 102, and 103. In addition, it’s time to start thinking of protecting customer data as a corporate social responsibility, and not to check off boxes for compliance or a thing that must be done so you can avoid some nasty breach costs.
What does your organization consider a corporate social responsibility? Is protecting customer data one of them? Why, or why not?
I’ll also be speaking on this topic of protecting customer data as a corporate social responsibility and sharing a bit of breach cost data (with caveats, of course) at Forrester’s upcoming US Tech Management Forum in May. I hope to see you there!