Security Incident Lessons Learned Checklist

Today we’re going to put a bow on our series covering different checklists for things you should be thinking about during each of the 5 primary phases of security incident response. We started with the identification phase and how to adequately capture information about a potential security incident to launch an investigation. We then covered the containment, eradication, and recovery from a security incident. Now to wrap us up, we’re going to jump into security incident lessons learned and all the things you need to think about following an incident.

This part of your response is arguably one of the most important, as the actions you take here are critical in improving your security incident response over time, helping you to avoid mistakes you’ve made in the response process previously, and ensure that all the important action items/take-aways to prevent future incidents are managed. So let’s take a look at some key items you should consider for your lessons learned process:

1. Is your incident documentation complete?

Immediately following the “hair on fire” portion of the response process, once you have eradicated the threat and recovered from it, you should ensure that all the documentation associated with the incident is captured and recorded. This should include a detailed incident report that captures all relevant details, action timelines, and remedial actions while everything is still fresh for your incident responders. A good read-through of the report after the incident will also help to clean it up and make sure everything captured is accurate and detailed enough. Security incidents should always be documented.

2. Have you held a lessons learned meeting?

Once you have a good handle on the documentation related to the security incident and your response actions, every incident should end with a lessons learned meeting. This is a chance for everyone that took part in the response process to take a look back and evaluate how you responded, could you have been more prepared, how can you prevent a similar incident in the future, etc. All of these topics should be discussed, the meeting should be documented (#compliance), and updates should be made to the Incident Response Plan, internal procedures, or relevant security controls.

3. Are all remediation/action items related to the incident being tracked?

Either during or after your lessons learned meeting, there should be a set of action items related to improvements that can be made to security controls, system configurations, documentation, etc. This list should be formally documented and tracked by someone to ensure everything is completed. Each action item should be assigned to a specific individual with an expected date of completion, to ensure nothing is dropped. This helps ensure you don’t see repeat incidents with the same root cause, as well as improves and streamlines the overall response process.

4. How can you improve the response process?

Part of the lessons learned meeting and those action items you are tracking should be focused on improving your documented Incident Response Plan and the associated procedures. Nothing helps improve your organizational preparedness quite like the real thing, so take advantage of each experience to improve the process. Make sections more detailed if you struggled to follow them during an incident, remove old or inaccurate content, update contact information or configuration details. Whatever it takes, each incident should be seen as an opportunity for improvement.

Hopefully these quick items that make up a security incident lessons learned checklist will help you create and continuously improve your incident response process. These topics are purposefully generic because of the differences in response processes between organizations, especially small businesses and large enterprises. So if you’re curious on how to best implement these in your environment or want to bounce some ideas off us, feel free to reach out and we’d love to help.