A buyer’s guide · Operating since 2002
SIEM has an awkward commercial property: it is billed by the volume of data you send it, and the data that most improves detection — endpoint telemetry, cloud audit trails, DNS, proxy — is also the highest volume. The pricing model quietly pushes every organisation toward collecting less than it should.
That tension is what this page is about. How to tier data so coverage does not have to shrink, how to meet a retention obligation without paying hot-tier prices for a year of history, and what tuning actually takes.
Economics
The same logs, at three different prices
Where data sits decides the bill far more than how much of it you have. Tiering is how coverage and cost stop being the same conversation.
Why estates end up paying too much
Because sending everything to the hot tier is the installer’s path of least resistance, and nobody revisits it. Debug output, health-check chatter and successful routine polling arrive at the same price per gigabyte as authentication logs.
Filtering at the collector — before ingest — is usually the fastest available reduction, and it changes nothing whatsoever about what can be detected.
Meeting the obligation affordably
CERT-In Direction 20(3)/2022 requires ICT logs retained for a rolling 180 days and maintained within India. Both parts are architecture decisions: the duration shapes your storage design, the location constrains which regions and platforms are usable.
Neither part requires that history to be hot. An archive tier satisfies the duty at a fraction of the cost — on one condition, which is that restoration has actually been tested rather than assumed.
Cost control
Six levers, in the order they usually pay off
None of these reduce detection coverage. Most estates have not pulled any of them, because the platform was configured once and the bill grew quietly afterwards.
Positions are our judgement from what we see in practice. The point is the bottom-right group: it is usually most of the bill and rarely most of the detections.
Tier by question, not by source
Ask what you would do with each log. Data you alert on belongs hot. Data you only search during an investigation belongs warm. Data you keep because you must belongs in archive. Most estates send everything hot by default because that is the installer’s path of least resistance.
Filter at the collector, not the platform
Verbose debug output, health-check chatter and successful routine polling are volume without value. Dropping or sampling them before ingest is the fastest reduction available and it changes nothing about detection.
Separate retention from searchability
A duty to retain for a period is not a duty to keep everything hot for that period. Archive tiers satisfy retention obligations at a fraction of the cost, provided restoration is tested rather than assumed.
Remove detections nobody acts on
Every rule that fires and gets closed without action is paying for noise twice — once in ingest and once in analyst time. Rules should be reviewed for outcome, not just for accuracy.
Watch what new sources actually cost
Adding a chatty source can move a bill materially. Estimating volume before onboarding is a ten-minute exercise that avoids an unpleasant renewal conversation.
Check what you are paying to keep twice
Estates commonly hold the same events in a SIEM, a backup, and the originating platform’s own retention. One of those is usually redundant and nobody owns the question.
Lever four is the one that surprises people. A rule that fires regularly and is always closed without action costs money twice — once to ingest the data feeding it, and again in the analyst time spent dismissing it. Rules deserve review for outcome, not only for accuracy.
The comparison
Log management vs SIEM vs data lake vs XDR vs SOAR
Five things at the collection and correlation layer, quoted against each other constantly. Two of them detect nothing at all, and that is not a criticism — it is what they are for.
Scroll the table sideways →
| Platform | What it does | What it is good at | The honest limitation |
|---|---|---|---|
| Log management | Collects, stores and searches logs. No security opinion. | Retention, evidence, answering “what happened on 14 March”. | Detects nothing. It is the filing cabinet, and a filing cabinet has never noticed an intruder. |
| SIEM | Log management plus correlation rules, detection content and alerting. | Turning many small events into one alert worth a human’s attention. | Priced by ingested volume, so it charges you most for the data that improves detection. Untuned, it produces noise nobody reads. |
| Data lake / security lake | Cheap bulk storage of security data, queried on demand. | Keeping far more, for far longer, at a fraction of hot-tier cost. | Query latency and skill requirements are real. It is where data goes to be kept, not where alerts come from. |
| XDR | Vendor-curated correlation across the sources that vendor supports. | Fast time to value with detections already written for you. | Coverage is bounded by what the vendor ingests, and detection logic is largely theirs — see detection and response. |
| SOAR | Automates the response steps after something is detected. | Removing repeated manual work from confirmed incidents. | Automates decisions somebody already made. It improves nothing about what gets detected — see SOAR. |
The pairing worth understanding is log management and SIEM. A great many organisations genuinely need only the first — retention, search, evidence. Buying the second without funding the tuning gets you the first at the second’s price, which is the most common way SIEM budgets get wasted.
Straight answers
What buyers get wrong about SIEM
SIEM pricing punishes good security
The platform is billed by volume, and the data that most improves detection — verbose endpoint telemetry, full cloud audit trails, DNS and proxy logs — is also the highest volume. So the commercial model quietly pushes every organisation toward collecting less than it should. Recognising that is the first step to designing around it rather than simply losing to it.
“Is this a SIEM or a log archive?”
The distinguishing feature is not the product; it is whether anyone tunes the detections and reads the output. A SIEM that nobody has tuned since deployment produces alerts nobody trusts, which are then ignored, at which point you own an expensive, well-indexed record of an incident you did not notice.
Retention and searchability are different purchases
An obligation to keep logs for a period is an obligation to have them, not to keep them instantly searchable at hot-tier prices for the whole period. Archive tiers meet the duty far more cheaply. The only condition is that restoration is tested rather than assumed — an archive nobody has restored from is a hope.
“What happens to the bill when we add cloud audit logs?”
Cloud audit and DNS are among the most valuable sources for detection and among the most voluminous. Estimate before onboarding. This is a ten-minute calculation that regularly prevents a very awkward renewal.
A SIEM has no opinion of its own
It correlates what someone wrote a rule to correlate. Out of the box it ships with generic content that fits nobody’s estate precisely, and the value comes entirely from the tuning that follows. Budget for the tuning or do not budget for the SIEM.
“Who owns the rules we paid to have written?”
A year of tuning is a real asset. If it exists only inside a provider’s tenancy, changing provider means rebuilding it from nothing, and that cost is rarely visible at the point of signing.
Before you sign
Ten questions for any managed SIEM provider
Use these on us and on everyone else. Question four decides whether you are buying a SIEM or an expensive archive.
What exactly are we billed on — ingest volume, events per second, users, or nodes?
These behave very differently as an estate grows. Ask for the projected bill at 1.5× your current volume, in writing.
Can data be tiered, and can we move it later without re-ingesting?
Some platforms charge again to rehydrate archived data. That cost belongs in the comparison, not in a surprise during an investigation.
How is our retention obligation met, and where does the data physically sit?
CERT-In Direction 20(3)/2022 requires ICT logs retained for a rolling 180 days and maintained within India. Both the duration and the location are architecture decisions.
Who writes and tunes correlation rules after go-live, and how often?
This is the difference between a SIEM and an expensive log archive. An untuned platform is noise, and noise gets ignored within weeks.
Do we own the detection content, or does it live in your platform?
Rules built for you should be exportable. Otherwise switching provider means rebuilding a year of tuning from nothing.
What does adding a new log source cost in effort and in licence?
Both numbers matter. A source that is free to parse and expensive to store still shows up on the bill.
Is 24×7 analyst coverage included, or is this platform operation only?
“Managed SIEM” covers both arrangements. One delivers investigated incidents; the other delivers a well-run dashboard.
Which of our systems will not be sending logs, and why?
There is always a list — legacy applications, appliances, systems whose owners never responded. It should be documented and accepted rather than quietly absent.
Can we produce an auditable timeline for an arbitrary date last year?
This is the practical test of a retention design, and it is worth asking someone to actually demonstrate it.
On exit, what do we receive — raw data, parsed data, rules, dashboards?
Agree the format and the window at contract. Historical log data is what makes leaving a SIEM expensive.
Working with us
How we run this
We operate SIEM as part of a staffed operations centre rather than as a platform subscription, which is why the tuning conversation happens before the licensing one.
Volume estimated before quoting
We size ingest from your actual source list and tell you which sources are worth their volume. Estimating after go-live is how renewals become arguments.
Tiered by default
Alert-worthy data hot, investigation data warm, obligation data archived — with restoration tested rather than assumed.
Tuning is the service
Detections reviewed for outcome, not just accuracy. A rule always closed without action is retired, not tolerated.
Your platform if you have one
Including where a contract requires you to hold the log platform yourself. We start with an audit of what is already running.
Content that transfers
Rules built for you are yours. A year of tuning should not be locked inside a tenancy you rent.
Log source health reported
Sources stop reporting silently. We report that monthly, because nobody notices until an investigation needs the data.
Questions we get asked
Managed SIEM, answered
What is managed SIEM?
A service in which a provider runs the SIEM platform for you: onboarding log sources, writing and tuning correlation rules, monitoring what the platform produces, and investigating what matters. The platform may be yours or theirs. What separates a genuine managed SIEM from platform babysitting is whether analysts investigate the output or simply keep the system running.
What is the difference between log management and SIEM?
Log management collects, stores and searches logs. It answers “what happened on 14 March” and it detects nothing — it is the filing cabinet. A SIEM adds correlation rules and detection content on top, turning many small events into one alert worth someone’s attention. Many organisations genuinely need only the first, and buying the second without funding the tuning gets you the first at the second’s price.
Why is SIEM so expensive?
Because it is priced by the volume of data ingested, and the data that most improves detection is also the highest volume — endpoint telemetry, cloud audit trails, DNS, proxy. The commercial model therefore pushes organisations toward collecting less than they should. The answer is not to collect less but to be deliberate about where data sits, which is what the tiering diagram above describes.
How do we reduce SIEM costs without reducing coverage?
Tier by question rather than by source: alert-worthy data hot, investigation data warm, obligation data in archive. Filter noise at the collector before ingest — debug output and routine health checks are volume without value. Separate retention from searchability. Retire rules nobody acts on. And check whether you are paying to keep the same events in three places, which estates commonly are. The six levers section above works through each.
What are the CERT-In log retention requirements?
CERT-In Direction 20(3) of 2022 requires organisations to maintain logs of their ICT systems for a rolling period of 180 days, maintained within India. Both parts are architecture decisions rather than policy statements — the duration drives your storage design and the location constrains which regions and which platforms are usable. Crucially, it is a duty to retain, not a duty to keep 180 days instantly searchable at hot-tier prices.
Which SIEM platforms do you work with?
We run FortiSIEM most often, and we operate customer-owned platforms including the major commercial and open-source options where you have already made that investment. Where you have no platform yet, the honest recommendation depends on your volume, your team’s skills and your retention obligation rather than on a feature comparison — the licensing model will affect your costs more than the feature list will.
Can you run the SIEM we already own?
Yes, and it is a common arrangement, particularly where a contract or regulator requires you to hold the log platform yourself. Expect the first phase to be an audit of what is already there — platforms that have run without a dedicated team almost always carry detections nobody has reviewed in a year and log sources that stopped reporting without anyone noticing.
How long does SIEM implementation take?
First sources typically ingest within days. Meaningful detection coverage takes weeks, and the constraint is tuning rather than integration. A platform freshly pointed at a network produces a great deal of noise, and the value comes from the baselining that follows. Treat any promise of reliable detection on day one as a description of alerting rather than detection.
What log sources should we prioritise?
Identity and authentication first — it is where a large share of real intrusions are visible and the volume is modest. Then endpoint telemetry, cloud audit trails, and firewall deny events. DNS and proxy are extremely useful and extremely voluminous, so onboard them deliberately with an estimate rather than by default. Anything you would not act on can wait.
Is a SIEM the same as a SOC?
No, and conflating them is the most expensive mistake in this area. A SIEM is a platform; a SOC is a function of people, process and technology. A SIEM with nobody reading its output is a compliance artefact producing alerts into a void. See managed SOC services for what the function involves.
How does SIEM relate to XDR and SOAR?
XDR is vendor-curated correlation across the sources that vendor supports, which gives faster time to value inside a narrower boundary. SOAR automates the response steps after something is detected and improves nothing about what gets detected. SIEM is the broad collection and correlation layer that can ingest anything producing a log, including systems no agent will ever reach. The comparison table above sets out all five side by side.
Do we get the correlation rules if we leave?
You should, and you should require it in writing from any provider. A year of tuning is a genuine asset, and if it exists only inside a provider’s tenancy then changing supplier means rebuilding it from nothing. We build content in a form that transfers.
What does the monthly reporting look like?
Detections raised and their disposition, tuning changes made and why, log source health including anything that stopped reporting, ingest volume against the plan, and retention position against your obligation. The log source health section is the one worth reading — sources silently stop, and nobody notices until an investigation needs them.
How is this priced?
By ingest volume and by whether analyst coverage is included. We will estimate volume from your source list before quoting rather than after, and we will tell you which sources are worth their volume and which are not. If a smaller retention footprint meets your obligation, we will say so.
Next step
Send us your source list, not your requirements
Which systems you want logged, roughly how many of each, your retention obligation, and your current bill if you have one. We will estimate the volume, show you what tiering would do to it, and tell you honestly which sources are not worth what they cost to keep hot.