SIEM Implementation: The Parts That Decide Whether It Works

Most SIEM projects are judged on the wrong thing. They ship a platform, connect sixty log sources, write four hundred correlation rules, and declare success - and then for the next two years the platform answers nothing, because the questions that matter were never specified. A SIEM exists to answer four questions fast enough to act on: who did this, what changed, what left, and what talked to what. Everything else - the licence, the parsers, the dashboards, the ATT&CK heat map - is machinery in service of those four. This guide is about the decisions that determine whether the machinery works: which sources earn their ingestion cost, how you detect a source that has silently stopped forwarding, where retention has to sit against real detection time, how to tell proven coverage from claimed coverage, and the staffing arithmetic that should decide whether you build this at all.

Four questions, and the one nobody instruments

Write the four questions on a wall and score every design decision against them. Who did this is identity: authentication logs from every identity provider you have, including the ones nobody remembers, plus the directory changes that create or privilege an account. What changed is configuration and control plane: cloud audit trails, firewall policy commits, DNS record edits, group membership, service principal credentials. What left is egress: proxy, DNS, mail flow, cloud storage access. What talked to what is network and endpoint telemetry.

Almost every SIEM answers the first question passably, the second badly, and the fourth as a wall of noise. The reason is that source selection is usually driven by what is easy to connect rather than by which attack step the source makes visible. A verbose perimeter firewall that logs every denied packet produces enormous volume and answers almost none of the four - it is the most commonly over-ingested device in the estate. A cloud control-plane audit trail that nobody enabled produces nothing and answers the two questions that decide most modern incidents.

That asymmetry is the whole argument of this page: the sources you did not connect and the sources that quietly died are the two failures that no dashboard shows you. The joint NSA and CISA practitioner guidance published in May 2025 makes the same point in operational terms, telling organisations to build processes that identify when systems have stopped generating logs and telemetry at all. That is a control, not a monitoring nicety, and it is the one thing this guide puts ahead of detection content.

Five things to specify before you compare platforms

Platform comparisons are decided by licence cost and demo dashboards, which is why so many are wrong. Settle these five first, in writing, because each one constrains the platform rather than the other way round.

Two of those five are commercial rather than technical, and they are the two that decide whether the project is still viable in year three. Detection content written by an implementation partner in a proprietary query language, with no export clause, is a renewal negotiation you cannot win. Fix it in the statement of work, not in year two.

Choose sources by attack step, not by device inventory

The instinct is to onboard everything and let correlation sort it out. That produces a platform that is expensive, slow and blind in the places that matter, because correlate-everything hides the absence of a signal inside an excess of them. The alternative is to work backwards from the attack steps you intend to see.

The tier-one set is small and has been stable for years. Identity provider events, including MFA and conditional access decisions and administrative changes to roles and federation. Endpoint detection telemetry, not just antivirus. Cloud control plane audit trails for every account and subscription. Email security and mail-flow events. DNS, which is the cheapest high-signal egress source in existence. Remote access - VPN, and any zero-trust or remote-desktop gateway. Perimeter and edge devices with policy change events, not per-packet denies. And the applications that hold the data the business would be embarrassed to lose.

Sequence by coverage per unit of ingest cost, not by project plan aesthetics. The practical test for each source is a sentence you should be able to write before connecting it: "this source lets us detect this technique, and this person will look at the alert". If you cannot write the second half of that sentence, the source is not ready to onboard - and onboarding it anyway is how a SIEM acquires the data lake nobody queries.

A word on timing. The published phase timelines for a mid-size enterprise run six to nine months from kickoff to a stable system, with log onboarding in the early weeks and tuning in the middle. Treat those numbers as the outside of the range, not a plan. The first month should produce a platform that answers three of your fifteen questions end to end, with a health check on every source, rather than one that ingests everything and answers none.

The silent source is the failure nobody instruments

