Notes from the first month at a SOC.

The thing nobody tells you about a SOC is how much of it is reading.

Not reading code, not reading playbooks. Reading other analysts. Every closed ticket on your tenant is a small artifact of how someone earlier in the rotation thought about a problem — what they checked first, what they ruled out, what language they used to summarize. After a couple of weeks you stop seeing alerts as standalone events and start seeing them as part of a long, ongoing conversation between shifts.

The second surprise was how local the work is. School makes you think in attack frameworks and CVE numbers. The real job is much more parochial: this client's user base, this client's normal beacon traffic, this client's tolerance for false positives. A rule that's noisy at one tenant is a goldmine at another. The skill isn't memorizing techniques — it's developing taste for what's normal here.

A few habits that started paying off around week three:

• Open the ticket twice. Once to read it cold, once after running the lookups. The first read tells you what the previous analyst thought mattered. The second tells you whether they were right.
• Write the summary before you close. Not the disposition — the human-readable summary. If I can't write a one-paragraph version that the next shift can pick up without context, I haven't actually understood the incident.
• Keep a personal scratchpad. Mine is a Confluence page nobody else reads. Patterns I keep noticing, queries I keep re-typing, names of internal services I keep forgetting. Almost everything in it eventually becomes a runbook contribution.

None of that is sophisticated. The job mostly isn't. It's a craft about paying attention, and it gets better the more carefully you pay it.