Crisis Communications for Incident Response

Scott Roberts of Github gave an excellent talk on Crisis Communications for Incident Response. If you only follow up one talk from the FIRST conference, make it this one: the slides and blog post are both well worth the time. So this post is just the personal five point plan that I hope I'll remember to re-read whenever I’m involved in communicating around an incident:

• Be Clear: You’re explaining to semi-technical and non-technical people. Style should be "Fifth-grade level" or, for the international audience, early Harry Potter. Stay consistent across all messages and media. Don't try to name the attacker – it doesn't help.
• Be Timely: Which doesn't mean sooner is better: if you have to send a continuous stream of corrections/amendments, then you look confused. Revising upward the scale of an incident isn't good. Nor is being so slow that Brian Krebs reports the incident before you do.
• Be Actionable: You need to tell people clearly what you are doing to remediate the problem and to protect users, how they can determine if they are affected and what they need to do if so.
• Be Responsible: Admit what went wrong, show you understand, say sorry. It's worse to pretend you are in complete control and things still went wrong, than to admit you made a mistake. But don't over-apologise, so you need to work with security, PR, legal and customer support to get this right.
• Be Human: You want recipients of your message to empathise with your plight. That won't happen if your communications are written in legalese or jargon, or by a committee. Getting feedback to correct errors and clumsy wording is fine, but try to stick to a single author as far as possible. And before you send it, read it again, and again out loud.