The alerts that should never reach a human

When a security operations centre is drowning, the instinct is to hire. Usually the actual problem is that a large share of the queue consists of alerts where the analyst adds no judgement — they gather three pieces of context, compare them to a rule they hold in their head, and close the ticket. That is a program, not a person.

The discipline is deciding which alerts genuinely need a human, and being honest that most do not.

Automate the enrichment, always

Before an analyst sees anything, the alert should already carry the asset owner, the user’s role and recent behaviour, the reputation of any external indicator, and whether this pattern has fired before and how it resolved. Every minute spent assembling that by hand is a minute not spent thinking.

Automate the closure when the rule is deterministic

Impossible-travel alerts where the second location resolves to a known corporate VPN egress. Malware detections where the file was quarantined before execution and the hash is a known commodity dropper on a fully patched host. These have a defensible deterministic answer, and a playbook can reach it faster and more consistently than a tired analyst at 4am.

The rule we hold ourselves to: automated closure requires a written decision tree, a logged rationale on every closure, and a monthly sample reviewed by a human. Automation without audit is just deleting alerts.

Never automate the judgement calls

Anything touching a privileged account, anything on a system in your crown-jewel list, anything where the signal is behavioural rather than deterministic, and anything novel. These are where analysts earn their salary, and they should have the time to do it properly.

A well-tuned pipeline typically moves a large majority of raw alert volume off the human queue while increasing the number of genuine incidents found — because the people left in the loop are looking at things worth looking at.