Platform

How it works The analyst team Trust & audit Integrations Deployment Evidence

Solutions

Defense & suppliers Government Healthcare Financial services MSSPs

Company

About Partners Resources Contact Responsible disclosure
Home/Evidence
measured A managed security provider · July 2026

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.

0
Alerts analyzed
July 2026, full month
0%
Resolved without analyst involvement
714 of 728
0s
Median AI triage time
absolute, not an improvement figure
0hrs
Analyst hours returned
at a 30-minute manual triage assumption

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.

FigureBasis
728 alertsCount of alerts ingested and processed in the month
98.1%Share dispositioned without an analyst touching them: 714 of 728
14 escalationsThe remainder, handed to an analyst as a finished case file
48 secondsMedian wall-clock triage time. Absolute, not a comparison
617 / 619Alerts resolved to a single documented root cause
0 droppedNo alert was suppressed, filtered or tuned out
357 hoursModeled 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.