This is the most expensive defect in security monitoring and the least discussed. A source that was never connected is a known gap. A source that connected, worked for a year, and then stopped is worse than a gap, because every dashboard still lists it as enabled. Analysts see a quiet week and read it as a quiet week.

The concrete ingredients, in order of how often they actually cause the silence:

The field-population assertion is the one most teams skip and the one that catches the nastiest class of failure. A parser update lands, events keep arriving at the same rate, and every user field is now empty - the volume graph is flat and the detections are blind. Measure the ratio, alert on it, and store the ratio alongside the volume so a slow drift is visible.

Then test the control. Once a quarter, stop one source deliberately, and require the health check to fire and route to the right person within its stated window. A monitoring control that has never been triggered is a hypothesis, and this one is cheap to prove.

Ingest cost is an architecture decision, not a licence negotiation

Analytics-tier pricing is metered per gigabyte, and the published rates for the major cloud SIEMs sit in the low-to-mid single digits of dollars per gigabyte ingested, before commitment discounts and regional variation, with separate meters for long-term storage, query volume scanned and processing. Do the arithmetic before you sign, because it is unforgiving at scale.

Three rules keep this from becoming a renewal crisis.

Measure before you commit. Run thirty days of collection at full fidelity, then attribute gigabytes per source. Every platform can report volume by source or by index; the number that matters is the one attached to a device nobody can name an owner for.

Let your own query logs decide what to drop. The internal audit of searches that every platform keeps tells you which fields and sources have actually been queried in the last ninety days - Splunk exposes this in its audit index, and cloud platforms log every query per workspace. Fields with zero queries in ninety days are candidates for filtering at ingest, and the ones queried constantly are not, whatever their volume.

Filtering is irreversible, so route before you drop. Ingest-time filtering - a data collection rule transformation, or a props-based route to the null queue - discards the event before it is stored. That is the right tool for a deny-per-packet feed you only ever need as a count, and the wrong tool for anything an investigation might want later. Send the raw feed to cheap object storage with a lifecycle policy first, filter in the SIEM second, and you keep the ability to answer a question you did not anticipate at a tenth of the cost of analytics-tier retention.

Two categories deserve explicit decisions rather than defaults: full packet capture and message content. Neither belongs in a SIEM, both can usually be summarised into metadata that answers the same investigative question, and both carry legal consequences discussed further down.

Retention: three tiers and a restore test you can time

Retention is usually set to whatever the platform gives by default, and the platform default is set by a commercial model rather than by your detection time. The gap is not academic. The IBM 2025 breach study puts the mean time to identify and contain an incident at 241 days, with internally detected incidents found in 172 days. Against that, the useful defaults are short: AWS CloudTrail event history keeps 90 days of management events per region, the Okta system log 90 days, Entra ID sign-in logs 30 days on the paid tiers and seven on the free tier, the Microsoft 365 unified audit log 180 days on standard licences, and the Azure activity log 90 days. A compromise discovered in June has an identity log window that closed in April.

The fix is architectural. Three tiers, each with a stated purpose and a stated restore time.

Then do the thing almost nobody does: time a restore. Pick a random day eleven months back, restore the events for one source, and measure from request to a query that returns the expected records. If nobody has ever run that test, treat the archive as unverified - metered archive queries are charged per gigabyte scanned, so a broad search across a year of data can cost more than the storage did, and knowing that before an incident is the difference between a focused extraction and a four-figure query that times out.

The compliance floor is worth stating separately, because it is a floor and not a target. PCI DSS v4.0 requires audit log history retained for at least twelve months, with the most recent three immediately available for analysis. HIPAA expects audit controls that record and examine activity in systems holding electronic protected health information. ISO/IEC 27001:2022 covers this in Annex A 8.15 for logging and 8.16 for monitoring activities. Financial entities under DORA have to detect anomalous activities under Article 10 and manage incidents under Article 17, and NIS2 Article 21(2) requires incident handling and a policy that assesses the effectiveness of the measures - logging is how you evidence both. None of those numbers is your detection time, and the longer of the two wins.

