Your SOC closes 400 alerts a day but its case notes are unusable a year later - how do you fix that without halving throughput?

## Diagnose before prescribing `The notes are unusable` is a symptom with three quite different causes, and the fix depends on which one you have: - **No standard.** Nobody ever said what a closed case must carry, so quality tracks individual conscientiousness. - **A standard nobody can afford.** A long template exists; analysts have four minutes per alert; the template is filled with `n/a` and the standard is fiction. - **A tooling problem.** Analysts are retyping what the console already knows, so the note is a transcription chore rather than a record of thinking. Most SOCs with 400 closes a day have the second and third. Writing a stricter policy is the response that fails, because the constraint is analyst-minutes and policy does not create any. ## Tier the depth to the decision Not every case deserves the same record, and pretending otherwise is what makes the standard unaffordable. A workable split: - **Bulk and automated dispositions** - alerts closed by an enrichment rule or an obvious, repeatedly-seen benign pattern. These need structured fields, populated by the tooling, plus a single reason code. Prose adds nothing a query cannot recover. - **Analyst-judgment closes** - anything where a human decided that activity which fired a rule is acceptable, especially a benign true positive where the rule was right and the activity was authorised. These need the full record, because this is the category that gets re-read after something goes wrong, and the question will be whether the decision was reasonable on what was known. - **Escalated cases** - the full record plus the handover discipline, since they will be read by people who were not there. The honest framing for leadership: you are buying auditability for the cases where it can be needed, and paying for it with minutes taken from the cases where it cannot. ## Make the tool write the boilerplate Everything mechanical should arrive in the case without a human keystroke: the entities, the rule identifier and version, the query text an analyst ran in the console, the artefacts pulled, timestamps normalised to UTC on capture rather than by hand. Every field a human must retype is a field that will be wrong, blank, or in local time. This is usually the highest-leverage change available and it is an engineering investment, not a policy one - which means it needs a budget line and an owner, and that is the actual decision being asked of a lead. ## A skeleton, not a template Four prompts, in the case form, that mirror how the work is actually done: what did you think was happening; what did you check and over what window and sources; what did you rule out and how; what is the verdict and why. That is short enough to be completed under time pressure and long enough to pass the only test that matters. A twenty-field template collects compliance; a four-field skeleton collects reasoning. ## Measure the thing, not a proxy The acceptance test for a case note is re-derivation: give a peer only the note and ask them to reach a verdict. Sample a small number of closed cases per week across dispositions and analysts, run that test, and record agreement plus the reason for each disagreement. It is slow and it is the only measure that resists gaming. The proxies all fail predictably. Mandatory-field completion rates measure form-filling; note length is gamed the day it is published; time-spent-per-note punishes the efficient. And report results at team level, framed as a signal about the standard and the tooling rather than a scorecard on individuals - the moment note quality is a personal performance metric, notes get longer and no more useful. ## The organisational parts **Ownership.** Someone owns the standard, is allowed to change it, and is allowed to say no when a new mandatory field is proposed. Standards drift upward by accretion because every addition is individually reasonable. **Retention and the audit obligation.** How long closed cases must be readable, in what form, and by whom, is usually an external requirement rather than a SOC preference. Find out what it actually is before designing the record - it determines what has to be inside the case rather than linked from it, because linked consoles and chat systems have their own, shorter, lifetimes. **The existing backlog.** Do not retro-fix a year of thin notes. Declare a cutover, keep what exists, and state the limitation plainly. Reconstructing case notes from memory produces a record that is confidently wrong, which in an audit or a legal context is worse than an admitted gap. **Expectation setting.** Say out loud what the change costs - a small number of analyst-minutes per judgment close - and what it buys: the ability to answer, eleven months later, why an alert was closed, with the person who closed it long gone.