You ingest for 90%, you detect 21%: the SIEM detection gap is a data problem

Paid for, not detected

The number to bring to your next coverage review

You are probably already paying to collect the data you need to detect almost every attack technique anyone has cataloged. Your rules use about a fifth of it.

That is the finding that should change how a security team talks about telemetry. CardinalOps, a detection engineering company, has published an annual report on the state of SIEM detection for five years running. Its 2025 edition, built from live production SIEMs, puts the averages across all five years at this: organizations ingest enough data to cover 90% of the techniques in the MITRE ATT&CK framework, their detection rules cover 21%, and 13% of the rules they have are broken (CardinalOps, State of SIEM Detection Risk, 2025).

The usual response to a coverage gap is to buy more data. Add a source, turn on another log category, raise the ingest commitment. These numbers say that is mostly the wrong answer. The data is already there. What is missing is data in a shape a rule can depend on, and the engineering time to write and keep the rules.

So the short version, the one worth repeating upward, is this: you are paying for data that could cover 90% of attack techniques, and detecting 21%. More data is not the answer. Detection-ready data is.

Three terms first, in plain words

Some readers live in this vocabulary every day. Others are about to forward this to someone who does not, so here are the three terms everything below depends on.

A SIEM (security information and event management) is the system that collects security logs from across a company and searches them to raise alerts. Splunk, Microsoft Sentinel, CrowdStrike Falcon LogScale and Google SecOps are examples. Most SIEMs are priced by how much data you send them, which is why their bill grows with every new source.

A detection rule is a saved search that runs inside the SIEM and raises an alert when a pattern shows up. A simple example: many failed logons on one account, then one that succeeds. A rule depends on the exact names and formats of the fields it searches. If the field it looks for is renamed, moved or missing, the rule does not complain. It simply never matches.

MITRE ATT&CK is a public catalog, kept by the non-profit MITRE, of the techniques attackers have been seen using, from stealing credentials to moving between machines to hiding their tracks. Security teams map their rules to it to see which techniques they watch and which they do not. Nobody is meant to cover all of it. The report says so itself: “full MITRE coverage of MITRE ATT&CK is not practical. The framework was never intended to encourage 100% coverage”. It is a map, not a target.

Ninety against twenty-one

Here is what the two big numbers mean, read carefully.

The 90% is potential. CardinalOps compares the log sources an organization already sends to its SIEM against the data each ATT&CK technique needs to be detected, and finds that the data on hand could support a detection for nine techniques in ten. On average that data comes from 259 log types and nearly 24,000 unique log sources per organization.

The 21% is reality: the share of techniques for which a working detection rule actually exists. It is the average across five years of samples, and it has barely moved. The 2025 sample on its own came in at 22%, up from 19% the year before, and the report describes progress as “hovering around 20% each year”. In the 2025 sample, SIEMs had rules for only 4 of the 10 techniques attackers use most often.

The sample is large enough to take seriously. Since its first report in 2021, CardinalOps has analyzed more than 13,000 unique detection rules and nearly 2.5 million log sources, across production SIEMs on Splunk, Microsoft Sentinel, CrowdStrike LogScale and Google SecOps, in multinational companies across most industries. It is configuration data pulled from real environments, not a survey of what people believe.

And it explains why the gap feels invisible from inside. As the report puts it, if you asked SOC leaders what share of ATT&CK their SIEM cannot detect, “only the most pessimistic (or brutally honest) would say anything above 50%”. The real answer is closer to 80%.

What the gap is actually made of

The honest reading of 90 against 21 matters, because a CISO who has read this report will quote the 90% back at anyone who says the fix is more sources.

The gap is mostly not missing data. It is two other things.

The first is detection engineering capacity. Writing a good rule, testing it against a simulated attack, tuning it until it stops drowning analysts in false alarms and keeping it working as the estate changes is skilled, slow work. The report calls the discipline “still reliant on error-prone manual processes and individual heroics”. Most teams have far more data than they have hours to turn into rules.