Normalisation, clocks and the fields you will wish you had

Correlation is only as good as the join keys, and the join keys are usually the part of the project that gets skipped. Normalise to one schema - the Open Cybersecurity Schema Framework, the Elastic Common Schema, or the platform model - and be explicit about the fields that must survive every parser: a user identifier that resolves to one person, a device identifier that resolves to one asset, a source and destination address, an action, and an outcome.

Timestamps deserve their own paragraph because they are where quiet failures live. Every source should log in UTC in ISO 8601 with the year first, and every device should synchronise to the same time source - ISO/IEC 27001:2022 calls this out as Annex A 8.17, clock synchronisation, for the obvious reason that an event order built from unsynchronised clocks is fiction. Two practical checks: confirm the offset of each source against a known event rather than trusting its configuration, and watch the ratio of events whose parsed timestamp is more than five minutes behind arrival. A collector with a full queue produces events that arrive late, which silently breaks any detection with a correlation window.

Transport is the other quiet failure. Plain syslog over UDP is fire-and-forget: the sender cannot know the receiver dropped the event. Use TLS transport on the standard secure port, keep collector disk from filling, and buffer at the source so a receiver outage produces a delay rather than a hole.

Finally, the fields that cost nothing now and everything later: the person behind a service account, the business owner of an asset, the environment tag, and whether a source address is internal. Enrichment at ingest is cheap. Enrichment during an incident, when the asset database is the only place the answer exists and it is being restored from backup, is not.

Coverage you can prove versus coverage you can claim

Every SIEM project produces a heat map of ATT&CK techniques coloured by whether a rule exists. It is the most misleading artefact in the discipline. A rule existing means someone wrote a query. It does not mean the query fires, that the required telemetry is present at the time of the attack, that the alert routes to a human, or that the human can act. A rule that fires four hundred times a day against production is not coverage; it is the reason the analysts stopped reading.

Replace the map with three questions per claimed technique.

• Is the telemetry present? Named source, named field, verified by a query that returns a real event from the last seven days. Not "we have EDR" - the specific event type the detection needs.
• Has it fired on purpose? An atomic test run in a controlled scope, with the resulting alert recorded against the technique. Atomic Red Team and Caldera exist for exactly this; an hour of controlled testing converts a claim into a fact.
• Does it survive the environment? A detection tested against a clean lab often dies on contact with a production estate full of automation accounts, backup jobs and CI/CD roles. Record the expected false-positive volume for every rule and treat "unknown" as unproven.

Keep the mapping, but as a by-product of that process rather than the deliverable. DeTT&CT-style scoring, which separates visibility from detection and scores the quality of each, is more honest than a binary colour, and it makes the gaps arguable in a budget meeting, which is where they need to be arguable.

The day-one detection set

If the platform is new, these are the detections to have working before the wider catalogue. Each one catches a step that appears in a large share of real intrusions, and each is verifiable with a modest amount of setup.

Twelve detections, each with a named owner and a documented expected false-positive volume, beat four hundred imported rules with no owner. Import the community sets - Sigma conversions, platform content packs - afterwards, as a source of candidates to be validated one at a time, never as coverage.

Alert design: the arithmetic that decides whether anyone looks

Alert volume is a budget, and it is spent in analyst minutes. Run the arithmetic before you enable a rule set: at one hundred alerts a day and twelve minutes of honest triage each, that is twenty hours of work a day before anything is investigated properly. Spread across analysts who spend perhaps seventy percent of a shift on queue work, it is close to six full-time equivalents just to triage. If you do not have six, the queue does not shrink - it becomes a scroll, and the forty-first alert of a shift gets thirty seconds.

