Writing a ticket someone else can act on

Your ticket is read by people who were not in your head at the time: the next shift, the incident lead, an auditor months later, and you, three weeks from now, when the same alert fires again. Write for them.

The test of a good ticket is simple. Could someone pick it up at the start of their shift and carry on without messaging you? If the answer is no, something is missing.

A shape that works

1. Summary in one sentence. "Finance laptop FIN-0231 ran an encoded PowerShell command at 03:12 UTC; closed as benign, matches a scheduled IT script."
2. What fired. Rule name, alert time, host, user.
3. What you checked. Each check and its result, in order. Include the queries you ran, so someone can rerun them.
4. Evidence. Links to the events, hashes, IPs and domains you looked at. Paste the key line from the raw log.
5. Verdict and why. True positive, false positive or benign true positive, and the fact that decided it.
6. What happens next. Escalated to whom, a tuning request raised, a user contacted, or nothing.

Habits that help

• Use UTC, or state the time zone every time.
• Write what you saw, not what you assumed. "No outbound connection in EDR for 10 minutes after" is useful. "Looks fine" is not.
• If you closed it as a false positive, say whether the rule should be tuned and raise the request. Otherwise the same alert will waste someone else's time tomorrow.
• Record what you did not check and why. "Could not see proxy logs, no access" tells the next person where the gap is.

Keep a personal snippet file of the queries and phrases you reuse. After a month you will write a clear ticket in half the time, and your tickets will look the same from one shift to the next, which helps everyone who reads them.

Rule of thumb:Rule of thumb: a ticket is finished when a stranger could defend your verdict from what is written, without your memory.