Case Management and Documentation
Chapter 5 walked through the mechanics of working an incident from confirmation through initial containment and handoff. This chapter is about the paper trail that runs alongside that work, and why it deserves as much discipline as the investigation itself. A ticket with a weak disposition and no supporting notes is functionally a closed case with no memory: nobody, not the next analyst, not an auditor, not the SOC manager pulling monthly metrics, can reconstruct what actually happened. Good documentation is not overhead bolted onto the real work. For a SOC, it is part of the real work.
Why Documentation Matters to a SOC
It's tempting to treat ticket notes as a formality you fill in after the real work, the investigation itself, is done. That framing undersells what documentation actually does for a SOC. Three separate functions depend on it, and each one fails quietly, not loudly, when notes are thin.
Audit Trail
Every closed ticket is potential evidence that something was looked at and handled appropriately. If a regulator, an auditor, or legal counsel later asks "what did the SOC know about this activity, and when," the ticket is the answer. A case with a vague note and no timestamp doesn't just look sloppy in that review, it may be legally indefensible, because there is no record showing due diligence was actually performed.
This matters even for tickets that turn out to be nothing: a well-documented false positive proves the SOC evaluated the signal and reached a reasoned conclusion, rather than simply ignoring it.
Knowledge Transfer
The analyst who opens a similar alert six months from now, quite possibly you, needs to know whether this exact pattern has come up before and how it was resolved. Without a searchable, readable case history, every recurrence gets re-investigated from scratch, which wastes time and risks a different analyst reaching a different, inconsistent conclusion on what is effectively the same activity.
This is also what makes handoffs between shifts work: an analyst picking up a case mid-investigation at a shift change should be able to read the notes and continue the work without a live briefing.
Metrics Input
Chapter 7 covers SOC metrics and KPIs in detail, but the short version is that every one of those numbers is computed from ticket data:
- Mean time to respond
- False positive rate
- Dwell time
- Disposition breakdown by alert type
If analysts close tickets with inconsistent or missing fields, the metrics built on top of that data are wrong, and a SOC manager making staffing or tuning decisions off wrong metrics is making decisions off bad information without realizing it. Documentation discipline at the individual ticket level is the foundation the entire measurement layer of the SOC sits on.
Ticketing Systems and the Ticket Lifecycle
Nearly every SOC tracks its case load through a ticketing platform, generically the same category of tool as ServiceNow or Jira, sometimes a purpose-built SOC case management module bolted onto the SIEM itself. Whatever the platform, the underlying lifecycle a ticket moves through is broadly consistent, and understanding each state matters because documentation expectations differ at each stage.
| State | What Happens |
|---|---|
| New | An alert or report has generated a ticket, but no analyst has picked it up yet. The ticket carries whatever context the alerting system auto-populated: source, severity, raw event data. |
| Assigned | An analyst (or a queue routing rule) has taken ownership of the ticket. Ownership should be explicit and visible in the system, not just understood informally, so two analysts don't unknowingly duplicate the same investigation. |
| Investigating | Active work is happening: pivoting through logs, pulling related events, reaching out to an asset owner or the user involved. This is the state where working notes should be added incrementally, not reconstructed from memory at the end. |
| Resolved | The analyst has reached a disposition and taken any required action (containment, escalation, notification), but the ticket hasn't been formally closed. Some workflows use this state for a quality check or peer review step before final closure. |
| Closed | The ticket is finalized: disposition code set, notes complete, no further action expected. A closed ticket should be readable on its own, without the analyst who worked it needing to fill in gaps verbally. |
The specific state names and workflow steps vary by platform and by how a given SOC has configured its queues, but the shape is the same everywhere: a ticket moves from unclaimed, to owned, to actively worked, to a reasoned conclusion, to a finalized record.
Skipping states, jumping straight from New to Closed without ever marking a ticket as Investigating, is usually a sign that the investigation itself was skipped too, not just the state transition.
What Good Investigation Notes Look Like
The gap between a useful ticket and a useless one usually isn't length, a long note can still be vague, and a short one can still be precise. The difference is whether the note answers the questions a future reader will actually have. There's a small, consistent set of elements a solid investigation note covers.
- What was observed: the specific event, alert, or behavior that triggered the ticket, described concretely rather than paraphrased ("PowerShell spawned from winword.exe with an encoded command argument," not "suspicious PowerShell activity").
- When: timestamps for the observed activity and for the investigation steps themselves, with the timezone stated explicitly. A timestamp with no timezone is ambiguous the moment more than one region is involved.
- How it was investigated: which queries were run, which tools were used, which systems or people were contacted. This lets someone else retrace the same path without starting over.
- What evidence was gathered: linked to or referenced directly, not just described. A saved search link, a case file attachment, or an exported log excerpt is worth far more than a sentence summarizing what it showed.
- The disposition reached, and why: the conclusion on its own is not enough. The reasoning that got there is what makes the note defensible and reusable later.
Contrast that with a note that reads "looked into it, seems fine." It has no timestamp, no description of what was actually checked, no evidence reference, and no stated reasoning.
If that ticket is ever reopened, questioned by an auditor, or referenced by another analyst investigating a related alert, that note is worthless. It technically satisfies the requirement that the ticket have a note, but it satisfies none of the three purposes documentation is supposed to serve.
Writing Notes as You Go
The best investigation notes are written incrementally during the investigation, not reconstructed from memory afterward. Working an incident and taking notes at each pivot, this query returned these results, this asset owner confirmed this, keeps the record accurate and saves the end-of-investigation scramble to remember what you actually did an hour ago.
It also means that if the investigation gets interrupted, by a higher-priority alert or a shift change, whoever picks it back up has an accurate account of where things stand rather than a half-finished ticket with no context.
Disposition and Closure Codes
Every closed ticket needs a disposition code, a standardized label for what the investigation concluded. Disposition codes exist so that similar outcomes get recorded consistently across analysts and across time, which is what makes metrics and trend analysis possible in the first place. Most SOCs work from some version of the following set.
| Disposition | When to Use It |
|---|---|
| True Positive - Actioned | The alert reflects genuine malicious or policy-violating activity, and the SOC took a response action: containment, credential reset, escalation to IR, notification to an asset owner. |
| True Positive - No Action Needed | The activity was genuinely malicious or unauthorized, but it was already handled by an automated control, already mitigated, or otherwise required no further response from the SOC beyond documenting it. |
| False Positive | The alert fired on activity that was not malicious and not policy-violating. The detection logic matched something it shouldn't have. |
| Benign True Positive | The detection logic correctly matched what it was built to match, but the underlying activity itself was legitimate: a penetration test, an approved admin action, expected but rarely-seen behavior. The rule worked; the activity just wasn't a threat. |
| Duplicate | The ticket represents the same underlying event as another ticket already open or resolved, usually caused by overlapping detection rules or a retriggered alert for the same activity. |
| Insufficient Data | The investigation could not reach a confident conclusion because required logs weren't available, a source wasn't onboarded, or evidence had already aged out of retention. This disposition should be rare enough to be a signal, not a default fallback. |
False Positive vs. Benign True Positive
The distinction between False Positive and Benign True Positive is one analysts new to case management often blur, but it matters for tuning decisions downstream. A False Positive suggests the detection logic itself needs adjustment. A Benign True Positive suggests the logic is working correctly and the fix, if any, belongs in an allowlist or exception for a specific known-legitimate source, not in the underlying rule.
Documentation Pitfalls
Most documentation failures aren't dramatic. They're small habits that feel harmless in the moment and only become a problem when someone actually needs to rely on the record later.
- Copy-pasting notes across similar tickets. Reusing a template for a recurring alert type is fine; reusing the exact wording without tailoring it to what was actually observed in this instance is not. It produces a case file that reads as if nobody actually looked at the specific event, and it erases whatever small details would have distinguished a routine occurrence from an unusual one.
- Missing timestamps or timezone ambiguity. A note that says "activity occurred around 3pm" with no date, and no indication of whether that's local time, UTC, or the SIEM's default timezone, is nearly impossible to correlate against anything else later, especially across a distributed team or a multi-region incident.
- Closing tickets without linking the evidence that justified the disposition. A disposition of False Positive with no reference to what was checked to reach that conclusion is unverifiable. If that same pattern recurs and someone questions whether it was really benign, there's nothing to point back to.
- Inconsistent terminology between analysts. If one analyst writes "beaconing" and another writes "C2 callback" and a third writes "suspicious outbound" for the same underlying behavior, searching the case history for past instances of that pattern becomes unreliable. Consistent, shared terminology is what keeps a ticket archive searchable rather than just archived.
None of these pitfalls are hard to avoid individually. What makes them persistent is that they rarely cause visible harm on the day they happen, the ticket still closes, the queue still clears. The cost shows up later, when someone tries to use that documentation for exactly the purposes covered earlier in this chapter, and finds it isn't there.
Key Takeaways
- Documentation serves three functions for a SOC: audit trail, knowledge transfer to future analysts, and the raw input for every metric the SOC reports on. Weak notes quietly undermine all three.
- Tickets move through a consistent lifecycle, New, Assigned, Investigating, Resolved, Closed, tracked in a ticketing platform such as ServiceNow or Jira, and skipping states usually signals skipped work, not just a skipped status update.
- A good investigation note states what was observed, when (with timezone), how it was investigated, what evidence was gathered (linked, not just described), and the disposition reached with its reasoning.
- Disposition codes, True Positive - Actioned, True Positive - No Action Needed, False Positive, Benign True Positive, Duplicate, Insufficient Data, should be a controlled list applied consistently so metrics and trend analysis stay meaningful.
- Common pitfalls, copy-pasted notes, missing timezones, unlinked evidence, and inconsistent terminology, don't cause visible damage at closure time. They surface later, when someone actually needs the record to hold up.
Knowledge Check
Click an answer to reveal the explanation.
Q1. An alert fired exactly as its detection rule was designed to, but the activity turns out to be an approved penetration test. What is the correct disposition, and what does it imply for tuning?
Q2. A ticket note reads: "Checked the activity around 3pm, looks fine, closing as false positive." What is the biggest problem with this note?
Q3. Why does inconsistent terminology between analysts (for example, one writing "beaconing" and another writing "suspicious outbound" for the same behavior) create a real problem for a SOC?