Disclosing Incidents: A Handbook for CISOs

As a CISO, there have been many stressful events I’ve had to manage. Top among them in terms of potential complexity and importance is communicating publicly about a security-related incident. I wanted to share some thoughts that I wish were available to me the first time I had to do so. 

This advice is based on my personal experience thus far in my career. I am looking forward to learning and creating additional best practices with my new team at LinkedIn.

Zero hour

The day has arrived. You’ve had a security incident. Take a deep breath. This happens to everyone. Hopefully, it’s not an actual breach. More likely it’s something relatively minor. You’ve worked with your legal and privacy teams and you have, as a team, determined you need to notify customers or users. Now what?

Now you need to demonstrate that you, and your organization, are worthy of whatever trust has already been earned from your customers or users. Having an incident won’t necessarily make you untrustworthy. But, handling it poorly will. Your customers will be able to immediately recognize if you’re actually trying to do what’s best for them, or just what’s best for you. 

The importance of preparation

If you’re coming across this post in your hour of need, there’s enough here to help you through it. If you don’t need it yet, you’re in luck. You have an advantage that most don’t: you get to spend time preparing, rehearsing, and improving. Every minute you spend on preparing to do this, before you actually need it, will save you hours when the time comes. Spending even 15 minutes of pre-work on this with your executive team and your board allows you to set their expectations and align their efforts in a way that might not be possible during an incident.

Organizing your team of partners

You are about to do something really important and really hard: communicate nuanced information to a group of humans. This is not the time to, and I cannot stress this enough, “just wing it.” You need help. You need a team of partners from across your organization.

Your legal and privacy teams will help you understand who you are legally required to notify about this incident, and when. Keep in mind, this is the floor for notification, not your final list. Doing the absolute minimum required by law is not your goal. Protecting your customers, and the trust you’ve built with them, is. A good legal and privacy team understand this. Great legal and privacy teams live it. Lean on them to help guide you on this.

You need a communications professional. Hopefully your organization already has a comms team. If not, you can get outside help. There are many great firms to choose from. If there isn’t time to prepare, look to find someone who specializes in crisis or reputation management communications. Google around, or have your legal team check with their favorite outside firm. You can find one pretty easily. They will be expensive. They will be worth it. A comms team will help you work through how to say what you need to say, not just to customers and the press, but also to your own organization. Your customers or users will not react well to hearing about an incident from someone else first. Your colleagues will think even less of it.

Your customer support organization will help you understand how to see events through the lens of your users and customers. What you share with your customers through your disclosure will help minimize users reaching out to support, but don’t assume it will eliminate it. Your support organization needs to know what has happened, and what you’re doing about it, so they can be prepared with information, instructions, and even new help center articles if necessary. 

Your executive team will need to be informed of what happened, and you should brief them on what you’re doing next. It’s OK (great, in fact) if the exec team wants to be involved directly. But, if you expect them to drive the entire process for you, you’re going to have a bad time.

Determining your message and medium 

Should you just send an email? Should you publish a blog post? Share a deep technical Post Mortem? All these things are great. But it really depends on what has happened and how customer or user trust might be impacted. A simple mistake is a good candidate for an email. But, an email is simply transactional; something bigger requires more transparency. A blog post on your corporate blog is a great way to let everyone (current and prospective customers or users) understand that you are transparent and accountable. Think about what avenues you have for engaging directly with your customers, members, and users. Put yourself in their shoes and think about how you’d like to receive sensitive (and perhaps even upsetting!) information—this can go a long way in maintaining trust.

This is one of many decisions you will help make that falls onto the spectrum of deciding what is right vs. what is easy. Not every right decision is hard, but not every easy decision is right. There is no simple formula here. Trust your partners, your team, and (most of all) trust your instincts.

Content and Tone

Whatever the medium for your message: be clear, be direct, be concise. People need to understand what happened, what you’re doing about it, what they need to do about it, and finally, where to go if they have questions. This is not the time to add fluff or share your emotions, but do remember you’re speaking to humans and it should sound human. Apologizing is a good idea. But keep it crisp. 

Also, as a personal favor, try not to say “Your security / safety / privacy is important to us.” It sounds every bit as comforting as “Please hold; your call is important to us.” The fact you’re writing this email means it’s important to you. Ultimately it’s your customers or users that will decide whether they think their security is important to you by how they respond to your handling of this incident.

