From alert to decision.
This paper is about the security operations decision layer: the tier between the SIEM that raises alerts and the person who has to act on them.
SIEM alert overload is not a collection problem. Triage, qualification and escalation are where the week actually goes, and that is the part nobody sold you a product for.
Seven sections. Every figure is attributed to whoever measured it. Section six is the list of what we do not have — read that one first if you are short of time.
SIEM alert overload, in numbers you can check.
Two published measurements describe the same week from opposite ends. Neither is ours, and both name their method, which is the only reason to quote them.
- CardinalOps, State of SIEM Detection Risk 2025. Read from live production SIEM configuration metadata rather than from a survey: detection coverage stood at 21% of MITRE ATT&CK techniques, where the data already being ingested could support 90%.
- The same study, on rule health. 13% of the rules already running are silently broken. They do not fire, nothing announces that they stopped, and the detection posture degrades without a single decision being taken.
- Microsoft and Omdia, State of the SOC 2026 — vendor-commissioned, and worth reading as such. Two thirds of SOC teams lose roughly a fifth of their weekly capacity to correlating alerts by hand.
The estate is instrumented. The detections cover a fraction of what the data allows. And about a day a week goes on joining the results together inside somebody's head.
That last part is the expensive one. It is skilled labour, it does not scale with headcount, and it is the day that never goes to detection engineering or threat hunting.
Neither figure says your team is bad at its job. They say the work has been left in the one place nobody can inspect, review, or hand over at shift change. More on the coverage gap →
Why more data does not fix it.
Three different jobs get sold under one word. Separating them explains why the budget keeps rising while the Monday morning stays the same.
Adding a source improves the first job and makes the third one harder. Every new stream multiplies the number of things a person has to reconcile by hand.
More data feels like progress because it is buyable by the gigabyte. Decision is not, so nothing on the market forces the question — and the cost lands on the rota instead of the invoice.
- Collection
- Getting the events into one place. Solved, competitive, and the thing most vendors are actually selling you.
- Detection
- Writing and maintaining the use cases that turn events into alerts. A craft with measurable debt: coverage and rule health both decay quietly.
- Decision
- Turning alerts into an actionable short list: what a named person will act on tonight. Today, almost always a human, unaided, working from memory.
A SIEM finds things. Tier 1 clears what it can and escalates the rest. A ticket queue records that you were told.
Between the escalation and the ticket sits a senior analyst with several consoles open, deciding which fourteen alerts are one intrusion and which of them carries real business impact.
That person is your decision layer. They are undocumented, unbacked-up, and they take annual leave. The six stages of triage, and where the hours go →
What a security operations decision layer is.
One spine, repeated everywhere in the product: alerts become cases, and cases carry decisions. Alerts arrive from the stack you already run. Cases are what a person works. Decisions are what gets recorded.
Judged nine ways, decided once
Nine independent checks examine every alert and have to agree on one verdict, rather than one rule deciding alone. One check being wrong does not carry the case.
Shared entities · attack progression · agreement between sources · repeat volume · risk that builds slowly · known attack patterns · attacker clustering · benign-pattern suppression · what your analysts already decided about work of this shape.
Every case keeps its reasoning
Each case carries a readable decision trace: what mattered, how the verdict was reached, and what would have changed it.
That is the difference between a score you have to believe and a verdict an analyst can argue with — or overturn, on the record, in front of an auditor.
- Hundreds of repeats become one case. A burst of low-severity noise is absorbed into a single rated case rather than a hundred rows nobody reads, and nothing is lost if a component restarts mid-burst.
- The queue is ordered by business impact. Kill-chain position advances as evidence arrives, so a case that reaches ransomware stops sitting where it started. Ordering by arrival is how a real intrusion accrues dwell time behind a false positive.
- Every case has a clock and an owner. Not a shared inbox where urgency depends on who happens to look, and where the oldest thing is the least visible.
- Known attack patterns are recognised, not reinvented. Phishing to account takeover, exploit to foothold, execution to ransomware, identity to cloud privilege abuse.
- The sources stay yours. Splunk, Microsoft Sentinel, CrowdStrike, Defender, Cortex XDR, Elastic, OpenSearch, ClickHouse or Wazuh — pulled, pushed, or read where the data already sits, with a connector built on request.
None of this replaces your detection stack, and none of it asks you to move your data. How a verdict is reached, in detail →
Where the human stays.
The category now sells an agentic SOC, and its own leaders publish the limit: bounded autonomy, a human in the loop, and approval before anything destructive runs.
Gartner's formal position is that there will never be an autonomous SOC. We agree, and we built as though that is true rather than as though it were a marketing inconvenience.
The AI argues in the open
SIROC, our AI analyst module, lists its hypotheses and the evidence for each. What reaches the case is a detection verdict, how confident it is, what it recommends, and the reasoning behind all three.
And gets fact-checked
The evidence it cites is checked against the case's own alerts. A verdict the case does not support is downgraded in front of your analyst rather than quietly shipped.
Destructive actions stop for a person
With the Automations module, anything destructive waits at an approval gate, and that guardrail cannot be lifted by anyone — including us.
When an analyst overrules a proposed verdict, their decision is the decision. The disagreement is kept, and it becomes part of what the platform weighs the next time work of that shape arrives.
Most products say human-in-the-loop and mean a confirmation dialogue nobody reads. Our claim is smaller: the machine joins and reads, then hands a person a short list with its working attached. What SIROC does, and what it refuses to do →
Sovereignty, and what leaves the building.
For most European buyers this is the first question rather than the last. It has a short answer: by default, nothing leaves.
- A local model does the reasoning. An open-licence model runs on ordinary hardware on your own box. No GPU, no external call, no account with anyone.
- A cloud model only if you bring the key. You choose the provider, and you choose which tasks may use it — one task at a time, not a global switch someone flips once and forgets.
- Redaction happens before the call leaves. Secrets and personal data, including SIRET and RIB identifiers, are removed first.
- Every outbound call is on a ledger. Where it went and what was removed, written in a record that cannot be edited afterwards and that exports whole for your auditor.
- Spend caps and circuit breakers. A cloud bill cannot run away, and a failing provider stops being called rather than stalling your queue.
- The platform answers the question itself. Ask your deployment for its sovereignty attestation — is cloud AI permitted here, yes or no — and hand that to the auditor instead of a letter from us.
An air-gapped site is a supported deployment, not an exception we tolerate. Updates are signed, verified before a byte is applied, and reversed automatically if the health check afterwards fails.
The regulatory clocks assume you can already answer who decided what, and when. NIS2 wants an early warning within 24 hours, a notification within 72, and a report within a month; DORA starts counting four hours from classification.
A decision layer that keeps its own trace is how those deadlines stop being a scramble through chat logs. What the law actually asks → · The security and trust page →
What this costs you to evaluate — and what we do not have.
The evaluation cost is one machine. Debian or Ubuntu, Docker or bare metal, no GPU, on infrastructure you control. There is no account to create and no data to send us.
Priced per deployment, per year
Not per gigabyte, not per event, not per endpoint, not per seat — and not per customer served. A bill indexed on volume is where lock-in starts. Two things move our price: the edition you deploy, and the modules you switch on.
Real cases, at no cost, indefinitely
The free edition puts real cases and a real queue on the open-source stack a team may already run, with no time limit and no feature nag — and no correlation engine, which is what the paid edition turns on.
In people-time, budget an afternoon: someone who can grant read access to one source, and a senior analyst willing to disagree with a verdict out loud. Nothing else is needed to reach an opinion.
What we do not have.
This list is the reason the rest of the document is worth reading. We would rather you find it here than halfway through a procurement questionnaire.
- No customers yet. We are pre-GA. There are no logos, no testimonials, no references and no ROI study, because there is nothing honest to put in them.
- No ANSSI qualification, CSPN or SecNumCloud. A readiness assessment is on the roadmap. A claim is not.
- No third-party penetration-test report. One will be commissioned alongside the first design partners, and they will get it unedited. Until then we will walk you through how we test it ourselves.
- No SLA. What you get instead is a direct line to the engineers who build the product, and a design-partner arrangement that says in writing what that includes.
- No accuracy number of our own. No triage-accuracy figure, no false-positive-reduction percentage, no MTTR improvement. We have not measured them on anyone's real estate, so we will not print them.
- No SaaS and no self-serve provisioning. One deployment, on infrastructure you control. That is a deliberate limit, not a stage we are passing through.
A vendor who cannot tell you what they lack has not finished thinking about what they have. What is shipped, what is next, and what we will not build →
How to judge SOC alert triage on your own alerts.
Do not evaluate this on a vendor demonstration estate. The only question worth answering is what happens to your noisiest hour, and it takes about half an hour to find out.
After the replay, ask your senior analyst a single thing: would this have saved you the joining-up you did that morning?
If the answer is no, nothing else about the product matters — not the architecture, not the roadmap, and not the price.
Two capabilities are worth putting into the same session if they are on your list. Threat intelligence as context on a live case, rather than a feed nobody reads.
And the Vulnerability Operations Centre, which is included with the paid edition rather than sold separately. The six modules →
Run the thirty-minute test on your own alerts.
Bring one source, one busy hour and your hardest questions — including the ones from section six. You will leave knowing which edition fits and which modules are worth switching on.