Writing an After-Action Report (AAR)

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *

Already have an account? Sign In »

5 hours 19 minutes
Video Transcription
less than 6.3. Writing an after action report.
The objective for this lesson is understanding how to properly right an after action report commonly called on a A are and what the contents of in a a R should be.
We've mentioned already doing the debrief, and it's important during that debrief meeting that good notes are taken. We want to use those notes from the debriefing to help guide the A A r and what contents we will be putting in that report.
The focus of the A R is not to place blame, though, or attribution, but it's really to focus on what went well
and what needs to be improved. Commonly, you'll see in a are things like opportunities for improvement or OEF eyes and maybe even findings that air significant gaps that are identified
when you construct the a r thes air. The sections that I recommend putting in here on there's 10 of them. The first is the executive summary. So this is going to be the quick one or two paragraphs of executive summary on the incident, the debrief and what's going to be in the report.
Number two, who are all the participants and the I R team members and by I our team. I don't mean just those that are full time incident responders, but anyone who was involved in the actual response and this could be full time people in cybersecurity It could be folks from I t that have a collateral duty
could be others that you pulled in to assist.
You want to make sure all of those people are identified within the report.
Number three is the incident timeline in details. When I write thes, I always like to have a really nice graphical timeline of when we first notify were notified of this all the way to the debriefing and all of the major milestones and events and investigative findings
are detailed within that timeline.
Impact assessment is another section. So how bad was this? How did it actually impact the organization in that sort of thing?
Root cause analysis is extremely important and what a lot of the executives were going to be looking at, and it actually takes a little bit of practice and skill and knowledge to truly right a full root cause. Analysis.
Number six What are the lessons learned out of this number. Seven. How effective was our response to the incident?
Eight. What are those O. F eyes or opportunities for improvement that I mentioned before? Nine. What are the identified gaps? These may be called findings or just simply identified gaps
however you want toward this. But we definitely want to talk about the gaps that were highlighted in this incident. And then what's our next steps? What are our recommendations and maybe even a road map on how we would
I suggest, or recommend that we get to where we, in our opinion, believe we need to be now? This might be a good time to do some sort of ah maturity assessment of your organization. There's a lot of ways to do that. You could do You use the nest CSF.
If you're a client of somebody like Gartner, you could use their I t score for information security,
or there's plenty of other free tools out there as well. That can help you, but always try and use a known framework to guide these discussions and decisions. You could also use outside consultants to come in and help identify your organization. Of course, that's gonna cost you some money. But
if you can go to the leadership and have as part of your a r
clear gaps that were identified, the impact that those had on the organization and then say But we've also come up with a solution
to address these gaps. We had somebody else come in from 1/3 party point of view confirmed. These are in fact, gaps for us were less mature than we really should be for our size of organisation. And we believe we need to implement the following people, processes and technologies to close that gap.
This is hypothetical. Maybe everything went great. Maybe you do have gaps, but it's not gonna cost any money. You just need to write some policies or create some work flows.
But you can see where I'm going with this too. Is don't ever let a breach go without capitalising on it. If in fact there is a reason to do so.
So in summary, we talked about how to properly right in a are and what are the contents that should be included in that a r.
So a quick question for you on this all of these air recommended sections within an A R except A. Participants and I, our team members
be incident, timeline and details
see opportunities for improvement or D the names of individuals who made mistakes.
As tempting as it may be to write the names of people who made a mistake, that is not the appropriate time or place for that in an a r. So we're going to leave that out and make sure the other three things are within your report.
Up Next