The security information and event management (SIEM) platform at my last fintech had, on paper, full coverage. Every endpoint, identity provider, and cloud account sent telemetry to it, and the ingest bill looked like proof. Then an attacker signed in through our virtual private network (VPN) with a credential from an infostealer dump and spent two days moving laterally. Every event was sitting in the index. Not one rule fired.
That silence was a detection-engineering failure, not a logging one. I found the activity on a TTP-based hunt, wrote the detection that week, tested it against the historical logs, and shipped it, and it has fired on real credential abuse since. The SIEM gave us centralized collection, retention, search, and a place to run analytics. But it did not supply the local detection logic, validation, and maintenance that turn raw events into an alert anyone can trust.
This distinction matters because SIEM spend is often treated as detection spend when it is not. SIEM in cyber security gives you aggregation, search, retention, compliance, and native analytics, much of it priced on ingest. Detection value lives in the engineering built on top.
In brief:
- Logging everything does not detect anything; turning stored logs into alerts is an engineering job, not a data-collection one.
- Ingest-based pricing punishes the exact telemetry detection needs most, pushing teams to drop high-value logs to control the bill.
- SIEM rules break quietly and stop firing, and the staffing to keep the rule library alive can rival or exceed the platform bill.
- The platform's durable value is compliance retention and forensic search. A detection strategy is a separate investment, and most budgets pretend it is not.
Buying a SIEM is not buying a detection strategy
A SIEM combines log aggregation, event correlation, alerting, search, compliance reporting, and native analytics in one platform, which is a real capability. But the platform records and processes events without deciding which activity matters in your environment. The orthodoxy treats the license as the capability: deploy the platform, point the log sources at it, and the detection box on the board slide turns green.
Native analytics and a rule engine are not a detection program. A program exists only when a team defines threat hypotheses, writes and tunes local logic, tests it, and revises it as telemetry changes. Without that work, the platform stores the evidence of an attack without ever flagging it.
What a SIEM actually gives you
Aggregation and retention preserve evidence across systems. Search turns that evidence into something investigators and auditors can use.
Aggregation and search are what make forensics possible
Payment Card Industry Data Security Standard (PCI DSS) retention rules require at least 12 months of audit-log history, with the most recent three months immediately available. The Health Insurance Portability and Accountability Act (HIPAA) Security Rule documentation retention covers six years of specified compliance records, not every security log. CIS centralized logging guidance names SIEM as an example of centralized audit log collection.
Centralized aggregation, fast search across sources, and an immutable retention store satisfy auditors and make incident forensics possible. I have run investigations that would have been dead ends without that search layer.
Logs require detection logic before they detect anything
Vendor-shipped content is what most teams mean when they say the SIEM detects, and it rarely works out of the box. In my experience, vendor-provided rules create noisy starting points until they are locally tuned, and continuously maintained detections behave nothing like static rules a team rarely revisits.
The failure mode is not hypothetical. During the Target breach, monitoring generated warnings while exfiltration malware was being staged, but the company did not act on them in time. Generating alerts is not the same as having a working detection-and-response capability, which also needs usable alert logic, defined ownership, triage capacity, and escalation paths. Target did not prove that alerts are useless, only that alerts alone are not enough.
Where the tax comes from
Ingest pricing raises the cost of collecting telemetry. Rule maintenance consumes engineering time after deployment. Both costs grow as the environment changes.
Ingest-based pricing punishes the logs you need most
Many major SIEM deployments are priced partly by ingestion, and one processing significant daily volume can incur a substantial annual license bill before anyone writes a rule. Models vary by vendor and contract: Splunk offers ingest, workload, and entity pricing, while Microsoft Sentinel prices analytics around reserved or pay-as-you-go daily ingestion capacity. Log volume tends to grow year over year, so the bill compounds on its own.
Ingest-based pricing creates a structural incentive to monitor less. I have seen security operations centers (SOCs) switch off noisy sources such as firewalls and endpoint detection and response (EDR) to control cost. Teams also skip detailed process-creation logging such as Windows Event ID 4688 to save on storage. Process-creation telemetry is exactly what credential-abuse and lateral-movement detections depend on.
CISA and the Australian Signals Directorate list EDR telemetry among the highest-priority logs for SIEM ingestion, and Sumo Logic reports that blind spots remain widespread. When the meter runs on ingest, the logs most likely to catch an attacker are often the first ones challenged in the chief financial officer (CFO) conversation.
Maintenance and rule upkeep are the hidden line item
I have repeatedly found SIEM rules unable to fire after a data-source misconfiguration or parsing error. The breakage is quiet, because a parser update, schema change, or process rename can silently invalidate working logic. The pipeline itself needs monitoring for parsing health, field population, and rule-match volume. I hit this after a log-source upgrade renamed a field: the rule stayed active while nothing would ever have matched.
Then there is the people cost. An enterprise SIEM needs dedicated staff to operate, and in my experience staffing and content maintenance often rival or exceed the platform bill. In the 2025 SANS Detection Engineering Survey, resource and time constraints were the primary obstacle for 71% of organizations, even with 67% reporting strong executive support. The platform budget did not include the engineering capacity required for upkeep.
Where detection actually comes from
Custom logic determines which events become useful alerts. Testing and upkeep keep that logic working as telemetry changes.
The engineering on top is what creates detection
In 2023, the Chinese-affiliated Storm-0558 actor forged authentication tokens against Exchange Online tenants. The U.S. State Department caught the intrusion with a custom "Big Yellow Taxi" alert built on enhanced logging that few other victims had acquired, as the Cyber Safety Review Board found. Microsoft later detailed the forged-token technique affecting roughly 25 organizations.
The practitioners who build this content say the same thing. Anton Chuvakin has made a team-first SIEM argument: a great team operating an average SIEM will outperform an average team operating a great one. Florian Roth, who created Sigma partly to free detection logic from proprietary query languages, has argued the same about expertise being the expensive and valuable part.
Mature teams run detection as code
Mature teams already operate this way, and in the 2025 SANS Detection Engineering Survey, custom-developed content was the leading detection source at 42%, ahead of vendor-provided content. The mature programs I have seen apply detection-as-code discipline: version control with peer review, integrated into continuous integration and continuous delivery (CI/CD).
When I implemented detection-as-code in my last software-as-a-service (SaaS) environment, every rule needed positive and negative test fixtures, followed by a week in shadow mode before it could page anyone. The shadow-mode discipline turned our rule library from a liability into an asset, because the SIEM provided the runtime while engineering produced the detection.
What SIEM is legitimately for
The platform earns its budget as infrastructure. The detection program is a separate line item, and treating the two as one is how teams overpay for storage and under-invest in engineering.
Keep the SIEM as infrastructure, fund detection as a program
Keep the SIEM for what it does well: compliance retention, centralized aggregation, and forensic search when an incident is live. Then stop paying detection prices for storage. A decoupled pattern routes long-horizon compliance and investigation logs to cheaper object storage and reserves the SIEM for time-sensitive telemetry that drives real-time detection. The trade-off is slower retrieval and more integration work, so the savings are real but not free.
Draw the line between platform and program
Here is the division of labor I hold teams to, so nobody confuses the platform line item with the program it is meant to fund. The SIEM collects, normalizes, and retains telemetry, supplies the query and correlation runtime, keeps the platform available, and shows you dashboards. None of that decides which activity matters.
Detection is the other half, and it is all engineering. Engineering sets data-quality and onboarding criteria, tunes the local logic that decides what actually alerts, and builds the fixtures and adversary emulation that prove a rule fires.
Engineering also monitors parsers and schema changes so rules don't die quietly, and retires stale content through coverage reviews. Everything there is labor the platform budget did not buy, and it is where detection comes from.
The audit I would run this week
Pull your full rule inventory, map it against the MITRE ATT&CK techniques that show up in your incidents, and test which rules still fire against sample events. When I did that at my last SOC it took two days and rewrote our roadmap. The SIEM kept its budget line as a log store and compliance record; the detection budget moved to engineers who wrote, tested, and retired rules. Their work had produced the detections all along.
Frequently asked questions about SIEM in cyber security
What is SIEM in cyber security?
I use SIEM to mean a platform that aggregates logs from across your environment, correlates events, generates alerts, and produces compliance reporting from a central store, recording and searching what happened while your team's rules determine what matters. The quality of its detection output depends almost entirely on the rules your team writes and maintains on top of it.
Does a SIEM detect threats on its own?
Not without local engineering. Vendor-shipped content remains a noisy starting point that produces false positives until locally tuned, and without that tuning it does not reflect how your environment changes. Out-of-the-box content gives you a starting library that still requires local engineering and maintenance to become real detection.
Why is SIEM so expensive?
Cost models are often dominated by ingest volume, and log volume grows every year. The license is also only part of the cost: staffing to operate and tune the platform can rival or exceed the platform bill, and rule maintenance, storage tiers, and false-positive triage sit on top of that. The bill grows whether or not detection improves.
What actually makes a detection strategy?
A detection strategy is an engineering program: custom rules built for your environment, version control and peer review, CI/CD deployment with positive and negative test fixtures, adversary emulation to validate that rules fire, and a lifecycle that retires broken content. The program also measures outcomes such as false-positive rate and time to detect rather than counting active rules. The SIEM provides the substrate for this program, while the engineering work provides the capability.