How to Create Incident Response Documentation

Cybersec Café #50 - 01/14/25

When sh** hits the fan, the last thing you’ll want to do is scramble to get organized.

Building out Incident Response documentation is essential for any Cybersecurity team before the incidents happen.

Or, if they have already been happening for a while now - it might be time to finally set aside an afternoon to build one out.

But why exactly do we need Incident Response (IR) Documentation?

For anyone who’s been a part of an IR team before, you’ll likely already know. But for those who don’t…

• Stay Organized - If you’ve been a part of a major security incident before, you’ll know that it gets crazy, and it gets crazy fast. It’s important to keep artifacts and action items organized so you know exactly where to find them when you inevitably need to reference back to them during the investigation.

• Central Source of Truth - Documentation provides a central resource detailing how all the pieces of the puzzle fit together for anyone participating in the investigation. It helps the everyonee stay on the same page. But, in order to get the full benefit of the document, it must be regularly maintained as the incident progresses.

• Compliance Purposes - The major Compliance frameworks (NIST, ISO, SOC 2, GDPR, etc.) have varying requirements for security teams to document their security incidents. So, if you ever want to achieve compliance with these frameworks, it’s best to start early.

• Historical Record - Just because you resolve one incident, doesn’t mean something similar won’t happen in the future. Having reliable documentation to reference back to in the case of any similarities can help bring a new incident to close significantly faster. Trust me, you’ll thank yourself later.

• To Make the Team Better - After an incident, it’s important to be honest with yourself. Your processes were probably great in some areas, but you also likely had shortcomings in others. Formally note and call them out to the team. Use each incident as a learning experience and an opportunity to improve.

As you can see, documentation can bring quite a suite of benefits to a Security Team.

So, let’s see exactly how to build one out to fill our requirements.

The Platform

My platform of choice is Google Docs.

Although potentially controversial, Docs provides one of the biggest benefits that you can have during an investigation: real-time collaboration.

No need to pull down the latest version, open a new Pull Requests, or save the file whenever you make a change - Docs keeps it simple

What’s also great are the other tools and features built into the Google ecosystem.

You have Sheets for creating spreadsheets (which you’ll definitely need at some point), and folders to segment permissions. Want to add a specific stakeholder to the investigation but don’t want them all of the artifacts? Easy - just share the document with them.

I also believe that as your security team matures, you’ll be looking for ways to automate your processes. The Google API makes this easy, and there are plenty of examples and robust docs to get you started.

Plus, the best part? It’s free!

---

- Today’s Sponsor -

Prepare for a career in Cybersecurity, one sip at a time with The Security Sip. With rapidly evolving threats and technologies, many struggle to gain the right skills and experience to break into the cybersecurity industry. This course is designed to transform beginners into industry-ready professionals over 12 sections, 85 modules, and 155 exercises. Check it out!

---

Building the Document

Building out a document that works for your team will be an iterative process.

What works for my team won’t necessarily work for yours.

But from my experience, my Incident Response Documentation Template and this article will give you the building blocks you need to get started.

Now, let’s break down the pieces you’ll need.

High Level Incident Tracker

This is the first thing team members will see when they open a document.

So, you’ll need to make sure people can see the current state of the Incident from a glance. It should include a Classification, a Severity, a Type, and of course, the incident name.

These are the values I generally default to, but don’t be afraid to change them as you begin to figure out what works best for your own document.

• Classification

  • Incident: Generally higher severity and involves customer data or data exposure of some kind.

  • Event: When incident response is needed to investigate, but data isn’t necessarily at stake.

• Severity

  • Low

  • Medium

  • High

  • Critical

• Type

  • Malware

  • Phishing

  • Data Leak

  • Vulnerability

  • Insider Threat

  • System Compromise

  • Physical

  • Other

This section should also include a warning about the sensitivity of the information on the document. Let users know to keep it confidential.

Executive Summary

The executive summary should enable stakeholders added throughout the investigation to come up to speed quickly. Update it regularly with major information, leading indicators of compromise, high-level investigation items, and key stakeholders.

Write a final draft at the end of the investigation, including the details on how it was brought to resolution.

Status Tracker

This portion differs from the header information because it is meant to keep track of the individual action items happening and the overall place in the response process.

It’s important to maintain a short description of the current state of the investigation. Keep it between 1-2 sentences.

Also provide a Current Status:

• Reported

• Investigating

• Responding

• Contained

• Resolved

• Recovering

