Alert triage, step by step: the six stages and where the hours go
Alert triage in six steps: dedupe, group, scope, verdict, action, record. Where the hours really go, which steps a machine should own, and what needs a person.
Alert triage is the work of turning a stream of raw alerts into a short list of things worth a person's time, and then deciding each one. In practice it is six steps: deduplicate, group related alerts into a single incident, establish scope and blast radius, decide true or false positive, decide what to do, and record why. The useful thing to know before you buy anything is that the first two steps are mechanical and eat the majority of the clock. That is the part a machine should own.
Everything after them is judgement, and judgement is what you hired your analysts for. Most tooling has this backwards: it automates the verdict, which is the part a person is accountable for, and leaves the joining-up to a tier 1 analyst with three consoles open.
Your Tuesday, named before we name ourselves
A detection stack finds alerts. A ticket queue records them. In between, a person opens the endpoint console, the identity provider and the SIEM, notices that the same host name appears in all three, and decides from memory whether those three things are one incident or three.
That last step is not written down anywhere, is not measured, and is repeated hundreds of times a week.
It does not survive a shift handover, and it is the step that most reliably goes wrong at 03:00, because it depends entirely on how much of the estate one tired person happens to be holding in their head.
The six steps of alert triage, and who should own each
| # | Step | The question it answers | Should be owned by |
|---|---|---|---|
| 1 | Deduplicate | Have I already seen this exact thing? | the machine, entirely |
| 2 | Group | Do these alerts belong to one incident? | the machine, showing its reasoning |
| 3 | Scope | What else did this touch, and how far could it reach? | the machine gathers, the analyst judges |
| 4 | Verdict | Is it real? | the analyst, given an argued first opinion |
| 5 | Action | What do we do now, and how urgently? | the analyst; anything destructive, a person |
| 6 | Record | Why did we decide that? | the machine writes it, the analyst owns it |
Read the right-hand column as the design brief. Steps one and two are the tier 1 grind: they have one correct answer, independent of business context, so a machine that gets them right gives the whole shift its hours back.
Steps four and five are where an escalation to tier 2 earns its cost: they depend on things no product knows about your organisation, so a machine that pretends to own them is selling you a liability.
Steps one and two: the ones that quietly cost you a day a week
Microsoft and Omdia's vendor-commissioned State of the SOC study (2026) found that two thirds of SOC teams lose about a fifth of their weekly capacity to manual correlation. A fifth of a week is a day per analyst, spent joining alerts by hand.
Deduplication is the smaller half. The same event reaches you twice because two sensors saw it, because a poll window overlapped, or because a delivery was retried. None of that is interesting, and none of it should reach a queue.
Grouping is the expensive half, and it has two failure modes that look nothing alike.
The first is the burst: one rule fires hundreds of times in a few minutes — a brute-force run, a misconfigured agent, a scanner sweep. Ungrouped, that is a morning's backlog. Hundreds of individually low-severity failed logons are not hundreds of incidents, and they are not one low-severity line either. They are one incident that deserves to be rated for what the volume actually means, with every repeat counted.
The second is the opposite: three alerts that look unrelated because they came from three different tools, and are in fact one intrusion. The strongest signal most estates have is agreement between sources — and no single tool can see it, because no single tool sees the other two.
This is the work our correlation engine does before a human looks. Nine independent checks examine every alert and must agree on one verdict: how the entities are behaving, whether the attack is genuinely progressing, whether more than one source independently agrees, whether the pattern matches a recognised attack pattern such as phishing to account takeover, whether a known-benign pattern explains the whole thing. The analyst opens a case that already knows which alerts belong to it, and why.
Step three: scope and blast radius
Scoping asks what else the thing touched. Which other hosts did that account reach, has this address appeared elsewhere this week, is this technique part of something already open.
This step splits cleanly. Gathering the context is mechanical — lookups, joins and history — and a person doing it by hand is doing data entry. Judging the context is not: whether a service account reaching four servers is normal depends on what that account is for, and nobody outside your organisation knows that.
So the machine should arrive with the scope already assembled: the entities involved, the kill-chain position, whether sources agree, and, with the Threat Intelligence module, what is externally known about the indicators. The analyst then spends their attention on the part only they can do.
Step four: the verdict, and the gap it inherits
Triage can only decide on what reached it. CardinalOps read live production SIEM configuration metadata for its 2025 State of SIEM Detection Risk report and found detections covering 21% of MITRE ATT&CK techniques where the data already ingested could cover 90%, with 13% of the rules that did exist silently broken. Those two numbers set the ceiling on any triage process: alerts that never fire cannot be triaged, and rules that fire for nothing generate work with no verdict worth reaching.
Detection coverage is a detection-engineering problem, not a triage one. No triage process lifts the ceiling it inherits, and the people who can lift it are not the people working the queue.
Under that ceiling, qualifying an alert is a judgement call, and the verdict should be argued rather than announced. SIROC, our AI analyst and the Advanced AI module, sets out the innocent explanations and the evidence on both sides first, and commits to a verdict last. Then the specifics it cited are checked against the alerts actually attached to the case, and a verdict the case's own evidence does not support has its confidence score downgraded in front of the analyst rather than passed along as fact.
That ordering is the point. An analyst can supervise an argument. Nobody can supervise a conclusion.
Step five: decide what to do
A verdict is not an outcome. Someone still has to weigh the business impact and choose between watching, containing and disrupting a business process — the third has a cost your organisation may not want to pay at 03:00 on a Friday.
Automation belongs here in a narrow form: the repeatable, reversible steps that always follow a given verdict, packaged as a response playbook in the Automations module. Destructive actions — isolating a host, blocking an address — always stop at an approval gate a person has to clear, and no playbook can lower that bar.
Gartner's formal position is that there will never be an autonomous SOC. We agree with it, and we do not sell an autonomous SOC. The machine ranks, explains and proposes; a person decides and stays accountable.
That is what keeping a human in the loop means across these six steps: the machine owns one, two and six, and it never owns four or five.
Step six: record why, the step everyone skips
Six months after an incident nobody asks what happened, because the logs answer that. They ask why you decided it was fine, or why you escalated. That answer normally lives in the head of an analyst who has since changed jobs.
Every case should therefore keep a readable decision trace: which signals mattered, how the verdict was reached, and what would have had to be different for it to change. Written as a by-product of working the case, not as a second job at the end of the shift. When it is, the write-up your board, your auditor or your regulator eventually asks for is already there — which is the argument behind treating the SOC as a decision system rather than a monitoring one.
What still needs a person, honestly
Whether the service account touching four servers at 02:00 is an intrusion or the migration somebody scheduled and forgot to mention. Whether this host can be pulled off the network during a month-end run, or whether the outage costs more than the risk. Whether an ambiguous case is worth waking the on-call for. Nobody outside your organisation can answer those, and accountability for the answer cannot be delegated to software at all.
We hold no ANSSI or CSPN qualification, we have no third-party pentest report, we offer no SLA, and we are pre-GA with no customers yet. We publish no triage-accuracy figure of our own, because no credible cross-vendor benchmark exists and a number nobody can check is worth less than none. Judge the claim against your own week of alerts instead.
Where this leaves you
The sequence never changes. What changes is who does which step, and how much of the clock the mechanical half consumes. Seculogik sits above the detection stack you already run — open-source stacks such as ClickHouse, Elastic, OpenSearch and Wazuh, market platforms such as Splunk, Microsoft Sentinel, CrowdStrike, Microsoft Defender and Cortex XDR, or a connector we build if yours is missing — and takes steps one, two and six off your analysts, while making three, four and five faster to do well.
Seculogik is licensed per deployment, per year, with no meter on the alerts you send it. The same sequence runs whether you protect one estate or, on the MSSP edition, several customers from one screen.
If the arithmetic here matches your week, the next chapter is the machinery: how the Verdict Layer turns alerts into cases into decisions, and what your analyst sees at the end of it. If you would rather see it against your own alerts, book a demo.