What must a security alert's case note record beyond the verdict, so another analyst can act on it?
answer
- someone else, without you
- facts and reasoning, not the verdict
- paste the query, not a summary
- one clock for every source
- zero results are findings too
basics
~20 sA case note must let someone else reach the same verdict without you: the exact queries run with their time windows, what was found and what was ruled out, every timestamp in UTC, and the reasoning behind the disposition.
solid answer
~50 sThe test I apply is simple: can another analyst, or an auditor eleven months from now with nobody left to ask, reach my verdict from the note alone? That means recording observable facts and reasoning, not just a conclusion. Concretely: the entities involved (host, account, process, source address); the exact queries or tool actions I ran, pasted verbatim, with their data source and time window; what each returned, including the searches that returned nothing; what I ruled out and the evidence that ruled it out; every timestamp normalised to UTC, noting a source's local offset where it mattered; and the verdict with its reason - true positive, false positive, or benign true positive with the authorised activity named. `Checked, looks fine` is not a case note. It records that a human touched the ticket and nothing else.
go deeper
Be ready to list what goes in a note: entities, the exact queries with time windows, results including empty ones, what was ruled out, UTC timestamps, and the verdict with its reason.
Explain why each element is there - what a later reader cannot do without it, and why a paraphrased query or a local timestamp quietly destroys the note's value.
Show the judgment about depth: which cases justify a full narrative, what you preserve versus what you only reference, and how you write so a stranger in another region can act at 22:00.
Own the standard itself - what the organisation requires a closed case to carry, how long it is kept, and how that is reconciled with the minutes an analyst actually has per alert.
## What a case note is for A case note is not paperwork attached to an alert. It is the only durable output of triage. The alert console will age out, the search you ran will not be re-runnable at the same retention a year from now, and you will not remember this alert next week - let alone in eleven months when an auditor pulls a sample of closed cases. Everything triage produced that outlives the shift lives in the note. It has exactly two readers, and they want the same thing for different reasons: - **The next analyst.** They pick up your case cold, possibly in another region at 22:00, possibly because the same host alerted again. They need to know what you checked so they do not repeat it, and what you did not check so they know where the gap is. - **The auditor, regulator or investigator, much later.** They are asking why this alert was closed the way it was. They cannot ask you. They can only read. Both reduce to one acceptance test: **can someone else reach the same verdict from the note alone?** If not, the note is incomplete no matter how long it is. ## The contents **Identity and scope of the alert.** Which detection fired, on which entity, at what time, and what the rule was actually looking for. Rules change; a year later `suspicious archive creation` may mean something different, so record the rule name or identifier and the field values that triggered it. **The entities.** Hostname *and* an address or asset identifier, account name in a resolvable form (a SID or object id survives a rename), process name plus full command line, parent process, and any external address or domain. Names drift; identifiers do not. **The exact queries and actions, verbatim.** Paste the query text, not a paraphrase. `I searched the proxy logs` is unverifiable and unrepeatable; the query string, with its index or data source and its explicit time window, is both. The same goes for console actions: which tool, which view, which filter. **What each query returned - including nothing.** Zero-result searches are findings and belong in the note. So do their limits: which hosts were in scope, whether every host in scope actually reports, how far back the data goes. **What was ruled out, and by what evidence.** The conclusion `no lateral movement` is worthless on its own. The query that failed to find it, over which sources and window, is what a reader can evaluate. **Timestamps, in UTC.** A SOC handing cases between regions cannot reason about a timeline where one line is in local time and the next is not. Normalise every timestamp to UTC in the case timeline; where a source recorded local time, say so and say what offset you applied. Note whether a timestamp is event time or ingest time when the two differ enough to matter - the gap between the two is often what makes an ordering claim wrong. **The reasoning and the verdict.** State the inference, not just its result: `4624 logon type 3 to FS-07 came from the backup service account at its scheduled 02:00 window and matches the previous 30 days, so this is authorised activity`. Then the disposition - true positive, false positive, or benign true positive (the rule fired correctly on activity that turned out to be authorised) - with the authorising owner or change named if you have it. **What you preserved.** If you exported logs, saved a process tree or pulled a file, say what you took, when, and where it now lives, so the next person can find it rather than re-collecting it. ## The failure modes - **The conclusion-only note.** `Checked, looks fine.` It cannot be checked, corrected or defended. - **The chat-thread note.** The reasoning lives in a channel, the case says `see chat`. Channels are ordered by message, not by event; they are not retained on the case's schedule; and the participants leave the company. - **Local timestamps.** Two sources, two offsets, one confident ordering that is wrong by an hour. - **Paraphrased queries.** The reader cannot tell whether your search would have found the thing you say it did not find. - **Recording only the supporting evidence.** A note that lists what confirmed the verdict and omits what did not is an argument, not a record. ## What the note is not It is not a formal evidence-custody record, and it is not a postmortem. It is the working record of an investigation, written for a stranger, in the plainest possible terms, with the reasoning exposed so that a stranger can disagree with it.
- Where should the record live - the case, or the chat thread where the work actually happened?The case. Chat is a working surface, not a record: it is ordered by message rather than by event, it is retained on a different schedule, and its participants leave. Link the thread if you like, but the evidence, the queries and the reasoning are copied into the case record so it stands alone.
- Why record which detection rule fired and what it was looking for?Because rules change. A year later, reading only the alert name, nobody can tell whether the rule that fired then is the rule that exists now, or which field values tripped it. Recording the rule identifier, its version if you have one, and the matched values makes the original firing reconstructible.
- Two sources recorded the same event in different local times. What does the note record?Normalise the case timeline to UTC and record, per source, the original timezone and the offset you applied, plus whether the timestamp is event time or ingest time. Otherwise a later reader cannot verify the ordering you built your conclusion on, and an ordering claim is usually the load-bearing part of the note.
saying these in an interview costs you the question
- Writes only a verdict: checked, looks fine
- Summarises the query instead of pasting it
- Records local times with no timezone or offset
- Leaves the reasoning in a chat thread
- Omits searches that returned nothing
- Assumes the next reader can just ask them