Responding to security incidents, whether they are malicious or accidental, requires a final step that many organizations neglect. An After Action Plan (AAR) helps to reduce the probability of a recurrence and improve response activities. Tom Olzak shows you how to execute a standard AAR.
After Action ReviewsAAR's begin with a post-incident meeting to discuss what happened and why. Benefits of implementing AARs include:
- Root causes are identified using input from multiple perspectives
- It assists employee development by examining better ways to get to goals and objectives
- Performing AAR's on both successful and unsuccessful activities results in not only achieving expected outcomes—it can also result in reaching them with greater consistency
The AAR process answers five basic questions:
- What was supposed to happen?
- What actually happened?
- What were the differences?
- What are the lessons learned?
- What do we do to prepare for the next time?
The answers to question 4 provide input into a knowledgebase to which employees refer when dealing with similar incidents or tasks in the future. The answers to question 5 make up an action plan to improve processes, conduct additional team training, and to modify or add controls.
How NOT to conduct AARsAARs are valuable only if common pitfalls are avoided. Actions taken or wrong attitudes brought to the meetings can get in the way of identifying what to fix and how. In addition to trying to place blame on an individual or team, other ways to derail an AAR include,
- Getting stuck in the process, preventing a free exchange of ideas about what happened and why. Many AAR methodologies provide a step-by-step approach to running a fact-finding meeting. Methodologies are good guidelines, but they shouldn't discourage free and open discussion. For example, if the team starts brainstorming, generating a good flow of information, the meeting coordinator shouldn't stop the discussion because it doesn't strictly conform to the dictates of the selected AAR method.
- Managers influencing responses, resulting in solutions that don't reflect the insights of the team members who actually did the work. In some cases, keeping managers out of the room until issues are identified and causes thoroughly discussed provides the best results.
- Discussions in the meetings are not confidential. This causes the team members to refrain from contributing to the improvement effort for fear of angering management and peers.
A successful AAR process
Two sets of AAR behavior guidelines—one for management and one for employees—help avoid common pitfalls.
- Remain unbiased
- Ask a lot of questions with the sincere intent to learn as much as possible from every team member about the activity under review
- Refrain from placing blame on individuals or groups
- Let the team members offer solutions
- Managers should not "manage" during the AAR
- To help ensure less management influence, a non-management team member should facilitate the AAR
- Keep blame out of the room
- An AAR attempts to answer what and why, NOT WHO
- What is said in an AAR is confidential
- During an AAR, no team or individual rivalry is allowed
- Do not refer to actions taken as successes or failures
In addition to the behavior guidelines, the meeting format is also important. Instead of being formal and structured, problem solving meetings usually work better when they're informal brainstorming sessions. This doesn't mean there shouldn't be specific objectives. But an AAR meeting facilitator can achieve stated objectives by asking the right questions at the right times instead of strict adherence to some arbitrary meeting framework. The following is a list of questions a facilitator can use to guide him or her to achieving productive outcomes. (Mission-Centered Solutions, 2002).
- When was the problem realized and by whom?
- Were there indicators? If so, what were they?
- Was there information in the recovery or project process that enabled us to understand the indicators?
- Who was aware of the situation and who was not?
- How was the problem communicated?
- Was there a difference in how the various team members viewed the problem?
- What was the REALITY of the situation? What actually happened?
- How effective was the option selected to deal with the problem or to accomplish the task?
- What was the reasoning used to select the selected recovery or project option?
- Were critical risks identified in advance?
- Was the action to be taken effectively communicated to the team?
- How well were the technical tasks performed?
- How successful was the recovery or project option at achieving the desired result?
Again, this list of questions is just a guideline to ensure the right information is gathered. And even though the question of "who" comes up several times, the intent is still to identify what happened and why—not to place blame.
The action plan
The outcome of one or more AAR meetings is a list of processes or technologies requiring remediation. Each identified weakness should be listed in an action plan for managed correction. (A sample action plan, in Excel format, is available for download at the end of this post.) The action plan doesn't have to be complicated, but it should contain at least the following information on each issue:
- Priority - Issues should be prioritized based on risk. In other words, remediate the issue that eliminates the most risk first.
- Remediation activities - There might be more than one remediation activity per issue. For each activity, the following information should be tracked in the action plan:
- Resources assigned
- Status of remediation
- Scheduled completion date
- Date issue remediation was complete.
The final word
AARs are necessary if an organization wants to learn from experience. Initial attempts will be rough, and outcomes might be far less than perfect. Over time, however, AAR activities improve, providing an incremental path to continuous improvement.Downloads