The Importance of an Executable Incident Response Plan, and How NASA Can Help

By Seth Jaffe.

Brian Harrell had a good piece this week on improving cybersecurity governance in the boardroom, a topic that we routinely blog about in our Cyber Governance Corner Series. So why am I mentioning a governance article in the Incident Response Series? Because Brian opines, in his article, that “[c]ompliance is a regulatory minimum that one must achieve, . . . but it is not a cybersecurity strategy.” In the world of incident response plans, I believe that to be a true statement.

I periodically list, on my Twitter and LinkedIn accounts, authorities that require or recommend incident response plans. But what do they mean by putting a plan in place? New York’s Department of Financial Services, one of the more recent entities to mandate a plan, explains in Section 500.16 that an “‘Incident Response Plan’ requires each Covered Entity to establish a written incident response plan designed to promptly respond to, and recover from, any Cybersecurity Event.”

In my view, the phrase “promptly respond to, and recover from” defines the plan. This is another way of saying that a plan must be “executable,” that any team member can call up the plan and more or less have a step-by-step guide through the common tasks of incident response.

LEO’s incident response program was born from NASA’s Mission Control framework, where I spent nearly a decade and a half flying spacecraft. But it has proved to be a perfect foundation for incident response. In his recent book, by old boss and former director of mission operations, Paul Hill, sets the basis for the Mission Control Center (MCC). Originally, it was derived from the aircraft test community, but as vehicles became more complex, the telemetry and decision-making points outpaced the capabilities of a single person. Mission Control was created to digest a huge amount of information, funnel it to the decision maker(s), and subsequently push decisions to the correct person to carry out the action. Fifty years later, MCC is an entity like no other, and one from which I believe the incident response community can steal a few tricks, given that we face similar issues. We will discuss some of those processes in subsequent posts, but for now, let’s focus on the concept of execution.

NASA realized early on that no one person can handle the complexity of flying a spaceship. I think that translates accordingly to a data breach, which can become unruly in a short amount of time. I remember sitting in MCC as a trainee, scared to death because I noticed a vehicle system failure, but couldn’t remember what to do. I’ve seen this happen to team members during an incident as well, but they did not have the luxury of calling themselves trainees.

Fortunately, NASA put in place step-by-step procedures, the practice of which has a number of benefits. First, procedures shake a frightened team member out of his/her “deer-in-the-headlights” trance and get him/her moving again. Second, they dramatically reduce errors. Third, they offer immediate insight into tasks upon which other team members are focused. Fourth, procedures decouple the housekeeping sections of a conventional plan to provide an actionable document for the team member. Fifth, they act as a concise training and certification tool. Sixth, they can be discipline specific, such that each section of an incident response team has its own book of procedures, focusing on that section’s core responsibilities (and strengths). And finally, the compartmentalization of procedures makes updating the plan easier.

We’ve seen the damage a botched response can do to a company. Equifax’s CEO is out, its CIO and CISO gone, stock down 25%, and some are estimating that its liabilities are greater than its assets. Anthem suffered, as did Target. On the flip side, some companies like Adobe and Home Depot weathered their breaches in better fashion. Why that is the case is beyond the scope of this post, but having a seasoned incident response team with a concrete, executable plan goes a long way. In subsequent posts, we will take a look at examples of procedures and also discuss the concept of directives. In the meantime, subscribe to our RSS Feed at LEO Cyber Security, or follow me on Twitter or LinkedIn.

Seth is our official rocket scientist in residence. Hailing from NASA’s Mission Control Center, Seth brings a unique perspective to incident response, applying aspects of one of the world’s preeminent emergency operations platforms to cyber response. In addition to twenty-plus years’ of technical experience, Seth was previously a member of the data protection task force at a large law firm, and served as the lead Legal team member of an incident response team at a major U.S. airline. Seth is a certified business continuity professional, and he holds a juris doctorate, which is why he also wears the General Counsel hat at LEO.


  1. […] of concrete, step-by-step procedures. I’ve written about the need for procedures before, here and again here. Benefits include concrete direction for team members, faster references to […]

  2. […] response concluded that a shift toward executable incident response plans is warranted and the follow-up article laid out reasons for decoupling procedures from the overarching incident response policy document, […]

Leave a Comment