SIEM tools: how to choose a SIEM security tool

The short answer: you choose a SIEM security tool on a handful of numbers, not on a feature list. How much log data you produce and how the vendor charges for it, how many of your sources are already supported, how many detections work on day one, how far back you can search, whether the platform runs in the cloud or in your data centre, and who will run it once the project team has gone home.

This is not a league table. It is the list of criteria that separate a SIEM that still works after six months from an expensive archive of unread alerts, with examples from the public documentation of Google Security Operations and Microsoft Sentinel.

Before the products: your own numbers

No comparison makes sense until you have five figures in hand. A serious vendor will ask for them on the first call.

• Daily log volume, in GB per day or events per second. It moves the bill more than anything else.
• The list of sources, with make and version: firewalls, EDR, identity, cloud accounts, business applications, legacy systems and any OT.
• Required retention, separating what compliance asks for from what an investigation needs.
• Detections actually in use, not the ones switched on: how many rules produce alerts that someone looks at.
• Hours of cover: who reads the alerts, in which shifts, and what happens on a Friday night.

For managed service providers, managed security service providers, cloud and data centre providers and the other digital providers it covers, Commission Implementing Regulation (EU) 2024/2690, which details the NIS2 risk-management measures, asks for a list of assets subject to logging based on the risk assessment. Where appropriate, logs include network traffic, user and permission changes, authentication events, privileged access, changes to critical configuration and backup files, and security tool logs such as firewalls and intrusion detection systems (Annex, point 3.2.3). Outside that group, it is still a sound checklist to test any SIEM against.

Cloud or on-premises: what actually changes

Today the question is less about where the data sits and more about who carries the operational load.

On-premises: you run the platform as well as the detection

With a self-hosted SIEM, storage sizing, upgrades, scaling and the availability of the platform itself are your team's job. The same Implementing Regulation asks that monitoring and logging systems be redundant and that their availability be monitored independently of the systems they monitor (point 3.2.6). On-premises, that redundancy is hardware and hours you plan and pay for.

Cloud: check data location, terms and the exit

A SaaS SIEM removes the infrastructure work and moves the scrutiny to the contract. The first question for a European buyer is where the data lives. Google publishes the locations available for Google SecOps SIEM and SOAR: a Europe multi-region with data centres in Belgium, the Netherlands and Finland, and single regions in London, Frankfurt, Zurich, Paris, Turin and Warsaw, among others. Ask every vendor for the equivalent page, and read it next to your privacy and sector requirements.

The second question is the exit: in what format you get your raw data back, and how long it takes, if you change platform in three years.

Hybrid is the normal case

Most mid-market estates combine a cloud platform with local collectors for on-premises sources and OT networks. What matters is where filtering happens, because that decides what you pay to ingest.

Criterion 1. The cost model follows volume, not the software

The first question is not how much, but what you pay for. The two most common cloud models are both tied to data.

• Packages priced on ingestion. Google documents three Google SecOps packages, Standard, Enterprise and Enterprise Plus, and states that "the pricing for all packages is based on ingestion volume". Hot retention is part of the package, which keeps the bill readable.
• Consumption by data tier. Microsoft Learn states that for Microsoft Sentinel "pricing is based on the tier that the data is ingested into". The analytics tier is billed pay-as-you-go or through commitment tiers that start at 100 GB per day; you can raise a commitment tier at any time, while lowering it is only allowed every 31 days. A separate data lake tier is billed on the use of its capabilities, such as ingestion, processing, storage and queries.

In both cases the lever is not the discount you negotiate but how much data you send and in what form. Before signing, find out which sources are noisy and whether the platform can filter or transform data before ingestion. In Google SecOps this varies by package: the Standard package lists limited filtering and transforms, while Enterprise adds advanced data processing to filter, redact and transform data from cloud and on-premises sources. Our observability and SecOps service starts from exactly this volume analysis.

Criterion 2. Source coverage, checked against your inventory

Every platform advertises hundreds of integrations: what counts is whether yours are among them. Google SecOps, for example, normalises incoming telemetry into its Unified Data Model and lists over 300 prebuilt SOAR integrations in the Standard package. A good base, but the check is still yours.

Take your source list and ask the vendor, line by line, whether a parser exists, whether they maintain it, and what happens when the source changes its log format. The awkward answers usually come from vertical business applications, custom-built systems and industrial equipment. A source without a parser is a project, not a box to tick: estimate it with its own hours and owner, or it will reappear after go-live as a blind spot.

Criterion 3. How many detections work on day one, and which

A SIEM without rules is a search engine for logs. The first month depends on the detections the vendor writes and maintains, and that content changes with the package.

In Google's package comparison, Standard allows 1,000 single-event and 75 multi-event rules with a subset of curated detection rules. Enterprise raises the limits to 2,000 and 200, includes unlimited curated detection rules, UEBA and Gemini in Security Operations. Enterprise Plus goes to 3,500 and 400 and adds emerging and active IR threat detections and alert prioritisation for EDR alerts.

