Notifications
Clear all
Topic starter
18/08/2026 2:46 pm
TL;DR: A SIEM that is merely running can still miss attacks, waste analyst time, and inflate storage costs, according to Expel’s diagnostic of data, detections, and team readiness. The real issue is often rule hygiene, ingestion discipline, and alert triage, not the platform itself.
NHIMG editorial — based on content published by Expel: a diagnostic look at SIEM maturity and performance
By the numbers:
- Only 38% have automated certificate lifecycle management in place.
- 69% of organisations now have more machine identities than human ones.
- 59% of companies face greater difficulties auditing machine identities, primarily due to lack of clear ownership and limited visibility.
Questions worth separating out
Q: How do security teams know if SIEM coverage is actually working?
A: They verify the path from source to rule, not just the rule itself.
Q: Why do identity events matter so much in SIEM and SOAR design?
A: Identity events often show compromise earlier than infrastructure telemetry because attackers usually start by abusing accounts, tokens, or authentication paths.
Q: What do teams get wrong about alert fatigue in a SIEM?
A: They often treat alert fatigue as an analyst discipline problem when it is usually a tuning problem.
Practitioner guidance
- Audit detection sources by confirmed value Rank log sources by true positives, not by ingest volume, and remove sources that do not support an active detection use case.
- Review every active rule on a fixed cadence Assign an owner to each rule, require evidence of recent validation, and retire or retune rules that have not produced a confirmed true positive in 90 days.
- Separate compliance retention from detection engineering Move low-signal compliance data out of the primary detection path where possible, and keep only the datasets that materially support investigations or ATT&CK-mapped detections.
What's in the full article
Expel's full article covers the practical diagnostic detail this post intentionally leaves for the source:
- A nine-question SIEM self-assessment that teams can use during internal reviews and maturity discussions
- The specific decision points behind source pruning, rule retirement, and compliance-data separation
- The operational reasoning behind alert fatigue, detection drift, and analyst context-switching
- A structured way to discuss whether the program is busy or genuinely improving detection outcomes
👉 Read Expel's SIEM maturity diagnostic for detection coverage and analyst workload →
SIEM maturity gaps: what practitioners need to act on now?
Explore further
18/08/2026 3:28 pm
Detection maturity is now an identity governance issue, not just a SOC issue. A SIEM that cannot reliably surface authentication abuse, privileged misuse, or service-account anomalies leaves identity governance incomplete. That is true for human IAM and even more true for NHI-heavy environments where machine accounts can generate large volumes of routine activity that hide abuse. Practitioners should treat detection quality as part of access governance, not a separate concern.
A question worth separating out:
Q: Who is accountable when detection coverage fails to stop a breach?
A: Accountability sits with the programme that owns detection engineering, rule review, and incident response readiness, not with the platform alone. In practice, governance should define who approves new data sources, who validates active detections, and who signs off when a rule is retired. That ownership is what makes SIEM performance auditable.
👉 Read our full editorial: SIEM maturity gaps are usually detection gaps, not tool gaps
