A green heatmap is not a tested detection.

A detection coverage map records that a rule exists. It does not record that the rule fires, that the alert carries enough context to act on, or that anyone acts on it. A green cell can mean any of those things, or none of them.

Our position: count a technique as detected when a controlled test has produced the expected alert and the expected response. A rule that has never been exercised is a hypothesis about your monitoring, not a measurement of it.

Data is rarely the constraint.

CardinalOps' fifth annual State of SIEM Detection Risk report, published in June 2025, found that enterprise SIEMs had detections for an average of 21% of the MITRE ATT&CK techniques used by adversaries. The same report estimated that the telemetry those SIEMs already ingested was sufficient to detect more than 90% of them. The company reports analysing more than 13,000 detection rules across hundreds of production environments. Read the report announcement.

CardinalOps sells detection posture management, and its sample is drawn from the environments it analyses rather than from a random selection of organisations. The figures describe that population, not your SOC. The gap they point to is still a useful one to check: the missing work is usually writing, testing and maintaining rules, not collecting more logs.

A rule that cannot fire still looks like coverage.

The same report found that 13% of existing rules were broken and would never trigger, for reasons such as misconfigured data sources and missing log fields. On a heatmap, a broken rule and a working rule look identical.

A rule depends on a data source arriving, a parser producing the expected fields and a query matching the values attackers actually generate. Any of those can change after the rule is written. A rule that has not produced an alert for months may be quiet because nothing happened, or because it can no longer see what it was written for. Only a test distinguishes the two.

Disabling a rule is a risk decision.

Tuning makes a rule more precise: it narrows the match, adds context or changes the threshold, and keeps the technique in view. Disabling a rule because the queue is too long removes that visibility. Both can be reasonable. Only one of them is tuning.

Treat a disabled or suppressed detection like any other accepted risk. Record the technique it covered, the reason, the owner who accepted it and the date it will be reviewed. A suppression nobody can explain is a gap nobody has decided to accept.

Automation can empty a queue without explaining it.

SIABench, a March 2026 preprint from Concordia University and Defence Research and Development Canada, evaluated language-model agents on security incident analysis. On the larger of its two alert-triage sets, the best model classified 98% of 100 alerts correctly. On 25 deep-analysis scenarios, which require reconstructing an incident from forensic artefacts and logs, the best model fully solved 8, while answering about 82% of individual questions correctly on average. Read SIABench.

The scenarios are curated and the triage sets are small; the authors discuss contamination and output variability as limitations. The result does not say what any particular product achieves. It does show that classifying alerts and explaining an attack are different tasks, and that a strong score on the first is not evidence of the second.

Practitioners report a similar gap. In the SANS 2026 AI survey of 536 practitioners and 57 senior leaders, 63% of practitioners reported significant shortcomings in AI threat detection and response, up from 45% in 2025. Read the SANS survey findings. A shorter queue is an operational result. Whether the closed alerts were closed correctly is a separate question that needs its own evidence.

Tests a detection programme can repeat

• Sample the green cells. Choose a set of techniques the map reports as covered. Emulate each one within an authorised, agreed scope and record the expected alert, the observed alert and the time between them.
• Check the silent rules. For rules with no recent alerts, confirm that the data source still arrives and the required fields are still populated. Separate quiet rules from broken ones.
• Register the suppressions. Keep disabled and suppressed detections in a list with an owner, a reason and a review date.
• Follow the alert to a decision. Confirm that the alert reaches the team that owns it, with enough context to decide, and record what that decision was.
• Evaluate automation on known incidents. Before relying on an agent for investigation, give it past incidents with established ground truth and compare its reconstruction with what actually happened.

NIST's Cybersecurity Framework 2.0 expects improvements to be identified from security tests and exercises (ID.IM-02). Read CSF 2.0. The detection worksheet shows the expected-versus-observed record on fictional data.

These are practices we recommend, not results SecurePeak measured. We did not reproduce the cited studies; they use different samples and methods, and their figures should not be combined into a single industry rate. Nothing here describes a particular client's environment.

The heatmap shows what you intended to detect. A test shows what you detect.