How Much of MITRE ATT&CK Does Your SIEM Really Cover?
Most detection rule sets cover a small slice of MITRE ATT&CK while the telemetry to cover far more already sits in the SIEM. Here is why the number is smaller than teams assume, and how a MITRE ATT&CK coverage assessment gets you an honest one.
September 12, 2026 · By ScopeWise Team
The gap between what you log and what you detect
CardinalOps' 2025 State of SIEM Detection Risk report found that enterprise SIEMs detect about 21% of MITRE ATT&CK techniques on average, even though the telemetry those same SIEMs already ingest could cover more than 90%. That is not a logging problem. The logs are there. What is missing is the mapping between the rules a team has written and the technique list those rules are supposed to defend against. Nobody sits down and decides to cover 21%. It happens because rule sets grow one alert at a time, tagging is optional, and no one re-checks the total against the full ATT&CK matrix once a quarter, let alone after every rule change. A MITRE ATT&CK coverage assessment exists to close that gap: take the rules as they are, take the ATT&CK matrix as published, and produce an honest count of what is actually covered instead of what a rule name implies.
Four states, not two
A rule set does not sort cleanly into "covered" and "not covered." A technique is covered when at least one enabled rule maps to it with a confident mapping. It is partial when the only mapping is a disabled rule, or the mapping confidence is low, or a parent technique has no direct rule of its own but at least one of its sub-techniques is covered. It is not covered when nothing maps to it at all. And it is not applicable when the technique cannot occur in the environment being assessed in the first place. Collapsing partial into covered flatters the number; collapsing it into not-covered ignores real intent behind a disabled rule. Keeping all four states separate is what makes a coverage percentage mean something specific rather than something optimistic.
Why not-applicable has to leave the denominator, with a reason
ATT&CK v19.1 lists 858 Enterprise techniques across 15 tactics, plus separate ICS and Mobile matrices. Not every technique applies to every environment: a macOS-specific technique is meaningless with no macOS in the inventory, and the ICS matrix should not be in play for an estate with no OT or industrial control assets. Marking those as not applicable and removing them from the denominator is correct, but only if the reason is visible. There are two kinds. Derived: the platform or domain the technique needs is absent from the declared inventory. Customer-declared: someone excluded the technique on purpose and gave a reason, printed verbatim in the report. An executive reading "78% coverage" needs to know whether that 78% is measured against the full 858 or against a narrowed set someone chose, and why it was narrowed. A coverage number with no visible N/A reasons is a number nobody can audit.
Two numbers, never one
A second reporting discipline matters as much as the four states: the coverage a customer's own rules provide, and the coverage a security tool claims to provide natively, are always reported as two separate figures. Merging them produces a number that overstates what the customer team actually built and maintains, and understates what buying or enabling a vendor feature would add. Keeping them apart also protects the audit trail — a rule the customer wrote and owns behaves differently under a product update than a vendor-native detection does, and a report that blends the two loses that distinction the moment it is printed.
Coverage is presence, not efficacy
A technique being "covered" only means a qualifying rule exists for it. It says nothing about whether that rule fires correctly, or at all. Detection strength is scored separately, from provenance (was the mapping written by a person, matched by keyword, or assigned by a language model), whether the rule is enabled, whether real detection logic is present rather than a placeholder, and whether the rule's log source actually matches the telemetry the technique requires. A disabled rule can satisfy the coverage state as partial, but it can never score as a strong detection — a rule nobody has turned on is not defending anything yet, no matter what it would catch if it were live. Splitting these two questions apart is why a report can honestly say "covered, but weak" instead of collapsing it into one comforting label.
A worked example
Picture a hypothetical 120-rule Sentinel workspace covering Windows endpoints, Entra ID, and AWS, with no macOS and no OT in the inventory. Applicability first removes every macOS-only technique (derived, platform absent) and the entire ICS matrix (derived, no OT assets declared), which might shrink the denominator from 858 to something closer to 640 applicable techniques for that specific estate. Against that narrower denominator, the 120 rules might land at 96 covered, 40 partial (mostly disabled rules kept for tuning, plus a few low-confidence tags), and the rest not covered — a strict figure near 15% and a weighted figure, crediting partial at half value, closer to 21%. Of those 96 covered techniques, detection-strength scoring might flag a third as merely moderate because the rule's log source only loosely matches the technique's expected telemetry. None of these numbers are real; they are illustrative of how the four states and the two-number split turn a single "here is our coverage" claim into something a security lead can actually interrogate.
What to do with the gap list
A list of not-covered and partial techniques is not useful until it is ordered. Gaps get ranked by how often real attackers use the technique and by whether it touches a declared crown jewel, then split by feasibility: short-term gaps are covered by telemetry already onboarded, mid-term gaps need tooling the team already owns but has not wired up, and long-term gaps need new capability entirely. That ranked list is the actual deliverable — a SIEM detection coverage percentage on its own tells you where you stand, but a feasibility-sorted gap list tells you what to build next quarter versus what to defer. If you want to see this run against your own rule export and environment inventory, ScopeWise's MITRE ATT&CK coverage assessment produces the coverage numbers, the detection-strength scoring, and the ranked gap list from the same run.