Explain what happened clearly. Platitudes and passive voice are not what’s needed. You’re not writing to avoid being blamed for something. You’re taking ownership. This is where your partners will be your biggest ally. It’s important to trust in their knowledge and the partnership built with them. Also, and this is important, apart from making sure legal requirements are met, your legal team should not be taking point on writing your messaging for you. This is the domain of your best friends, the comms team. Your legal and privacy teams are key partners, and crucial to helping be clear on what you can or can’t say, but the comms team will help find the best way to say what you decide needs to be said.

A blog post is for everyone, even if they weren’t impacted. The email is for people that you are sure or are reasonably certain were impacted. You can explain in your blog post that not everyone is impacted. However, in your email, you need to be clear and tell people directly if they were impacted. Do not dance around the issue. If they’re getting an email from you, don’t make them guess about why. Don’t say things like “may have” or “it’s possible,” unless you really don’t know. Even then, be clear about what you do know and what you don’t know.

Don’t transfer the problem to someone else. If your problem involved credentials in some way, do the hard part for them. Reset the password. Send affected users simple instructions on how to set a new one. If you’re emailing administrative users that may have many, but not all, users impacted, tell them upfront. Determine what you can securely provide, while following the right privacy practices. Then, proactively give them links to logs, a list of affected users, support articles, or other data they need to take action.

If the customer or user has everything they need to take action directly in the email, without requiring any further homework on their part, you have done well.

Timing is key

When to share your messages can be as challenging as what to say. Your legal and privacy teams are essential partners in identifying what notices are required and when. But, assuming no data has been breached, within those parameters, you may have choices: Do you rush sending something out the moment you discover the incident? Do you wait a week? A month? It takes time during an incident to establish sufficient understanding of the events and information about the impact to have enough to share externally. In the optimal scenario, you already have enough information such that you only have to reach out one time. 

If you’re dealing with something on the more serious side of the severity spectrum, it’s OK to share some initial details and send updates as needed. However, this will come with prolonged attention and a higher risk of confusing your customers/users with conflicting information. Your legal and privacy teams are your ally and close collaborator for understanding the optimal timing decision for your organization.

Whatever decision you make, optimizing on what’s best for your customers and users will always be a good choice.

“Go” Time

It’s time to ship it. If you’re taking any actions (e.g., resetting passwords), you should time them such that they happen just prior to any messages being sent. You don’t want your customers/users to be confused by a message that explains something that hasn’t happened yet.

Your comms team may make a recommendation to pre-brief media regarding the incident. This may seem scary if it’s your first time doing so, but it’s helpful for customers and the general public to understand what is happening. In the absence of transparency, people will assume you are being opaque because you are hiding something much worse. A good comms team will have your back. 

Once you’ve shipped your disclosure, you should focus on your internal teams and make sure they have your support, as now they may be taking questions from many places. Your comms and customer support teams have an important role here again. You should spend time with them creating answers for questions you expect so that whether someone is in sales, customer support, or engineering, everyone answering questions can stay on message and share the right details. Conflicting responses are the quickest way to raise the ire of your customers/users and attract the bad kind of media attention. If you’ve done a good job on your messaging, you shouldn’t have anything too unexpected to handle.

Don’t forget about the Post Mortem

When all is said and done, and people are starting to get back to their day-to-day, schedule time to run a “post mortem” meeting. Talk about the facts of the situation, talk about what you did, what you could have done better. No judgement, no blame. Take the lessons and apply them to your preparation and planning for the next time, because really effective security professionals understand that hoping bad things won’t happen isn’t as effective a strategy as ensuring you’re well prepared for when they do.

Takeaways

• It takes a village. You need to be accountable for this, but you shouldn’t do it on your own.
• Every minute of prep is worth hours of time and communication during an incident.
• Good comms speak for themselves. Spend the time to get it crisp.
• Remember, this is about taking ownership, not deflecting blame.
• Problems are not secrets and time is not your friend. The longer you keep a problem to yourself, the more damage it is likely to cause when it becomes known.
• Trust comes from what you do, not what you say. Do what’s right for your customers and / or users.