How to Write a Professional SOC Investigation Ticket

Why a Ticket is an Investigation Output

A good ticket serves several audiences simultaneously: the current analyst, the next shift, Tier 2, the IR team, the SOC manager, and sometimes also IT or the system owner. Each of them has a different need, so the documentation should be layered: a quick summary at the top, technical details in the body, and evidence or links in an appendix.

Documentation also protects against memory biases. During an investigation, it's easy to remember the conclusion and forget the process. When every Query, finding, and decision is recorded in real-time, it's possible to go back and check if the conclusion is still valid after new information emerges.

In the event of a confirmed incident, NIST emphasizes the importance of documentation and coordination as part of the response capability. Documentation is not just “what we did,” but also when, who approved, what the outcome was, and what limitations affected the decision.

Recommended Ticket Structure

Start with a descriptive title, not just a rule name. “Encoded PowerShell on DC01 after privileged login” is more useful than “Rule 4827”. In the summary line, state the who, what, when, and current status. Afterward, present Scope, Timeline, Evidence, Analysis, Actions, and Next Steps.

Use a fixed template, but don't turn it into a form full of empty fields. If a field is not relevant, state “not relevant” or remove it according to system policy. An empty field creates doubt as to whether it was forgotten or not checked.

Fact, Interpretation, and Hypothesis

A fact is data observed from a source: “Event ID 4688 logged powershell.exe at 10:14:22 UTC”. Interpretation is professional meaning: “Parent of WINWORD.EXE and encoded command line raise suspicion of execution from a document”. A hypothesis is an unverified possibility: “The user may have opened a Phishing file”.

When the three layers are written in the same sentence, the reader may treat a hypothesis as a fact. Therefore, use labels or clear phrasing: Observed, Assessment, Hypothesis. Add Confidence — high, medium, or low — and briefly explain its basis.

Even when closing an incident, document the alternative explanation. “Legitimate activity” is not enough; write who confirmed, what Change existed, which details matched, and what was unusual but explainable.

How to Quote Logs Without Overwhelming

Do not copy dozens of lines of Raw Log into the body of the Ticket. Choose the fields that prove the claim: Timestamp, Host, User, Process, Parent, Command Line, Source/Destination, Result, and Event ID. Save a link to the search or full evidence when the system allows.

When quoting a Query, document the time environment, Data Source, and filters. “No events found” without specifying a time range and table is not a reproducible finding. For example, write: “Searching SecurityEvent for user1 in the 24 hours prior to the alert did not return Logon type 10 from additional devices.”

Do not modify Raw Evidence to make it readable. A summarized version can be presented, but keep the original and Hash as needed. Sensitive information, secrets, and PII should be kept in the approved channel and according to organizational policy.

How to Document Queries and Actions

For each significant Query, record the purpose and result: “Purpose: Check Password Spray. Query: Failures by Source IP and user. Result: 37 users, no success”. Such a list prevents repetitions and shows which Hypotheses were tested.

In a response action, specify Actor, Time, Approval, Action, and Outcome. For example: “10:32 UTC — IT manager approved account Disable; 10:34 — Account was disabled; 10:36 — Refresh Tokens revoked; 10:40 — No new Sessions observed”.

If an action failed, it is still part of the documentation. Write the error message or reason and escalate. Hiding a failure creates a false picture of the containment status.

Weak Ticket vs. Professional Ticket

Shortened Full Example

Title: “Successful external login followed by mailbox rule creation — user1”. Summary: At 07:11 UTC, a successful login was recorded from a country not observed for the user; four minutes later, a Mailbox rule was created that moves messages with the word “invoice” to a hidden folder. The user is not aware of the activity. The account was temporarily disabled, and the incident was escalated to IR.

Facts: Entra Sign-in shows unmanaged Device and MFA satisfied by claim; Audit Log shows New-InboxRule; no Change found. Analysis: No legitimate explanation identified, and the action is consistent with persistence and email access. High Confidence. Scope: user1 account; Rules, OAuth grants, and additional Sessions are being checked. Next step: Revoke sessions, Reset credentials, Review mailbox access, and notification to the data owner according to Playbook.

Practical Checklist

• ✓The title describes behavior and entity, not just a rule name.
• ✓The summary answers what happened and what the current status is.
• ✓The Scope and Timeline are clear.
• ✓I separated fact, interpretation, and hypothesis.
• ✓I specified Queries, time ranges, and results.
• ✓I documented Actions, approval, and outcome.
• ✓I added Classification and justification.
• ✓There is a Next Step with an Owner and target time.
• ✓No secrets or sensitive information in an unauthorized channel.

Common Mistakes

• Writing “I checked and everything is fine” without evidence.
• Copying long Raw Logs instead of relevant fields.
• Not documenting Negative Findings and search ranges.
• Changing the story retrospectively without noting an update.
• Closing a Ticket before the Action was verified.
• Using a hypothesis as a factual title.

Summary and CTA

Take an old ticket or a lab scenario and rewrite it according to the structure in the article. Ask someone who did not participate in the investigation to read it and answer: what happened, what is the evidence, and what is the next step. In HPI's Cybersecurity & AI course, investigation and documentation are practiced as part of SOC work and not as a separate exercise.

FAQ