Case study
98.1% of a month’s alerts resolved without an analyst
728 alerts in July, every one of them investigated and dispositioned at a median of 48 seconds. Reading all of them is also what exposed a detection fault the queue had been absorbing for months.
The situation
A managed security provider was running a Microsoft-centric detection stack across a client estate. In July that stack produced 728 alerts. Nobody was reading all of them. No queue that size gets read in full by a team that also has to respond to incidents, and the loudest rule in it was crowding out everything else.
That rule was impossible travel. It fired 619 times in the month, and every firing looked, on its face, like it might be a compromised account.
The standard industry answer to this is to tune the rule down, raise its threshold, or suppress it for the users who trigger it most. All three reduce the alert count. None of them tells you whether you just turned off a detection that would have caught something.
What Intruex did
Every one of the 728 alerts was triaged. Not sampled, not the high-severity subset: every alert routed to a specialist, enriched, correlated and dispositioned with a confidence value and written reasoning, at a median of 48 seconds each.
That is the part that repeats. It is what the platform does with a queue every month, at whatever volume the estate produces and whatever the alerts happen to be about.
What reading all of them surfaced
The pattern surfaced in the correlation: 617 of the 619 resolved to the same root cause. The client's corporate proxy rotated its egress node between requests. Two sign-ins minutes apart would present from geographically distant addresses, the rule would compute an impossible velocity, and it would fire. Nothing about the authentication was anomalous. The two remaining alerts were not part of the pattern, and were investigated on their own merits.
Nobody samples their way to that finding. Each of those 617 sign-ins is unremarkable on its own; they are a root cause only in aggregate, and the aggregate only exists if every alert has already been examined and the results compared against each other. Fixing the cause removed roughly 600 alerts per month from the queue. Zero alerts were dropped to achieve it, and the detection remains armed.
What repeats
Removing a recurring fault does not empty a queue. It removes one thing from it.
The 619 impossible-travel alerts were a single rule inside a month that produced 728. What is left after the fix is the rest of the estate's output: the alerts that differ from each other, the ones that actually warrant a verdict, arriving at the rate they always did, from a stack that keeps changing. New tenants, new detections, new infrastructure, new noise.
Those get the same treatment, because it is the same process: every alert read, the great majority closed with written reasoning attached, the remainder handed up as a finished case file. The analysis does not depend on the queue looking the way it looked in July, and it does not have to be re-tuned for the queue it gets next.
Root causes like the proxy are not a one-time find either. They are a by-product of ordinary infrastructure change: a proxy, a VPN split-tunnel, a new SaaS tenant, a vulnerability scanner, a backup window that crosses midnight. Each produces its own recurring noise, and each becomes visible the same way this one did: only if somebody reads all of it and compares the results.
Why the distinction matters
Competitors in this category advertise 85 to 90 percent alert reduction, and buyers have started reading that number with suspicion. Merlin Gillespie, CTO at Cybanetix, put the concern plainly: a falling alert volume may indicate "suppression of signals rather than improved detection fidelity."
That is a fair worry and it is the right question to ask a vendor. The difference between the two is not the percentage. It is whether the vendor can show you the mechanism. We can, per alert, with the reasoning attached.
The audit outcome
Fourteen alerts were escalated to a human that month. The analyst reviewing them did not re-investigate any of them. The written reasoning, the enrichment and the correlation factors were sufficient to accept or reject each escalation on the record as delivered.
This is the whole thesis, measured: a verdict you cannot audit has to be redone, which means it saved you nothing. These did not have to be redone.
What it proves
The fix was one month. The reading is every month.
The 600 alerts were the one-off. The part that recurs is the 728: a full queue read end to end, most of it closed with reasoning attached, and whatever needs a person arriving at one already investigated. That happens again next month against a different set of alerts, and the month after that, without anything being tuned for it.
The root cause is what falls out of doing that thoroughly. Anyone can shrink an alert queue: raise a threshold, add a suppression rule, narrow a detection's scope, and the number goes down the same week. What you cannot do afterwards is say what you stopped seeing.
This engagement removed roughly 600 alerts a month and can account for every one of them: each was investigated, each carries a written disposition, and the detection is still armed. If that proxy starts behaving differently tomorrow, the rule fires and somebody finds out.
That is the difference worth paying for, and it is the one an auditor will ask about.
Additional operational detail from this engagement (internal response timings, per-detection breakdowns and cost figures) is available under NDA during an evaluation.
Method
Where each number comes from
Every figure here is a direct count or a stated derivation from one month of production traffic, so you can check the arithmetic. The customer is described as "a managed security provider" because they have not agreed to be named publicly.
| Figure | Basis |
|---|---|
| 728 alerts | Count of alerts ingested and processed in the month |
| 98.1% | Share dispositioned without an analyst touching them: 714 of 728 |
| 14 escalations | The remainder, handed to an analyst as a finished case file |
| 48 seconds | Median wall-clock triage time. Absolute, not a comparison |
| 617 / 619 | Alerts resolved to a single documented root cause |
| 0 dropped | No alert was suppressed, filtered or tuned out |
| 357 hours | Modeled from the alert count at a 30-minute manual triage assumption, stated inline |
Bring us an alert you already know the answer to
Hand it something from last week and read the reasoning. If the verdict is wrong, you will see exactly where it went wrong, which is the whole point.
