SIEM & DETECTION · 9 MIN
The QRadar SIEM Audit: A Practical Checklist Before You Renew
A no-vendor-spin audit framework for QRadar deployments — health checks, content coverage, log source quality, license efficiency, and the questions to ask before renewal.
What should be checked in a QRadar SIEM audit?
A complete QRadar audit covers six areas: (1) Platform health (EPS/FPM utilization, disk and memory headroom, retention policy adherence, backup integrity), (2) Log source quality (DSM mapping completeness, parsing errors, time sync, missing critical sources), (3) Content coverage (ATT&CK map of enabled rules, dead vs noisy rules, building block hygiene), (4) Offense quality (false positive rate, MTTC/MTTR, top noisy generators), (5) License and cost efficiency (EPS waste, log source ROI), and (6) People and process (analyst tooling, runbook coverage, knowledge transfer risk).
The QRadar SIEM Audit: A Practical Checklist Before You Renew
Most QRadar deployments never get audited. They get installed, tuned for a few months, then drift for years until something breaks or a renewal forces a conversation.
By the time the renewal conversation happens, the SOC has lost institutional knowledge of what's actually deployed, the EPS license is probably wrong (in either direction), and nobody can answer basic questions like "do we cover credential dumping detection?" without a half-day of investigation.
This is a checklist for fixing that — a framework for auditing a QRadar deployment in roughly two weeks, producing a written gap list, and walking into your next renewal with data instead of vibes. We use this framework on every QRadar customer we onboard.
The audit in six layers
Layer 1 — Platform health
The boring stuff that, when broken, makes everything else moot.
- EPS and FPM utilization. Current peak vs licensed. Sustained vs burst. Trends over the last 12 months. Look for both directions: over-licensed (paying for capacity you don't use) and under-licensed (silently dropping events).
- Disk and storage retention. Is hot retention matching the documented policy? Is archival working? Is anyone actually testing restore?
- Memory and CPU headroom. On Console, Event Processors, Flow Processors. A processor running hot under steady load means you'll lose events under burst.
- High availability. If HA is configured, has failover been tested in the last 12 months? Untested HA is theatre.
- Patching cadence. Current QRadar version, fix pack level, time since last upgrade. Six versions behind is common, and it's a problem.
- Backups. Configuration backups running, retained off-platform, restore tested. Most environments fail one of these three.
Layer 2 — Log source quality
This is where most QRadar deployments quietly rot.
- DSM mapping. Every log source should map to a maintained DSM. Generic "Universal LEEF" or "Universal CEF" entries are red flags — they parse poorly and break detection.
- Parsing error rate per source. A source with 30% parsing failures has 30% blind detection. Find these, fix the DSM, or escalate to IBM.
- Time synchronization. Sources logging in their own timezone, with clock drift, or with no time field at all. Critical for forensics and correlation.
- Critical sources missing. Common gaps: cloud admin logs (AWS CloudTrail, Azure Activity, GCP Audit), SaaS audit logs (Microsoft 365 Unified Audit, Okta, Google Workspace), modern EDR (CrowdStrike, SentinelOne), identity provider logs (Entra ID sign-in/audit), DNS query logs.
- Volume per source. Sudden volume drops (source went silent, nobody noticed) or sudden volume spikes (chatty new device drowning the EPS budget) both deserve investigation.
Layer 3 — Content coverage
What does this SIEM actually detect?
- Rule inventory. How many rules total, how many enabled, how many tuned in the last 12 months, how many have fired in the last 90 days. The shape of these numbers tells you the maturity of the deployment.
- ATT&CK coverage map. For each technique relevant to your threat model, do you have detection content? This is the single most important deliverable of the audit.
- Dead rules. Enabled but never firing — either broken or covering threats that don't exist in your environment. Disable.
- Noisy rules. Firing constantly, mentally filtered by analysts. Tune or disable.
- Building block hygiene. Are the building blocks documented? Are reference sets actively maintained, or filled with three-year-old IOCs?
- Custom content lineage. Custom rules with no documentation, no owner, no review history. Common, and a knowledge-transfer time bomb.
Layer 4 — Offense quality
What gets to analysts, and what they do with it.
- Offense volume per day. Trend over 90 days.
- False positive rate per rule. Top 20 rules by volume, FP rate per rule. If your top 5 rules have FP rates above 80%, your SOC is being trained to ignore alerts.
- Mean time to triage / contain / resolve. Industry benchmarks vary; what matters more is your trend.
- Offense backlog. Open offenses older than 7, 30, 90 days. Aging offenses signal capacity or process problems.
- Top sources of noise. Often a single misconfigured rule or log source generates a third of the offense volume. Find it.
Layer 5 — License and cost efficiency
This is what funds the next year's improvements.
- EPS waste. Sources logging at 10× their useful volume — debug logging left on, verbose audit categories that nobody actually uses, duplicate log sources sending the same events twice.
- Log source ROI. Each source costs EPS. Does each source contribute to detection? Many sources are ingested for "we might need it someday" reasons and never queried. They consume EPS budget that could go to high-value sources.
- Storage tier optimization. Hot storage holding data that hasn't been queried in 60 days.
- Add-on utilization. Apps and add-ons (UBA, Threat Intelligence, etc.) that you pay for but don't use.
A typical audit finds 15–30% of EPS volume is recoverable without losing detection capability. That's leverage in your renewal conversation.
Layer 6 — People and process
The deployment is only as good as the team running it.
- Analyst tooling. Are analysts spending time fighting QRadar UI or actually investigating? How many tabs to triage one offense?
- Runbook coverage. Top 20 alert types — is there a documented runbook? Has it been updated this year?
- Knowledge transfer risk. Is there one person who understands the custom content? What happens when they leave?
- Escalation paths. Tier-1 → Tier-2 → IR — documented and exercised, or improvised every time?
- Reporting cadence. What does leadership see, when, and is it actionable?
What the audit deliverable should look like
A good QRadar audit produces:
- Executive summary — one page, traffic-light rating per layer, top three risks, top three quick wins
- Detailed findings — per layer, evidence, severity, recommendation
- ATT&CK coverage map — technique-by-technique, current state, gap, priority
- Quick-win list — fixes deliverable in under 30 days
- 90-day roadmap — prioritized improvements, effort estimates, expected outcomes
- License recommendation — current waste, recommended renewal sizing, justification
If you don't get those six things, the audit was a sales pitch in disguise.
Common audit findings
Patterns we see repeat across QRadar audits:
- DSM coverage gaps — log sources stuck on universal parsers, breaking detection silently
- Rule sprawl — hundreds of enabled rules, dozens actually firing, single-digits actually actioned
- No ATT&CK map — detection coverage is a hope, not a plan
- Stale TI reference sets — IOCs from 2022 still in the high-priority watchlist
- EPS waste 15–30% — recoverable without losing detection
- Analyst tool fatigue — averaging 8+ minutes per offense triage, mostly UI navigation
- Untested HA — failover never exercised, will fail in the moment it matters
Want the bigger picture? Visit QMasters, learn about our managed cyber security services, or take a look at AI security.
Frequently asked questions
How often should you audit a QRadar deployment?
A full audit annually, with quarterly mini-audits on content health, log source quality, and offense metrics. Always before renewal.
What's the most common audit finding?
Log sources parsed as generic syslog rather than mapped to a proper DSM, breaking every downstream detection. Closely followed by enabled-but-untuned rules generating noise the SOC has learned to ignore.
Can QMasters audit a QRadar deployment I bought from another partner?
Yes. The audit is independent of resale. Many customers audit before deciding whether to renew, migrate, or change their MSSP. The deliverable is a written report and remediation plan you own.
How long does a QRadar audit take?
Typically two weeks of engineering time, plus another week of customer interviews and write-up. Three weeks end-to-end for an enterprise environment.
---
Want a free QRadar audit?
Our IBM Gold-Partner engineers run this exact framework against your deployment and deliver a written gap list, ATT&CK coverage map, and 90-day improvement roadmap — independent of resale. Book your audit →
FAQ
Frequently asked questions.
A full audit annually, with quarterly mini-audits focused on content health, log source quality, and offense metrics. Audit before every renewal — the data drives the renewal conversation, not the other way around.
Log sources parsed as generic syslog rather than mapped to a proper DSM, breaking every downstream detection. The second most common: rules enabled at install time, never tuned, generating noise that the SOC has mentally filtered out.
Yes. We audit independent of resale — the deliverable is a written report, prioritized findings, and a remediation roadmap. Many customers audit before deciding whether to migrate, renew, or change their MSSP.
ABOUT THE AUTHOR
Practitioners from the QMasters Security Operations Center. We run 24/7 monitoring, detection engineering, and incident response for organisations across regulated industries — and write here from the offense and defense work in front of us.