- A security information and event management (SIEM) platform is a detection and investigation capability, not a product you install. Most failed deployments failed at planning, not at procurement.
- Start from detection questions you want answered, not from the list of log sources you could connect. Coverage is measured in answered questions, not gigabytes ingested.
- Onboard identity, endpoint and cloud control-plane logs first. They carry the evidence for the earliest stages of most intrusions.
- Every log source needs validation. Until you have generated an event and watched it arrive, the source is an assumption rather than a control.
- Budget for the ongoing engineering effort, not just the licence. Detection content decays as your estate changes, and untuned alerts are the main cause of analyst burnout.
- Write down what each alert means and what an analyst should do about it. An alert without a documented response is a notification, not a detection.
Most organisations buy a SIEM before they have decided what they want it to tell them. The result is predictable: months of ingestion work, a large bill, a wall of alerts nobody trusts, and a team that quietly stops looking at it. This guide covers how to plan a deployment that avoids that outcome, and what to do if you have already arrived there.
What a SIEM actually does
A security information and event management platform collects log and event data from across an estate, normalises it into a common structure, retains it, and runs detection logic over it. Two capabilities matter more than the marketing categories layered on top.
The first is correlation. Individually unremarkable events become meaningful when linked: a sign-in from an unusual location, followed by a mailbox rule creation, followed by a bulk download. Any one of those is noise. In sequence, they are a story. A SIEM exists to make that sequence visible across sources that would otherwise never be compared.
The second is retention with searchability. When you are investigating an incident, the question is almost always historical: when did this first happen, what else did that account touch, was this the only host. Logs sitting in their originating systems, with different retention periods and no common query interface, cannot answer that under time pressure.
Everything else, including the user and entity behaviour analytics and orchestration features that vendors bundle in, is an extension of those two functions. Judge a deployment on whether it does those two things reliably before judging it on anything else.
Plan the detections before the ingestion
The single most common planning error is treating log onboarding as the project and detection as something that happens afterwards. It inverts the dependency. You cannot know which logs you need until you know what you are trying to detect, and connecting sources speculatively produces cost without coverage.
Work the other way. Write down a specific threat you care about, phrased as a question an analyst could answer: would we see an attacker creating a new privileged account in our identity provider? Would we see credentials being used from an address that has never been seen for that user? Would we see someone disabling endpoint protection on a server? Each question points at a small number of specific log sources, and each one gives you a concrete test of whether the deployment is working.
The MITRE ATT&CK knowledge base is a reasonable structure for generating those questions, because it enumerates techniques alongside the data sources that reveal them. Treat it as a prompt rather than a target. Attempting complete ATT&CK coverage is a well-known way to produce a very large backlog and very little working detection.
Which logs to onboard, and in what order
Once you have a handful of questions, the log sources they require will cluster in a predictable way. Identity, endpoint and cloud control-plane logs answer a disproportionate share of them, because those are where the earliest observable stages of most intrusions land.
Two things are worth saying about the third tier. It is not less important, it is less universal: network flow records and CI/CD audit logs are essential in some environments and largely decorative in others. And it is where ingestion cost tends to concentrate, so it is the tier where a specific justification matters most.
NIST’s guidance on log management remains a useful planning reference, though it needs a caveat. SP 800-92, published in 2006, is still the current final version. Revision 1 reframes the material as a planning playbook and is more useful for this purpose, but it remains an initial public draft, so cite it as guidance rather than as a settled standard.
Normalisation, timestamps and the boring failures
The failures that damage a deployment are rarely exotic. They are field mapping and time.
Normalisation is the process of mapping each source’s fields into a common schema so that a query for a username or a source address works the same way regardless of which system produced the event. Get this wrong and correlation silently degrades: rules match on some sources and not others, and nobody notices because there is no error, only an absence.
Timestamps deserve specific attention. Sources report time in different zones, some in local time, some in UTC, some with the collector’s receipt time rather than the event time. A correlation rule that depends on ordering will produce wrong answers if two sources disagree about when things happened, and an incident timeline built on mixed time bases is worse than no timeline. Confirm the time base of every source at onboarding and record it.
Generate the activity deliberately, in a controlled way, and confirm the event arrives with the fields you expect. Until you have done that, the log source is an assumption. Silent ingestion failures, a changed API, a rotated credential, a modified agent configuration, are common and produce no alert by definition, so schedule periodic re-validation rather than treating it as a one-time step.
Tuning, and the cost of not doing it
A new detection rule will produce false positives. That is expected and not a defect. What matters is whether there is a defined process for reducing them, because the alternative has a predictable trajectory: analysts learn that a given alert is usually nothing, begin closing it without investigation, and eventually the one occurrence that mattered is closed the same way. This is not a training problem. It is a design problem, and it is solved by tuning rather than by exhortation.
Practical tuning discipline means recording, for each rule, what legitimate activity is known to trigger it, and encoding those exclusions explicitly rather than by loosening the rule. It also means tracking the rate at which each rule fires and reviewing the outliers, since a rule that fires constantly and a rule that has never fired both warrant a look, for opposite reasons.
Alongside the rule itself, write down what the alert means, what an analyst should check first, and what would make it fire wrongly. An alert without a documented response is a notification. That documentation is also what makes the capability survive staff turnover, which is the usual point at which undocumented detection content becomes unmaintainable.
Budgeting honestly
Licensing models vary, most commonly by data volume or by event rate, and the pricing question that matters is not the headline figure but how the cost behaves when your estate grows or a source becomes chattier. Ask specifically what happens when volume exceeds the committed tier, and model the cost of the tier-three sources you might add later rather than only the ones you are onboarding now.
The larger and more frequently underestimated cost is engineering effort. Detection content decays: cloud services change their log formats, applications are replaced, an identity provider migration changes every field name you depended on. A deployment that receives no ongoing attention degrades quietly over a year or two into an expensive log archive. Budget for someone to own it as continuing work, not as a project with an end date.
This is also the honest case for a managed service. If you cannot fund sustained detection engineering, a co-managed arrangement will usually produce better outcomes than an unmaintained in-house platform. The trade is real, in visibility and in the specificity of detections tuned to your environment, so make it deliberately rather than by neglect.
- Write down five detection questions in plain language, phrased as things an analyst should be able to answer. Circulate them and see whether colleagues agree they are the right five.
- For each question, identify the minimum log source that would answer it. Note which of those you already collect.
- Validate three existing log sources by generating a known event and confirming it arrives with the expected fields. Record the time base for each.
- Pull the firing rate for every active rule over the last 90 days. Review anything that fires constantly and anything that has never fired.
- Pick your noisiest rule and document its known-benign triggers, then encode those as explicit exclusions.
- For your top ten alerts, confirm each has a written response note covering what it means and what to check first. Write the missing ones.
- Model your ingestion cost at 150 percent of current volume and confirm what happens contractually at that point.
Last verified: 20 August 2026. NIST SP 800-92 Revision 1 remains an initial public draft; check its status before relying on it in a compliance context.