SecOps · Automation
500 alerts in, 3 that need a human: building a triage pipeline that actually filters
Lajkó Levente · 22 August 2026 · 6 min read
Alert triage is the process that decides, for every incoming security alert, whether it needs human investigation or can be closed automatically with a documented justification. Most security teams do this by hand, and where they do, it is the biggest time sink of the day.
My website carries a claim: five hundred alerts in, three that need a person. I learned to reach that ratio in a high-volume telecom SecOps environment, and it is worth being precise about what it means. Not that four hundred ninety-seven alerts go in the bin. That four hundred ninety-seven get their answer automatically, with a logged justification, and three need the thing machines don't have: judgement.
This piece takes apart how that is built in practice. It is not product-specific: the same logic works under Splunk, Sentinel, Wazuh, Elastic or QRadar, because triage is not a tooling question. It is a design question.
Triage is not a staffing problem
When a team is drowning in alerts, the first reflex is always the same: we need more people. But the overwhelming majority of alerts are not decisions, they are noise, and noise should not be fed to analysts. It should be caught where it is produced. When triage hurts, it almost always means one of the pipeline's stages is missing.
The five stages an alert passes through
01
Filter before the SIEM
Most noise is not born in the detection rule. It is born when every log goes into the SIEM unsorted. The log pipeline (syslog-ng, nxlog or anything similar) filters, normalises and routes at the source: what will never be the basis of a detection should not land in your most expensive storage. As a side effect, licence cost stops being the ceiling on detection.
02
Deduplicate and correlate
A port scan is not five hundred events, it is one. Alerts arriving from the same source, with the same pattern, inside a short window get folded into a single case, and related signals (same host, same account, same time window) get placed side by side. The analyst receives a case, not an event stream.
03
Enrich: context is automatic
Before a human looks at it, the alert answers the routine questions by itself: whose asset is it, what runs on it, does it have known vulnerabilities, what does threat intel say, has this happened before, and how was it closed then. This stage alone halves triage time, because that is where analyst hours used to go: looking these things up by hand.
04
Rule-based closure, logged
Whatever has a deterministic answer after enrichment, the pipeline closes: a known maintenance window, an approved exception, a recurring false positive with a documented cause. The key word is logged: every automatic closure carries what closed it and on which data. Closure without evidence is not automation, it is sweeping things under the rug.
05
What remains is a decision
At the end of the pipeline, what is left is what genuinely needs judgement: the unknown, the unusual, the connected. The analyst doesn't filter, the analyst decides, and every decision feeds back: whatever gets marked a false positive becomes a rule-tuning task, not permanent background noise.
What to measure, so you know it works
A triage pipeline is not built once, it is a feedback system. Four numbers show whether it is heading the right way:
- Alert-to-case ratio: how many incoming alerts become a human investigation. This is the pipeline's efficiency, and it should improve week over week.
- Triage time per case: the time between an alert arriving and the first substantive decision. This measures enrichment quality.
- False positive rate per rule: not aggregated, but broken down by rule. The aggregate hides that ninety percent of the noise typically comes from a dozen rules.
- Tuning cadence: how many rules were modified in the past month. Where that number sits at zero, detection is not maturing, it is ageing.
Four mistakes I see in most environments
Sending everything into the SIEM
The most common and most expensive mistake. SIEM licensing is volume-based, so wherever every log goes in, cost eventually decides what is detectable. Filtering belongs at the source.
Imported rule sets with no tuning
Vendor and community detection rules make a decent starting point. They are not fit for live duty. Every environment has different base noise. A rule nobody tunes after enabling is not detection, it is a noise generator.
Alerts without an owner
If an alert type has no assigned owner and no expected response time, the organisation has silently said about it: we don't care. In that case, don't send it at all.
Automatic closure without evidence
The auditor's first question: how do you know that what the machine closed, it closed correctly? If the closure doesn't carry the reason and the data, the answer is that you don't. With logged closures the same question takes thirty seconds.
What this has to do with your audit
If the organisation lives under NIS2 or ISO 27001, the triage pipeline's by-product is worth at least as much as its main product. Every automatic closure with a logged justification, every human decision traceable: that is exactly the kind of evidence an audit will request about detection and incident response controls. Where triage is manual and undocumented, weeks go into reconstruction before each audit. Where a pipeline runs, the evidence is already there.
The 24-hour incident reporting deadline also becomes tenable from here: you can only report what you noticed, and you only notice what doesn't drown in the five hundred.
Lajkó Levente
Security engineer, founder of PROFIX Security Engineering. Day job: security operations at a national telecom provider.
If you want this built in your own environment: this is exactly what I do on contract, from assessment to a working pipeline. Details on the security automation page, or let's talk it through.