In the demo, ask which detections are active on day one, on which of your sources, with what coverage of the MITRE ATT&CK techniques relevant to your sector, who maintains them when a technique changes, and how many rules specific to your environment you will still need. The last question decides the project: no catalogue of ready-made rules knows that one server has been sending odd traffic for nine years for a perfectly good reason.

Criterion 4. Retention: how far back you can look

The criterion most underrated during selection and most regretted during an incident: the entry point of an intrusion is often weeks before the alert that woke you up.

• For Google SecOps, the documentation states that "by default, Google retains 12 months of your data", and the period can be extended up to five years as part of the purchase order. The Standard package describes this as 12 months of hot data retention, searchable at no additional cost beyond ingestion.
• For Microsoft Sentinel, data ingested into the workspace is retained at no charge for the first 90 days; retention beyond 90 days is charged at standard Log Analytics retention prices, and high-volume, lower-value tables can be moved to the lower-cost data lake tier.

Under Article 23(4) of Directive (EU) 2022/2555 (NIS2), essential and important entities send the CSIRT or competent authority an early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours, and a final report no later than one month after the notification. That final report includes the type of threat or root cause and the mitigation measures applied. If the logs from the period when the attacker got in have already expired, the root cause becomes a guess. The Implementing Regulation also asks covered entities to keep and back up logs for a predefined period (point 3.2.5): choose that period deliberately and write down why. More on the obligations in our NIS2 service.

Criterion 5. Time to a working platform

Switching on a cloud platform is quick. The real time goes elsewhere:

• Connecting sources one by one and checking that every event arrives, not just the first ones.
• Checking that parsers extract the useful fields: a log that comes in but is not parsed properly looks like coverage and is not.
• Tuning rules to your context and cutting false positives to a number one shift can handle.
• Defining what happens when an alert fires: who picks it up, how fast, and who gets woken.

Ask for the plan in phases, with dates, owners and exit criteria, and ask who does the work: the vendor, a partner, or your own team alongside everything else. For financial entities, Article 10 of Regulation (EU) 2022/2554 (DORA) asks for mechanisms to promptly detect anomalous activities, with alert thresholds and criteria that trigger incident response, and requires that these detection mechanisms be regularly tested. A one-off acceptance test at go-live is not enough: detection is ongoing work. See our DORA service for the wider framework.

Criterion 6. Who writes the rules after the first month

Detection engineering never ends: every new application, migration or acquisition creates rules to write, test and maintain. And rules are written in the platform's language. Google SecOps uses YARA-L, Microsoft Sentinel uses KQL, others have their own syntax. An open format, Sigma, describes itself as "a generic, open, and structured detection format" and lets you convert rules to supported backends, but every conversion still needs testing. Detection work is only partly portable, which matters for any future move.

Put these questions in the contract, not in the conversation: how many new rules per month are included, who writes and validates them, where they are documented, and who answers if a rule stops working after an update.

Criterion 7. What happens when the analyst leaves

In many mid-market organisations one person really knows the platform: the one who ran the project and remembers why a rule was muted in March. When that person leaves, the SIEM keeps producing alerts that nobody reads any more.

This is a continuity risk, not a technical one. NIS2 lists incident handling among the minimum risk-management measures (Article 21(2)(b)), and DORA asks financial entities to devote sufficient resources and capabilities to monitor user activity, ICT anomalies and ICT-related incidents (Article 10(3)). Before signing, answer three questions: where the operating procedures are written, who covers nights and weekends, and what happens during the summer holidays. If nobody is the honest answer, a 24/7 managed SOC on top of the platform is the piece to budget alongside the licence.

The questions to put in your request for proposal

Six questions that produce comparable answers a slide cannot dodge.

1. What exactly do I pay for, and what happens to the bill if my log volume grows by 30%?
2. Which of my sources, from my list, have a ready parser that you maintain?
3. Which detections are active on day one, and which need a higher package?
4. How many months of data stay searchable at no extra cost, and what does going further involve?
5. How many new rules per month are included, who writes them, and who watches alerts out of hours?
6. If I change platform in three years, what do I take with me: raw data, rules, case history?

The software is half the job

The criterion that weighs most does not appear on any datasheet: who makes the tool work every day. A well-chosen SIEM that nobody runs gives the same result as a badly chosen one, at a higher cost. For a sense of what is at stake, IBM's Cost of a Data Breach Report 2026 puts the global average cost of a breach at USD 4.99 million, a 12% increase on the previous year.

AmagisTech is a Google Cloud partner and runs managed SOC services for mid-market organisations, adding detection engineering and continuous monitoring on top of Google Security Operations. If you want to test your numbers, log volume, sources and hours of cover, before you sign a licence, talk to our team.

In short: judge a SIEM security tool on its volume-based cost model, real coverage of your sources, included detections, retention, deployment model, time to a working platform, and who writes the rules and covers the alerts after month one. The first half is in vendor documentation. The second half depends on your team.