Good investigation notes do two jobs at once. They help you think clearly while you work, and they help the next person understand exactly what happened after you are done. In Palo Alto Networks XSOAR, that matters even more because investigations often move fast, involve automation, and pass between analysts, engineers, and managers. A weak note creates confusion. A strong note becomes evidence, a timeline, and a handoff document in one place. This article walks through a practical XSOAR investigation notes template, explains why each field matters, and shows how to document evidence in a way that is useful during the incident and after it closes.
Why investigation notes matter in XSOAR
XSOAR is built to centralize incident response. It collects alerts, runs playbooks, stores artifacts, and tracks tasks. That can make teams assume the platform itself is the documentation. It is not. Raw incident data tells you what the system saw. Notes explain what the analyst concluded, what they tested, and why they acted.
That difference is important for a few reasons:
-
Evidence needs context. An IP address on an incident record means little by itself. A note that says, “Outbound connection from finance laptop to 185.x.x.x at 10:14 UTC matched prior malware infrastructure in vendor feed; destination first seen in our environment today” tells a usable story.
-
Handoffs fail without clear thinking. If a case moves from day shift to night shift, the next analyst needs more than screenshots and task status. They need to know the current hypothesis, the open questions, and what not to repeat.
-
Audits and post-incident reviews depend on notes. After the event, leaders ask what happened, when you knew it, and why you made each decision. If your notes are clean, you can answer quickly.
-
Automation still needs human judgment. XSOAR can enrich indicators and trigger actions, but it cannot fully explain whether those results are trustworthy or relevant to this incident. Your notes bridge that gap.
If you are preparing for a XSOAR engineer role or sharpening your process, it helps to think of notes as part of the workflow, not as admin work added at the end. For role-focused study, resources like XSOAR Engineer Palo Alto Networks practice test can help reinforce the operational side of the platform.
What a strong investigation note should do
A useful note is not a transcript of everything you clicked. It is a structured record of the facts, analysis, and actions that matter. In practice, every good investigation note should answer these questions:
-
What triggered the investigation?
-
What evidence has been collected so far?
-
What indicators are involved?
-
What is the current hypothesis?
-
What actions were taken, by whom, and when?
-
What is still unknown?
-
What should the next person do?
That is the logic behind the template below.
Palo Alto Networks XSOAR investigation notes template
You can adapt this template to a XSOAR layout, war room note, task form, or custom incident field set. The exact format matters less than consistency.
-
Incident ID / Case Name
Example: INC-2026-0418 / Suspected phishing with endpoint execution -
Analyst Name and Role
Example: Maya Patel, Tier 2 Analyst -
Note Timestamp
Use UTC and be consistent.
Example: 2026-06-19 14:32 UTC -
Incident Summary
A short plain-English statement of what is happening.
Example: User reported suspicious email. XDR alert shows child process spawned from Outlook on host FIN-WS-044. Possible phishing leading to script execution. -
Trigger / Source
What opened the case?
Example: User report, Cortex XDR alert, SIEM correlation rule, threat intel match, SOC escalation. -
Scope Known So Far
List affected users, hosts, accounts, applications, business units, or mailboxes.
Example: One confirmed host affected; one user mailbox involved; no lateral movement confirmed yet. -
Key Indicators
Capture the core IOCs and related artifacts.
Include: IPs, domains, URLs, file hashes, filenames, email sender, subject line, usernames, hostnames, process names, registry paths.
Example: URL hxxp://secure-doc-view.example; SHA256 9f…; sender [email protected] -
Evidence Collected
List the supporting facts, not just conclusions.
Example: Email headers reviewed; attachment hash checked in threat feed; endpoint process tree collected; DNS query logs reviewed; proxy logs confirm outbound connection at 10:14 UTC. -
Timeline
Record meaningful events in order with timestamps.
Example:
09:58 UTC email delivered
10:03 UTC user opened attachment
10:04 UTC powershell.exe spawned from WINWORD.EXE
10:14 UTC host connected to flagged IP -
Working Hypothesis
State your current best explanation.
Example: User opened phishing attachment that launched PowerShell downloader. Payload likely attempted C2 beaconing. No evidence yet of credential use or lateral movement. -
Alternative Explanations Considered
This shows analytical discipline.
Example: Legitimate admin script unlikely because process chain originated from user email attachment; false positive on destination IP still being checked against second intel source. -
Actions Taken
Be exact. Include time, actor, and result.
Example: 10:20 UTC analyst isolated host via XDR; 10:24 UTC blocked URL on proxy; 10:31 UTC reset user password; 10:40 UTC requested mailbox purge. -
Automation / Playbooks Run
Note what XSOAR did automatically and whether it succeeded.
Example: URL reputation enrichment completed; endpoint isolation playbook executed successfully; malware sandbox submission failed due to file retrieval timeout. -
Open Questions / Gaps
List what you still need to confirm.
Example: Need EDR results from second host used by same user; need to confirm whether attachment was forwarded internally; need identity logs for suspicious login follow-up. -
Risk / Impact Assessment
Summarize current business and technical impact.
Example: Likely single-user compromise attempt. Moderate risk due to execution on finance endpoint. No confirmed data access or spread at this stage. -
Handoff Notes / Next Steps
Tell the next analyst exactly what to do next.
Example: Review identity provider logs from 09:30–11:00 UTC; verify if same hash appears on any other endpoint; confirm mailbox purge completed. -
Final Disposition
Use at closure.
Example: Confirmed phishing with blocked follow-on activity; contained to one endpoint; no evidence of persistence.
How to standardize timestamps so the timeline stays trustworthy
Timestamps are one of the most common sources of confusion in investigations. Email logs may use one time zone, endpoint logs another, and analyst notes a third. If you do not standardize early, your timeline becomes unreliable.
The safest approach is simple:
-
Write all note entries in UTC. This removes time zone guessing during handoff and reporting.
-
Preserve original source time when it matters. If a log says local host time, mention that in the evidence section.
-
Use a consistent format. For example: YYYY-MM-DD HH:MM UTC.
-
Separate observed time from action time. The event may have happened at 10:03 UTC, but you may not have isolated the host until 10:20 UTC. Both matter.
Why this matters: response decisions are judged against what was known at that moment, not what was discovered later. Clean timestamps protect the integrity of the case record.
How to capture indicators without turning notes into a dump
Many analysts make one of two mistakes. They either add too few indicators, or they paste every enrichment result into the notes. Both hurt usability.
The better approach is to record indicators in layers:
-
Primary indicators are directly tied to the event. Example: malicious URL clicked, hash executed, sender address, destination IP contacted.
-
Supporting indicators add context. Example: related domain from same campaign, mutex name, parent process, nearby login source.
-
Dismissed indicators are ones you checked and ruled out. Example: a second IP that looked suspicious at first but belonged to a legitimate CDN.
This structure helps because it separates what drove your conclusions from what was only background noise. In XSOAR, where enrichment can return many data points, that discipline keeps notes readable.
For example, instead of writing:
“Many IPs and domains seen in logs; several bad reputation scores returned.”
Write:
“Primary IOC: 185.x.x.x contacted by FIN-WS-044 at 10:14 UTC. Two intel sources classify as malware infrastructure. Related domain update-check.example resolved to same IP within 5 minutes. Second IP 104.x.x.x initially reviewed and dismissed as Microsoft CDN based on reverse DNS and asset behavior.”
The second version is better because it shows the evidence path and the reasoning.
How to write useful hypotheses during an active investigation
A hypothesis is not a guess. It is your current explanation based on the facts you have now. Good notes make the hypothesis visible because it guides the next step.
A practical format is:
Hypothesis: What you think happened.
Why: The evidence supporting it.
What would disprove it: The check that could change your mind.
Example:
Hypothesis: The attachment executed a downloader rather than a full payload.
Why: Short-lived PowerShell process, outbound connection to known malicious IP, no persistence artifacts yet found, no large file write observed.
What would disprove it: Discovery of installed service, registry run key, scheduled task, or secondary executable on disk.
This method helps in two ways. First, it keeps the investigation focused. Second, it prevents notes from sounding more certain than the evidence supports.
How to record actions taken so they stand up later
Action logs are not just a checklist. They explain the control measures used and whether they worked.
Every action entry should include:
-
Time
-
Actor such as analyst, automation, endpoint team, email team
-
Action such as isolate host, disable account, block hash, submit file
-
Result succeeded, failed, partial, pending
-
Reason why the action was necessary
Example:
-
2026-06-19 10:20 UTC — Analyst — Isolated FIN-WS-044 via XDR — Success — Prevent further outbound communication while validating execution scope.
-
2026-06-19 10:24 UTC — XSOAR playbook — Added URL to block list — Success — Prevent additional user clicks on phishing infrastructure.
-
2026-06-19 10:31 UTC — IAM team — Reset user password and revoked active sessions — Success — Precaution due to possible credential exposure.
This format is better than writing “host isolated, password reset” because it preserves accountability and decision logic.
How to prepare a clean handoff in XSOAR
A handoff note should save the next analyst time, not force them to reread the whole case. The best handoffs are short, current, and directional.
Your handoff should include:
-
Current case status
Example: Contained but not fully scoped -
What is confirmed
Example: User opened malicious attachment; host executed PowerShell; one malicious outbound connection observed -
What is not confirmed
Example: No proof yet of credential abuse or spread to other hosts -
Highest-priority next step
Example: Query environment for same hash and same destination IP across all endpoints -
Dependencies
Example: Waiting on email team to confirm purge and on IAM logs for suspicious sign-in review
The reason this works is simple. In a real SOC, the next analyst often has limited time to get up to speed. A strong handoff removes ambiguity and lowers the chance of duplicated work.
Common mistakes that make investigation notes weak
Even experienced teams slip into habits that make notes less useful. Watch for these problems:
-
Writing notes only at the end. Memory fades fast. Record key findings as you go.
-
Confusing evidence with conclusions. Write both, but keep them separate.
-
Pasting raw output without summary. Add the meaning of the output, not just the output itself.
-
Missing timestamps. Without time, actions and evidence lose investigative value.
-
Not documenting failed actions. A failed sandbox upload or enrichment timeout still matters because it explains gaps.
-
Overstating certainty. If something is likely but not proven, say that clearly.
-
Leaving no next step. A note should help the next move, not just describe the last one.
Example of a concise, high-quality XSOAR investigation note
Incident ID: INC-2026-0418
Analyst: Maya Patel, Tier 2
Timestamp: 2026-06-19 14:32 UTC
Summary: Suspected phishing led to script execution on finance workstation FIN-WS-044. Current evidence supports malicious attachment opening followed by PowerShell activity and one outbound connection to known bad infrastructure.
Scope: One user, one endpoint, one mailbox currently confirmed. No evidence yet of lateral spread.
Primary Indicators: sender [email protected]; attachment invoice_review.docm; SHA256 9f…; destination IP 185.x.x.x; process chain OUTLOOK.EXE > WINWORD.EXE > powershell.exe.
Evidence: Email headers show external spoofed sender. Attachment hash flagged by two intel sources. XDR process tree confirms PowerShell spawned from Word at 10:04 UTC. Proxy logs show outbound connection from host to 185.x.x.x at 10:14 UTC. No persistence found in initial autoruns review.
Hypothesis: Malicious macro or document exploit launched PowerShell downloader. Follow-on payload may have been blocked or interrupted after host isolation.
Alternative considered: Legitimate script execution unlikely due to email-origin process chain. Full compromise not yet confirmed because persistence and credential use remain unproven.
Actions Taken:
10:20 UTC analyst isolated host via XDR — success.
10:24 UTC XSOAR blocked URL/domain artifacts in security controls — success.
10:31 UTC IAM reset password and revoked sessions — success.
10:40 UTC requested enterprise mailbox search and purge — pending confirmation.
Open Questions: Need tenant-wide search for same hash and same sender. Need IdP review for suspicious login after 10:00 UTC. Need confirmation whether user entered credentials into any linked page.
Handoff: Priority is environment-wide scoping. Check XDR for same hash, same parent-child process pattern, and same destination IP. Follow up with email team and IAM.
This note works because it is short but complete. It captures the event, the evidence, the current theory, the response actions, and the next step.
Final takeaway
If you want to document evidence like a pro in Palo Alto Networks XSOAR, focus on structure and reasoning. Standardize timestamps. Separate evidence from conclusions. Capture indicators with context. Write down your hypothesis while it is still forming. Record every meaningful action with time and result. End every note with what remains unknown and what should happen next.
The real goal is not to create longer notes. It is to create notes that are dependable under pressure. When the case gets escalated, reviewed, or reopened weeks later, your notes should let another skilled person understand the investigation without guessing. That is what professional documentation looks like.