The second is data quality. A rule can only be written against data whose shape you can trust. When the same event arrives from three sources with three field names, or a source changes format without warning, every rule built on it is fragile. The report names “fragmented data repositories and inconsistent log formats that can cause critical events to be missed” as one of the reasons coverage lags.

Both of those are problems a telemetry pipeline helps with. Neither is solved by sending the SIEM more of the same raw data.

The rules that went quiet

The third number is the one that should worry a SOC lead most, because it is a failure nobody sees.

On average across the five years, 13% of the rules in a SIEM are broken. That is roughly one rule in eight. A broken rule does not raise an error or turn red on a dashboard. It sits in the rule list looking healthy and stays silent on the day the attack it was written for happens.

There is good news in the trend. In the 2025 sample the share fell to 10%, the lowest the report has recorded, down from 25% in its early years and 18% the year before. The average SIEM held 163 rules, so about 16 of them were not working. The report links this to a second trend: rule counts are down nearly a quarter since 2022, and fewer rules leave teams more time to maintain the ones they keep. Quality over quantity is starting to show up in the data.

Even so, the report’s own line is the right one to end on: “it only takes one broken rule for an attack to go unnoticed”.

Why rules break: the data moved under them

This is where the argument turns from detection to telemetry, so it is worth being exact about what the report says, rather than what a pipeline vendor would like it to say.

On the cause, the report is direct: “issues such as misconfigured data sources, missing fields, and parsing errors prevent an alert from firing when a legitimate threat is in the environment.” The press release that launched the report says the same thing more briefly: rules “will never trigger due to issues like misconfigured data sources and missing log fields.”

On how it happens over time, it describes drift: “your network boundary shifts, security tools upgrade to the latest versions, and monitoring workflows change. This drift can lead to broken rules that never fire, leading to a false sense of security.”

And among the questions the report tells detection teams to ask themselves is this one: “How do you monitor impacts of changing infrastructure, log source formats, and SIEM data pipelines on whether detections work as intended?”.

Read those three together and a pattern appears. In most of these failures, nobody touched the rule. A firewall upgrade added or renamed a field. A cloud service changed its log format. A collector was reconfigured and a field stopped arriving. The search kept running, faithfully, against data that no longer had the shape it expected. That is our reading of the report’s causes, not a figure from it, but it is the reading that matches what anyone who has run a SIEM has lived through.

Detection-ready data

If rules break because the data under them changes, the strongest fix is to stop the data changing shape before it reaches them. That is what we mean by detection-ready data, and it is the job a pipeline in front of the SIEM can do. This section is our view, from building these pipelines, rather than a finding of the report.

A telemetry pipeline sits between your sources and your SIEM. Every event passes through it on the way in, which makes it the one place where you can make three promises to every rule downstream.

1. Every event is parsed. The raw text is split into named fields before the SIEM sees it, so a rule never has to reverse-engineer a vendor’s message format in its own search.
2. Fields are named one way. A user name, a source address or a process path carries the same field name whatever sent it, so one rule works across every source of that event instead of three rules each half working.
3. The fields a rule depends on are checked. The pipeline knows which fields matter to which detections. When a source stops sending one, or starts sending it under a new name, the pipeline flags it.

The third promise is the one that changes the failure. Without it, a format change is discovered by the rule, which goes quiet, and nobody finds out until an investigation turns up an alert that should have fired months ago. With it, the same change is discovered by the pipeline, which raises a flag the day it happens. The difference is between a silent failure and a ticket.

None of this replaces the SIEM. The rules still run there, and the analysts still work there. The pipeline sits in front of the SIEM, never in place of it, and hands it data it can rely on. It is the same idea we laid out for AI agents in your AI SOC agent pays for every log line too: clean the data once, in front of everything, and every tool downstream gets the benefit. We went deeper on why consistent field names matter in the parsing tax.

Routing by detection value

The 90% has a second, less comfortable reading. If most ingested data could support detections that do not exist, then a lot of what you pay a SIEM to index today feeds no rule at all.

