Last updated: 
1 week 1 day ago
Blog Manager
One of Jisc’s activities is to monitor and, where possible, influence regulatory developments that affect us and our customer universities, colleges and schools as operators of large computer networks. Since Janet and its customer networks are classified by Ofcom as private networks, postings here are likely to concentrate on the regulation of those networks. Postings here are, to the best of our knowledge, accurate on the date they are made, but may well become out of date or unreliable at unpredictable times thereafter. Before taking action that may have legal consequences, you should talk to your own lawyers. NEW: To help navigate the many posts on the General Data Protection Regulation, I've classified them as most relevant to developing a GDPR compliance process, GDPR's effect on specific topics, or how the GDPR is being developed. Or you can just use my free GDPR project plan.

Group administrators:

Crisis Communications for Incident Response

Thursday, June 25, 2015 - 10:43

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.