The Evolutional Leap from a Basic Incident Response Plan to an Executable Incident Response Program

The Evolutional Leap from a Basic Incident Response Plan to an Executable Incident Response Program

The Evolutional Leap from a Basic Incident Response Plan to an Executable Incident Response Program 1280 512 SethJaffe

By Seth Jaffe.

In the wake of the Equifax data breach, the time is right to revisit incident response. Dozens of authorities recommend incident response plans (you may have seen lists on my twitter feed or LinkedIn posts), but what does it really mean to have an incident response plan? Is it simply to check a compliance box? That may have been acceptable in the past, but with the cost of a data breach impacting not only the year’s bottom line, but also company reputation, companies cannot afford simply to hobble together a plan that sits in the back of the file cabinet.

In this series, we will deconstruct the facets of not just an incident response plan, but an incident response program, evolving from the commonplace esoteric policy document to the next generation enterprise response management platform. At the end of the day, the key to a good incident response program is execution. The elements of a program that foster effective execution will be the focus of this series, from team organization to training, from procedures to directives, from logging to attorney-client privilege, and from external to internal communication.

We invite you to take this journey with us, and we start with internal communication, a component rarely included in a conventional incident response plan. The publicly maligned sale of stock by Equifax executives days before the breach disclosure certainly did not reflect well for the company. Its blame on a lack of knowledge by the executives, if true, reveals an internal communication hole in Equifax’s incident response procedures. (6/13/18 update – at least one executive has been indicted on insider trading charges.)

Internal communication is one (among many) of the reasons why an incident response program should not be limited to the infosec group alone. At LEO, we also refer to it as “Enterprise Cyber Crisis Management” because the incident response team should include members from legal, public relations, corporate security, and human resources. And each of these groups, which I call “disciplines,” have their own set of executable procedures, reminding them, at the appropriate time, to provide updates to management.

What do these procedures look like? Who decides when to notify management, and to what fidelity? Can these notifications be protected from subsequent litigation discovery? How do you cut through the tautology and ensure the right information gets to the correct people? All good questions, which will serve as topics of future posts. In the meantime, I’ll leave you with the below graphic of a sample incident response team organization structure. Take a look and then consider your own team structure. Who is in charge? What are the goals of that person, what are his/her skill sets, and where are the communication bottle necks?