DFIR Note-Taking and Report Guide

/ ChocolateCoat

Main Takeaways

  • Useful Note-taking and reporting requires explicit planning and goals.
  • Organizing information is just as important as the content.
  • Tips have been collected into the DFIR Notetaking Cheatsheet on Github.

Introduction

Since I’ve been working in DFIR full-time, I’ve been on a mission. I want to answer a question, a key question, I’m sure everyone has had.

“How do I write a report that is actually useful?”

This led to even more questions that were just as important to answer.

  • “What do I write?”
  • “How do I write it to be appealing?”
  • “What do I want them to do after reading it?”
  • “Why do analysts hate documentation?”
  • “Is documentation even important if decision-makers rarely read it?”
  • “Why is it so hard to find good resources on this subject?”

Today, I’m going to seek to answer these questions. While I do this I hope I can show you why documentation is crucial and a skill anyone can develop. In addition, it will absolutely improve your ability to analyze and interpret evidence. If you want more practical steps then take a look at my post about the ADAPT framework and my DFIR Templates GitHub. I promise it will have at least one thing you can takeaway and apply to your work.

Why is it so hard to find good resources on this subject?

To start this off, I’m going to work backwards. There is hardly no guidance when it comes to good report writing in relation to incident response (IR). For digital forensics we have a few wonderful standards and resources developed that can be helpful but not quite what we need.

The problem is IR and most cybersecurity note-taking/reports have very different expectations. The intended reader for a forensically sound report is the court of law, but for IR it is decision makers. Decision-makers are folks like executives, managers or even technical peers. The key difference in my opinion:

The court of law needs to validate every step you took to ensure your conclusions are accurate.

Decision makers are not there to validate your steps, they want to know what your conclusions are and what they need to do about it.

So it doesn’t always make sense to create a perfect forensic report when it doesn’t accomplish the goal of incident response. I hope my little blog will be a helpful starting point for incident responders whether you do DFIR full-time or an incident finds you.

Is documentation even important if decision-makers rarely read it?

Yes.

Ok fine, let’s talk about it. Decision-makers are not reading it because they are not receiving the information they want. If your report provides details they want, then you will get more readership and meaningful actions based on what you found. Here’s a few ideas of what I have found decision-makers want to see.

  • Summary of what happened right at the top AKA Executive Summary
  • What was impacted? Be specific.
  • What else needs to be done?
  • What decisions do they need to make?

The easiest way to find the right questions is to ask them. Seems simple, but I guarantee no one has ever asked them the simple question. “What do you want to see in incident response report?”

First thing you need to do if figure out who will be reading your reports. From there you can craft what elements would be most important to them. This doesn’t mean you don’t include technical analysis, it just helps you prioritize what to have at the top.

Why do analysts hate documentation?

Brett Shavers wrote a pretty great blog post about this.

Here comes Brett’s opinion…
People don’t take notes because:
*  lazy, or
*  fear, or
*  believing notes are unimportant, or
*  no one makes them

Brett’s opinion on DFIR notes and note-taking

I’ve always resonated with this, in fact it was one of the posts I read that really made me dive into this topic more. If I had to add one thing to this, it would be “never being taught”.

Good note-taking and reports are assumed to be something you can do. We don’t really have courses focused on taking good notes and translating them into reports. Instead it becomes trial-and-error in a situation where “trying” may not be enough. This discourages folks especially when the first exposure to writing a full report is after an arduous incident. That’s why I’m here to give you that exposure and training. If you’re reading this you are already well ahead of the game.

What do I want them to do after reading it?

Two words. Take Action. I know we want to be as objective as possible, but I guarantee you already know what you want the reader to do. Here’s a few ideas.

  • Pay me more…
  • Buy that tool I’ve been asking for and would’ve clearly helped here
  • Take the list of IOCs and make new detections
  • Decommission that old server that we cannot protect
  • Hire more personnel so we can get things done
  • Stop using this vulnerable application
  • Centralize our logs so we have better visibility
  • MFA, MFA, MFA

Keep that objectivity with your analysis, but reporting should have clear calls to action. Just make sure your findings support the actions. Do not, I repeat, do not interpret this to mean shape your notes and reporting to only fit an end goal.

How do I write it to be appealing?

Reports have a reputation of being ugly, but they don’t have to be! My new Note-Taking Cheatsheet has some tips (linked above). However I suggest you start with this great video by Lenny Zetsler.

While his focus may be more geared towards Cyber Threat Intelligence (CTI), it still has plenty of tips that apply directly to a IR report as well.

Another rule I would add and try to follow is the two-paragraph rule. You should only have two paragraphs of text before you add some type of visual to reduce strain on the reader’s eyes. This can be using tables, screenshots, bullet points, or even code blocks. I even tried to do it in this post, but don’t worry about being perfect just put in the effort.

What do I write?

Personally, I use the word “finding” and I ensure I write down every one. A finding can be any suspicious or unique event. Notice I did not say “malicious”, just anything that stands out for the normal activity. Keep in mind a lack of findings is also relevant and should be note. My ADAPT process helps give clear steps on how to reach this point.

For each findings document these five details to ensure the notes are complete:

  1. Timestamp
    •  Use UTC to avoid time zone confusion between evidence sources.
    • Use ISO 8601 format (e.g., 2026-07-16T16:20:00Z).
  2. Evidence Source
    • Identify where your findings originated (e.g., query, registry key, or console).
  3. Event Description
    • Provide an objective statement of the fact.
    • “A new service named ‘Updater’ was registered”
  4. Context
    • Provide subjective analysis, explain why this is relevant or suspicious
    • “The binary is in a \Temp directory, which is atypical and commonly abused by threat actors.
  5. Visual/Proof
    • Include visual data like command lines, log entries, or screenshots
    • This can even be something simple to break up blocks of text (e.g., bullet points, tables, or charts)

How do I write a report that is actually useful?

This question should feel a lot less daunting now. So let’s summarize.

  • Write for the reader, not just yourself
  • What would get the attention of the reader?
  • Separate technical findings from an executive summary, mixing the two often leads to confusion or lack of interest on both sides.
  • Make your report visually interesting, no one likes pages of text

Conclusion

So that’s my rant. I hope this guide helps improve your writing in a less intimidating way. To summarize all this, I’ve put together nice and tidy cheatsheet. Keep this handy as you go about writing your notes and reports.

Happy Documenting!

Terryn Valikodath

Twitter: @CyberCoat

Mastodon: @ChocolateCoat@infosec.exchange

LinkedIn: terrynvalikodath

BlueSky: @ChocolateCoat

Leave a comment