That gives every routing decision an objective test, which is again our view rather than the report’s. Ask one question of every source, and of every event type inside it: which detection does this feed?

• If it feeds a working detection, send it to the SIEM. That is where the rules run, and it is what the SIEM is worth paying for.
• If it feeds no detection yet, send it to your own data lake. It stays searchable for investigations and threat hunting at storage prices, and it is there the day someone writes the rule that needs it.
• Keep the full raw copy in a low-cost archive. That copy is for audit and for the investigation that needs every byte. Nothing is deleted, it is routed, and it can be replayed into the SIEM later if a new rule needs history. We covered how that works in reduction is not data loss.

Two things follow from routing this way.

The first is budget. What you stop paying the SIEM to hold can pay for detection engineering, which is the real constraint the report points at, and for the few sources that really are missing.

The second is speed. A new source can land in the lake first. Its coverage does not have to wait for the next SIEM budget cycle. The team can look at it, decide what it is worth, and promote the parts that feed detections into the SIEM once the rules exist.

This is the shape of the Logmetry Blueprint: raw telemetry into a pipeline in front of the SIEM, the SIEM receiving what detection needs, the clean and enriched copy in your own lake, and the full raw copy in an archive for audit.

Where an AI agent fits

There is a reason this matters more this year than it did when the first report came out.

Security teams are putting AI agents on triage. An agent like that can read two things: the alerts the SIEM’s rules raise, and the data sitting in the lake. That second part is what makes it interesting against a coverage gap. An agent that can query the lake can look into activity tied to techniques no SIEM rule watches yet. It can follow a lead from an alert into data the rules never touch, and it can point a detection engineer at a pattern worth turning into a rule.

That is our view, and it comes with conditions. An agent finds gaps. A person writes the rule. The agent gets read-only access to the lake and the alerts, people review and approve anything it proposes before something changes, and there is a record of what it read and why. That is oversight a CISO can defend to an auditor and a board.

It also depends on everything above. An agent reading inconsistent, unparsed data has the same problem a rule does, only it pays for it in tokens and in wrong answers. Detection-ready data is agent-ready data.

Where this is the wrong answer

A pipeline does not fix everything in this report, and it is worth saying where it does not.

• If your rules are badly written, clean data will not rescue them. A noisy rule stays noisy.
• If the technique you care about needs a source you truly do not collect, routing will not create it. That is the one case where more data is the answer.
• If nobody has time to write rules, a cleaner feed only helps once someone uses it. The budget a pipeline frees up has to go to detection engineering, or the 21% stays where it is.
• If your estate is small and stable, with a handful of sources that rarely change, the drift problem may be small enough to manage by hand.

Five questions for your team

1. Which of our rules have not fired in ninety days, and do we know whether that is because nothing happened or because they broke?
2. When a source changes its log format, who finds out first: a person, a pipeline, or the attacker?
3. For each source we pay the SIEM to index, can we name the detection it feeds?
4. Where do new sources land today, and how long does it take before anyone can search them?
5. If an AI agent started triage tomorrow, could it read anything beyond the alerts?

The source, and how we read it

Every number in this piece comes from one source: CardinalOps, State of SIEM Detection Risk, 5th annual report, 2025 edition, read in full on 6 October 2026. We checked for a 2026 edition on that date and found none.

Two cautions, in the spirit of the report itself. First, the headline figures (21% coverage, 13% broken rules) are the averages across all five years of the report’s samples, as the report itself labels them. The 2025 sample alone came in at 22% coverage and 10% broken rules, and the press release that launched the report presents the five-year figures as the 2025 findings. We have used the report’s own labels. Second, this is vendor-published research. CardinalOps sells a detection engineering platform, and in July 2026 it was acquired by Cribl, which also sells a telemetry pipeline. Read the numbers with that in mind. We have kept this piece free of any product recommendation for the same reason: the argument holds whatever pipeline you use.

So, a question for the people who own the rule set: when did you last find a rule that had stopped firing, and how did you find out?