If your organization has experienced a breach, running a Lessons Learned session may help you gain insight into how to prevent or respond more effectively to another attack. Unfortunately, companies may get hit multiple times, once hackers see a successful attack. The healthcare industry traditionally has slightly older technology, so that’s one of the reasons they are often more vulnerable.
Lessons Learned Phased Approach
When an organization applies the Lessons Learned approach, they distill valuable information from an experience, such as a process or event (see Lessons Learned: Use It to Enable Your Business Strategy.) The Army, which has been using the method since 19851, states that its program “provides the foundation for all Army organizations to maximize the benefit of experiential learning to change behavior and improve readiness.”2 The program includes four phases:
During the Discovery phase, the team discusses something that could be improved, such as a process for communication or a technical solution. It is important to obtain a variety of viewpoints. This allows the team to see an issue more holistically.
The Validation phase allows others to pressure test the suggestion from the previous phase, and see if it could be implemented. Here again, it is beneficial to gather input from team members with varying levels of experience.
Within the Army’s framework, a lesson can be “adapted or applied” to an organization in the Integration phase. There could be work at the department or division level, and then those learnings get incorporated into a larger plan for the organization.
Finally, during the Assessment phase the team determines whether or not the lesson was successfully integrated into the work. If the new lesson was only partially successful, there’s an opportunity to send it back to the prior step and revise it, before moving it to get reevaluated. If the lesson is successfully implemented, the team considers it “learned” and it gets recorded in a repository that everyone has access to so others can refer to it when they face a similar experience.
Applying Lessons Learned to Cyberattacks
So how does one apply the process above to a cyber event? After the attack, consult with your leadership and response teams, to determine the best time to hold the session. We recommend a few weeks after your recovery efforts are underway, so you aren’t pulling people away from time sensitive tasks. Scheduling it during lunch hour (and providing the food) is an easy way to gain more participants.
Draft some basic questions in advance, and share them with the team, so they have time to think about it ahead of the session. Be prepared to improvise additional questions after the discussion is underway. It might be helpful to create a list of categories such as infrastructure, physical security, training, etc., that will help you structure the conversation.
Once you’ve gathered the members of your response team, ask them to describe what happened during the attack. The first few hours will be critical, because that’s where a lot of the issues may arise. As you listen to their responses, also be aware of what topic you are not hearing them mention, and make a note so you can ask about that later.
Depending on how many people are in your session, you may want to recruit someone to assist you as a scribe. You may prefer to write notes by hand first, and then typing them up later. You can jot a quick note in the margins, or circle something that you want to return back to for additional questions or clarification. Experiment to find the technique that best suits your work style.
While your team is providing their recaps, there may be times when the recommendations are clear cut and come up organically as the team speaks. Before you conclude your session, check in with the team and see if there are any last minute thoughts. Ask the team what they would have done differently at various points of the crisis.
After your session, organize the content. Feel free to move part of the text around, to better structure your narrative. You may want to go back and talk to a team member to elucidate a particular point once your document is underway. Working on a final report over several days, enables the team to read through it and make small adjustments.
Finally, go back and share the report with the organization. Identify what lessons need to be enacted, and collaborate with team members to resolve them. Post the report and lessons in an appropriate repository.
Good luck! Do you have alternatives to the Lessons Learned process that you’d like to share? Please respond below in the comments section.