Turning Incident Response Communications into a Sustainable Security Communications Program
Photo courtesy of Melanie Ensign
A recent piece in GitHub’s ReadME newsletter about moving from incident response to resiliency got me thinking: shouldn't that also happen for incident response and security communications?
In the GitHub article, the author Will Larson (CTO of Calm) does an excellent job of laying out, from an engineering perspective, how to get beyond the rinse and repeat cycle that occurs between incident notification to mitigation, and build a process that results in greater reliability so that there are fewer incidents to begin with. Wouldn’t that be nice?
Much like the often-messy technical process of incident response, security communications are frequently created on the fly, by many cooks, with little forethought (due to time constraints) and even less afterthought. This results in a security and incident comms process that is anything but resilient and sustainable, and can leave everyone from external comms to executives annoyed at why something as simple as getting a message out always seems to be so hard. In short, the process feels unreliable, and the amount of work that goes into managing it is often unsustainable.
I see this firsthand with a lot of our clients, which is why I think it’s important to focus on your incident comms program before you ever need it. And trust me, you will need it.
The best incident response communications are built on a foundation of strong, ongoing security communications. Here are a few thoughts on how to do that. I’d be happy to share more specific tools and approaches you can try if you’d like - just reach out to me.
Do Your Homework
If you have the luxury of time (no one does, but still) it’s worth doing an inventory and analysis of how incident comms have been going. Look at the last six months to a year of messaging and engagement (internal and external) to see if there is consistency and clarity to the comms that have been sent. Make note of what seemed to land well as well as what added to or subtracted from your credibility. Talk to the receivers of these messages. What do they think? You may be surprised at what you hear.
If you work in a mid-size to large org, find out who else might be “doing crisis comms” and will come out of the woodwork when you least expect it. They may send out duplicate messages, or almost worse, be responsible for a certain audience segment (ie, field sales) and not be sending incident alerts when they should be. Document all crisis/incident/security comms currently being developed so you’re not caught off guard and build their work into your program.
Build Your Bench
Relationships are one of the most critical - and most often overlooked - aspects to building a sustainable security comms program. The time to make friends with the folks you’re going to need on your side when the you-know-what hits the fan is now - before it does. It’s much harder to make friends when things are already on fire.
Identify who in your ecosystem is key to your success – people with the knowledge, credibility, and clout to either amplify or confuse your message. This can include external security experts, academics and researchers, advocates, business partners, law enforcement; oh, yes, and politicians (they have a history of getting real loud about anything that scares them or could be hijacked for media sound bites).
Talk to these people often - don’t wait until you’re in a crisis. Keep them informed of what your security organization is up to, where you’re making investments, etc. You can also talk about the weather and buy them coffee (and you probably should). The point is to build and maintain these relationships, because you’re going to need them.
Bring Consistency to Decisions
This is all about scenario planning, and being prepared for all of them with pre-approved priorities, values, and principles for how you will communicate in those situations. The goal is to accelerate sound and fast decision-making by getting buy-in up front about roles, responsibilities, and expected responsiveness. In my experience the greatest source of friction and delay in incident communications is caused by seemingly arbitrary input from stakeholders about what to say and how to say it. I’m not talking about legal language required for certain situations, but rather things like how do we demonstrate empathy and avoid coming across as defensive? And who makes that decision?
We worked with a client to help them define and secure stakeholder consensus on their principles for security communications – and thus, subsequently, also incident communications. A few of the principles we landed on were:
Be front-footed and transparent with employees
Prioritize communications that build customer trust
Why are principles helpful? Because no matter who is writing or editing the communication – whether it’s PR, legal, customer support, or someone else – it’s already determined upfront that employees will get the whole story (and as a result, we should prepare for what this will mean for other audiences like customers, potential plaintiffs, and media). This client decided holding back from employees was simply not an option.
Stating that communications that build customer trust is a priority for incident communications gives every function in the company permission to put aside content and messaging they may have planned for any given day in order to prioritize a security message. Securing cross-functional buy-in for this approach – and documenting what they would need from security in order to accomplish this during an incident – was also part of our process in defining the communication principles in the first place.
Make it true before you need it
This is where an ongoing and proactive security comms program really shines because not only does it serve as a mechanism through which you can nurture the relationships you need, it also gives you daily practice in applying your principles and engaging in your decision-making process. Not every incident is going to be a major breach – it might just be a negative news cycle about a product feature whose “creepiness” facture you underestimated, or a FUD-driven vendor whose most ingenious marketing strategy is to publish “research papers” with unverified claims against you for shock value and shallow press attention. Just like the major breaches, these incidents pull resources from other priorities, can incur costs even after the attention subsides, and are often resurrected by journalists, regulators, and the security community to fill holes left in your next incident communication.
Regardless of the specific incident, there are things you will wish all these people knew about your security program in advance. Things like which authentication standards you use, user and employee account security controls, and your strategy for supply chain security (remember 3rd party incidents impact you, too). These are all very common issues that come up in both small and big security incidents, but you won’t have enough real estate in any single communication to explain the technical details or the fact that your approach has been maturing for years. Those educational resources, for the stakeholders who want them, should be published yesterday and updated as needed. The worst time to try and convince someone that you prioritize security is after an incident. Do it now so it’s available as a link, leave behind, etc. when you need it. A best practice is to make it easy to find in an online Trust Center, and we’ve built dozens of these for our clients over the past few years.
While the upfront (and ongoing) work in building a security comms playbook that contains runbooks, processes, contact information and more can take some time, it’s time well spent. Because it puts you in the driver’s seat when an incident occurs and you’re able to respond quickly with the right messaging to each unique audience. Over time, this builds trust between you and the people who count on you for immediate and accurate information..
Do a Reality Check
Cybersecurity and corporate trust issues are ever-evolving. At the same time, internal organizational changes and fluctuating priorities are a permanent reality. So while you can put rigor and consistency around your incident communications program, it’s never really done. You need to constantly audit its impact and always conduct incident post-mortems that focus on comms. You’ll want to avoid frequent revisions and updates to your program of course - remember, this is about creating a sustainable and consistent process - but if the environment demands it then revise or update your approach.
And remember that incident response comms are but one part of the overall security communications program. Internal messaging around security training, security strategy as a business advantage, privacy controls, and more are all important streams that shouldn’t be siloed from incident comms - they are all parts of a very important whole.
If you want to learn how to turn one-off incident communications into a proactive security communications program that can better position you for future incidents, let us know.