• AAR/LL

• Closed

Include a table in this section to track action items, who is assigned, the status, and any notes needed for the person to close the item out. This will help you stay organized and informed on the different branches of the investigation.

Incident Info

This section should include a table with all of the necessary, high-level information someone may need to know about the incident.

• IR Lead - The leader of the investigation

• IR Second - The maintainer of documentation and assistant to the lead.

• SMEs - Subject Matter Experts brought in to assist in various portions of the investigation

• Incident Name

• Incident Reporter - Who reported the incident or how the initial report was received

• IoCs - The leading indicators of compromise

• Severity

• Product/Platform Affected

• Summary of Impact - Who or what is currently known to be affected?

• Summary of Resolution - How the incident was brought to close (leave this blank until it is actually resolved, stay away from theories)

• Incident Duration

• Quick Links

  • Related Tickets

  • Communication Channels

  • Important Documents

Artifacts

Use this section to paste artifacts or information that are integral to the incident.

Make sure to keep this section clean with clear labels and notes as to what artifacts are and why they’re relevant.

Include items like links, screenshots, queries, code blocks, or whatever evidence is necessary for the investigation.

Timeline

It’s important to keep an accurate timeline of what happened and when.

Incidents can take a while, there’s a lot of moving parts. You don’t want to rely on your memory when you need to construct a timeline of what happened.

Focus on documenting when artifacts are found, stakeholders brought in, key events, and significant findings.

Meeting Notes

It’s important for the IR Second to take notes during meetings.

It’s their job to ensure that information shared over voice and video calls are not lost in the chaos.

Keep items high-level. Don’t be afraid to over-document, it’s better to have too many notes than to not have something at all.

Brain Dump

This Brain Dump is great for when things are happening quickly and you just need an area to write things down.

When an incident is closed out, all items from this section should either be moved to another relevant section, or deleted altogether (most likely the Artifacts section).

The entire section should be removed after the investigation is closed to keep the documentation neat.

Technical Resources

Some incidents may affect systems or software that you’ve never worked with before.

Use this section to paste useful resources you find along the way to understand the tech stack. Your team will likely find it helpful too.

Specialist Section

This section is meant to be filled out based on what is present in your environment.

You’ll want to build out items as you identify areas where security incidents could happen.

This could be things like cloud infrastructure services, application code, hardware–whatever you need to prepare for when the worst happens.

AAR/LL

The After Action Report, Lessons Learned, Retro (whatever you want to call it) is just as important, if not more important, than the Incident Response process itself.

It should be used to formally identify the root cause and determine action items for improvement.

Everyone who was involved in the incident and any additional key stakeholders should be present for this meeting.

I like to conduct my AAR sessions in 4 parts:

1. Root Cause Analysis - Formally document the root cause for the incident. Ensure everyone is in agreement.

2. AAR Matrix - These are general questions I like to ask about every incident with standardized answers. It’ll allow you to get an idea of how smooth the response went from a glance.

3. Discussion Items - Paste improvement items actively in this during the investigation. Return to them for discussion during the AAR. These should be incident/response specific items that need to be talked about in depth.

4. Improvement Plan - Take time to create action items to solve problems you ran into during the incident.

How to Use the Incident Response Documentation

In order to get the full benefits out of Incident Response Documentation, you need full buy-in from the entire team.

Creating the doc template to fit your organization’s needs is the first step. Again, every organization is different, and only you know what you’ll truly need.

The next step is maintaining the document during an investigation. If stakeholders continue to document artifacts in their own spaces, you won’t get the full benefits of having a central source of truth. Every platform will have its pros and cons - whether it’s Google Docs or not. At the end of the day, choose which platform provides the least friction to the team.

The last step is the AAR. Holding a live meeting after an investigation is important to call out the wins, but also the opportunities for improvement. It’s necessary for everyone involved to buy in and participate in this as each member will have their own perspective and you’ll need to build solutions as a team.

—

I hope a major security incident never happens to you. But if it does, I hope my Incident Response Document and this article can assist you in your time of need.

---

Securely Yours,

The Cybersec Cafe

---

Just a heads up, The Cybersec Cafe's got a pretty cool weekly cadence.

Every week, expect to dive into the hacker’s mindset in our Methodology Walkthroughs or explore Deep Dive articles on various cybersecurity topics.

. . .

Oh, and if you want even more content and updates, hop over to Ryan G. Cox on Twitter/X or my Website. Can't wait to keep sharing and learning together!