Lesson 9 — Another Analyst Has to Read Your Notes Tomorrow
You understand the incident because you have spent the last hour investigating it. Tomorrow morning, another analyst may know none of that.
Your notes have to preserve the facts, the reasoning, the pivots you followed, what you ruled out and what still needs to be answered.

Your shift ends in 20 minutes
The incident is still open. Another analyst will take it tomorrow. They need more than a list of alerts.
Case briefing
Investigation objective
Write investigation notes that preserve facts, reasoning and outstanding questions so another analyst can understand the case and continue without repeating your work.
Investigator's rule
Write for the analyst who was not in the room. Do not rely on memory, portal history or unexplained shorthand to carry the investigation forward.
Stage 1 — separate observation from interpretation
| Weak note | Better note |
|---|---|
| User hacked. | User stated they did not recognise the sign-in. Authentication and endpoint evidence remain under investigation. |
| Bad PowerShell. | powershell.exe executed on ADM-LT-004 at 12:11 with an unexpected command line and subsequent external connection. |
| Attacker moved laterally. | A second privileged identity was observed from the same source IP. Relationship has not yet been confirmed. |
| Looks malicious. | Current evidence supports suspected compromise; no validated benign explanation has been identified. |
Facts survive handover
Timestamps, entities, command lines, alert IDs and observed actions can be checked by the next analyst. Your confidence and interpretation should be recorded separately.
Do not upgrade uncertainty
If lateral movement is only a hypothesis, write that. Notes become dangerous when “possible” silently becomes “confirmed.”
Stage 2 — record the investigation timeline
Time creates the story
A chronological note helps the next analyst understand sequence and causality much faster than disconnected observations copied from different portals.
Record the pivot, not every click
Document why you moved from sign-in to device, process to network or IP to another identity. Portal navigation history is not investigation reasoning.
Stage 3 — use KQL to preserve a compact evidence summary
KQL can help create a reproducible snapshot of important events for the handover. The query is not the note; it supports the facts recorded in the note.
let TargetDevice = "ADM-LT-004";
DeviceProcessEvents
| where Timestamp > ago(24h)
| where DeviceName =~ TargetDevice
| where FileName =~ "powershell.exe"
| project Timestamp,
DeviceName,
AccountName,
FileName,
ProcessCommandLine,
InitiatingProcessFileName,
InitiatingProcessCommandLine
| order by Timestamp asc
Make evidence reproducible
Record useful query logic, filters and time windows when another analyst may need to reproduce the result. “I saw something in Advanced Hunting” is not enough.
Do not paste telemetry without explanation
A hundred rows of raw events can hide the point. Summarise what the evidence demonstrates and preserve the query or identifiers needed to verify it.
Stage 4 — document what you ruled out
| Question tested | Result | Status |
|---|---|---|
| Was PowerShell launched by approved management software? | No matching approved parent process identified. | Benign explanation not supported |
| Did the user recognise the sign-in? | No. | Supports further investigation |
| Was another privileged identity involved? | Observed from same source IP. | Relationship unresolved |
| Was persistence confirmed? | Not yet investigated fully. | Outstanding |
Negative findings matter
If you checked for something and did not find it, record that carefully. The next analyst should not waste time unknowingly repeating the same test.
“Not found” is not “did not happen”
Write the limits of the evidence. No persistence found in the telemetry reviewed is more defensible than declaring that persistence did not occur.
Stage 5 — leave the next analyst a starting point
Lesson 9 key takeaways
- Investigation notes are part of the evidence trail.
- Separate confirmed facts from interpretation and hypotheses.
- Preserve important timestamps, entities and identifiers.
- Record why important pivots were followed.
- Document meaningful negative findings without overstating them.
- State the limits of the telemetry you reviewed.
- Use KQL to make important findings reproducible.
- Do not bury conclusions inside raw telemetry dumps.
- List outstanding questions explicitly.
- Give the next analyst a clear recommended starting point.
Module 1 — inside the SOC
You can now triage, collect evidence, pivot, decide, escalate and document. The final lesson in Module 1 brings the entire workflow together.
Continue your SOC Analyst training
🔎 SOC Analyst Academy — Module 1: Inside the SOC: Thinking Like an Analyst
How to write SOC investigation notes
Lesson 9 of the Agent Foskett SOC Analyst Academy teaches analysts how to document confirmed facts, investigative reasoning, negative findings, outstanding questions and next steps for a defensible SOC handover.
SOC analyst shift handover and incident documentation
Learn how to create investigation notes another analyst can reproduce and continue using Microsoft Defender XDR, Microsoft Sentinel and focused KQL evidence.