Which is why severity should be computed rather than asserted. A workable model multiplies three things: the fidelity of the technique (how often this pattern is genuinely malicious in your estate, measured rather than assumed), the criticality of the asset, and the privilege of the identity involved. A medium-fidelity rule on a laptop and the same rule on a domain controller with a privileged account are not the same event, and any platform that scores them identically will teach a team to ignore both.

Three mechanics make this survivable. Group by entity, so forty events about one host become one case rather than forty alerts. Prefer risk accumulation over thresholds for low-fidelity signals: a single unusual command is nothing, six in an hour across an identity and its host is a story. Put the next action in the alert title - isolate host, revoke sessions, verify with the user - because an alert whose first step requires research is an alert that waits.

Tuning without going blind: suppression is a loan, not a payment

Every tuning decision trades noise now for blind spots later, and the trade is only safe if it expires. Three rules keep suppression honest.

Suppress entities, not strings. Excluding the text of a known-good command line exempts the attacker who copies it. Excluding a named service account, on a named host, for a defined period, does not.

Every exception carries an owner and an expiry date. Ninety days, renewable once with a written reason. Unexpired exceptions appear in the monthly review, and an exception nobody can justify is deleted rather than renewed.

Distinguish benign from undetected. Counting an alert as a false positive when the truth is "we could not tell" flatters the metric and hides the gap. Track three outcomes separately: benign-true, false-positive, and unable-to-determine. The third is the number that tells you whether a detection is well built or merely well scored.

Tuning also has a floor. If a suppression list grows past a handful of entries, the rule is probably wrong about the environment rather than noisy, and rewriting the logic - usually by joining on asset criticality or identity privilege - is cheaper than maintaining twenty exceptions.

Response wiring: what the platform may do without a human

Automation is where a SIEM earns or loses trust, and the dividing line is consequence rather than complexity. Actions that are reversible and time-critical are good candidates: disabling a session, blocking a domain at the proxy, isolating a host at the network layer, forcing a step-up authentication. Actions that destroy state are not: wiping a device, deleting mailbox content, disabling an account without a recovery path, closing the ticket.

Two ordering facts from incident response apply directly to playbooks. Revoke sessions before you reset the password, because a password reset does not evict a live session and the attacker keeps working through the token. Preserve before you clean, because the isolation action that reboots a host destroys the memory image that would have explained the intrusion. A playbook that automates containment without preserving volatile state automates the loss of the evidence.

Then set the approval boundary in the runbook: which automated actions may proceed unattended, which require a second human, and what the rollback is for each. An action with no rollback sits behind an approval, without exception.

Build, buy or co-manage: the staffing arithmetic

The platform decision gets all the attention and the staffing decision determines the outcome. Covering one seat around the clock is 8,760 hours a year. One analyst, after holidays, training, sickness and the honest distinction between hours paid and hours productive, contributes roughly 1,760. That is 4.98 people per continuously staffed seat before you add a second seat for weekends, a detection engineer, or a manager - which is why the realistic floor for round-the-clock operation lands between eight and twelve full-time equivalents, and why the loaded cost of that floor is commonly put between 1.3 and 2 million a year in salary alone.

Set that against the alternatives honestly. A managed detection service is commonly priced per endpoint per month, and at a thousand endpoints even the upper end of the published range costs less than the salary floor - while accepting that the provider does not know your business, cannot make your risk decisions, and will hand back alerts you still have to own. A co-managed split - internal coverage in business hours for the things only you understand, a provider for nights and weekends and first-line triage - is often the correct answer for organisations between a few hundred and a few thousand endpoints.

The decision rule that survives scrutiny is not which option is cheaper but which work must stay inside: deciding what a detection means for your business, authorising destructive containment, handling legal and regulatory notification, and tuning against your own environment. Buy the shift coverage. Keep the judgement.

Migration: what silently dies when you change platforms

Platform migrations are sold on cost and lost on detection content, and the loss is silent because the new platform looks complete. Four things disappear unless someone owns them.

