Writing an Effective Security Incident Response Procedure

If you're a chief information security officer, you need to write security incident response procedure documents (I'll call them SIRPdocs). And your job can depend on the ability to write them well---Gartner suggests that up to 75% of CISOs who suffered publicly documented security breaches without well-tested security plans may have lost their jobs in 2016. Often these documents are dense and technical, with too much material before the actual instructions for an incident response even appear.

So it's worth it to look at guidelines on writing these. Unfortunately, the guidelines a CISO may come across can themselves be overly technical and complex. Here are Gartner's tips on writing an effective SIRPdoc, which helps simplify the process.

 

Keep Focused Goals in Mind

It's important to remember the point of this document and who will be reading it. A SIRPdoc addresses an immediate security incident. The people who need to respond to the document will be reading it under time pressure and stressful conditions. A good SIRPdoc will be simple enough to allow for quick and fluid reading, yet detailed enough to convey the necessary information for any required compliance regulations. Ideally, it will also provide the framework for new kinds of security incidences, since they will continue to evolve. Having a foundational SIRPdoc can serve as a sort of template and practice tool before incidents come up as well.

Gartner's Five Best Writing Practices for Security Incident Response Procedures

1. Keep language simple.

This writing should be concise and direct--it's not the place to explore poetic ruminations or to show off your vast technical vocabulary. You should be thinking of flowcharts, diagrams, and tables rather than chunky paragraphs.

Use active, commanding voice. Let's compare this to a real-world emergency situation where someone has stopped breathing. CPR instructors will tell you that the first thing you need to do is get someone to call 911. You don't want to mumble, "Emergency personnel should be contacted..." Instead, point to the nearest person and say, "You! Call 911 now!" Similarly, tell your security response team exactly what they need to do.

2. Know who's reading the document.

Expect your readers to have general IT incident response knowledge. Make sure your terminology matches general problem- and crisis-management processes. Again, using highly specified language will only fog up responders' thinking and slow down response time.

3. Consider the pressured environment it will be read in.

Most of the time your response team will be reading the SIRPdoc within five to ten minutes after identifying the incident. Stress levels will be high, and the team will feel anxious to take the steps they need to in order to resolve the problem. Using charts and listing clear steps will visually decrease the chaos of the situation, giving the team clarity and confidence--as well as instructions that they will follow quicker.

4. Be ready to address real-world and enterprise-specific issues.

It's important for SIRPdoc authors to use scenarios that are likely to happen. Sometimes these emergency documents address a broad range of possible scenarios, leaving readers to sift through unrealistic threats before they get to the urgent matter they're actually concerned with. It's a good idea to have a procedure in place for a few specific incidents of a similar type, as well as a more general (and realistic) procedure for incidents that aren't included in that one.

5. Focus on the consequences rather than the causes.

Of course, you will want to pinpoint the causes of incidents and work to prevent them in the future. Just don't do that here. In an emergency response situation, the team will need to focus on what the problem is and what to do about it--not why it happened. Once they've responded successfully to the incident, you can consider cause and prevention in a less time-pressured setting.

 

A Sample Structure for Security Incident Response Procedures

A clear and effective SIRPdoc might look something like this:

1. Title, classification, and a bullet list of a few specific actions that need to be taken immediately, such as: a) Spend five minutes reviewing the information you have available. b) Brief the two most important team members who will be involved in responding to this issue. c) Follow the flowchart provided.
2. Flowchart for general incident response or
3. Flowchart for specific incident type
4. Telephone list or calling tree for informing relevant staff members
5. Appendices with other relevant documentation and/or more detailed explanation of flowchart material

 

Be Ready

Finally, once you have a procedure in place, test it. Organize roundtable exercises and run potential scenarios, checking to see whether your SIRPdoc gives clear and adequate instructions. Be sure to include anyone who would participate in the response if such an incident actually occurred. Security incidents will inevitably come up, so it pays off to be practiced and prepared, with a great security incident response procedure ready to go.

For more on security preparedness, take a look at our discussion of the Zero Trust security model.