Query logic that does not translate. Statistical commands, transaction grouping and macro libraries rarely have a one-to-one equivalent between query languages. Every ported rule needs testing against the same historical window on both platforms with the alert counts compared; a rule that returns zero on the new platform has usually lost its join, not its attackers.

Saved searches nobody documented. The rule inventory is a query against the platform configuration, not a spreadsheet. Export the full list - owner, schedule, throttle, destination - before decommissioning anything, because the dashboards that matter are attached to searches that appear nowhere else.

The audit history you are obliged to keep. Historical logs rarely migrate in full, and legal holds and regulatory retention live in the old platform. Keep the old system read-only for the full retention window, with documented access for named people, rather than assuming an export satisfies an obligation.

Institutional knowledge in the heads of two analysts. Parallel operation for at least a month, comparing alert output per detection, is the only reliable way to find the rules that were tuned by hand for years. Budget for it, and record the differences as findings rather than noise.

The lawful limit of what you may collect

A SIEM is a monitoring system, which means it processes personal data by design, and the implementation plan is where that should be decided rather than discovered. Three boundaries matter.

Metadata is easier to justify than content. Authentication events, DNS and proxy records, and control-plane audit trails answer the four questions with far less intrusion than mailbox bodies, screen capture, keystroke data or TLS interception. In most European jurisdictions the first category is defensible under a documented legitimate-interests assessment; the second needs a stronger case, a necessity test, and often a works-council agreement before a single event is collected.

Employment context adds consultation duties. GDPR Article 88 allows national law to impose more specific rules on monitoring in the employment relationship, and several member states do. In Germany the works council has a codetermination right over technical devices capable of monitoring behaviour, and comparable consultation duties exist in Austria and the Netherlands. Building first and consulting second is how a working system gets switched off by a committee.

Retention limits cut both ways. Data minimisation and storage limitation mean personal data may not be kept longer than necessary, while forensic and regulatory needs push the other way. Resolve it explicitly: aggregate and pseudonymise what you keep beyond the operational window, keep the evidential subset under a written justification, and record the decision with a date so the next auditor sees reasoning rather than a default.

Two operational habits follow. Use a processor agreement with a sub-processor list, a storage region that matches your obligations, and a clear answer to whether vendor support staff can read your data. And keep the SIEM from becoming a way to watch individuals: queries targeting a named person should require a case reference and an authorisation trail, or the tool will be used for something the organisation did not intend.

Acceptance criteria and the clauses that decide whether you can leave

An implementation is finished when it meets tests written before it started. Five are worth putting in the contract.

• Detection acceptance test. For each detection family delivered, a controlled test runs with the buyer present, and the alert must fire, enrich correctly and route to a named person.
• Source onboarding service level. A stated number of days from handing over a source to it being parsed, validated and health-checked - with the clock on the integrator, not on your engineering team.
• Content ownership and portability. Rules written for you are yours, delivered in a portable format where one exists, with no licence trap on export.
• Tuning commitment. A stated false-positive target per detection family and a review cadence, rather than ongoing optimisation as an aspiration.
• Exit. Full data export in a documented format within thirty days of termination, a deletion certificate, and no charge for either.

Those five clauses cost nothing to negotiate at the start and are close to unobtainable later. The exit clause in particular is the difference between a platform decision and a hostage situation.

What to measure monthly

Rule counts are not a metric; they measure effort, not outcome. Measure these instead, and publish them where the people who fund the programme can see them.

If those numbers are not moving, more rules will not move them. The failures they expose - a dead source, a field that stopped parsing, a rule nobody validated, a volume decision that costs more than the risk it covers - are the failures this guide started with, and every one of them is cheaper to fix in a monthly review than in the middle of an incident.

If you are in the middle of this and need the awkward parts done - the source inventory, the health-check build, the detection validation, the retention design against your actual regulatory clocks, or an independent review of a partner implementation - that is the kind of engagement our team takes on, always with written authorisation and inside your own legal boundaries.