Every SIEM contains a log manager. No log manager contains a SIEM. That asymmetry is the whole distinction, and missing it is how organisations end up with terabytes of perfectly retained evidence about a breach nobody noticed.
The two get used interchangeably partly because vendors sell both, often from the same platform, and partly because "we collect the logs" sounds close enough to "we would know" that nobody pushes on it. They are not the same claim.
What log management actually does
Log management is a data problem, solved well. It collects events from across the estate, normalises them into something consistent, indexes them so they can be searched, and retains them for as long as policy or regulation requires.
That is genuinely valuable, and not only to the security team:
- Operations use it to find out why something broke at 03:00, which is usually a faster question to answer from logs than from anywhere else.
- Compliance uses it because almost every framework has something to say about retention — ISO 27001, PCI DSS, SOC 2 and the rest all expect logs to exist, to be protected, and to be kept.
- Investigators use it after the fact. When you need to answer "how far did they get and what did they take", the logs are the answer or there is no answer.
What log management does not do is form an opinion. It will faithfully store the record of an attack, and it will wait to be asked.
What a SIEM adds on top
A SIEM starts from the same pile of data and adds the layer that decides something is worth a human's attention. In practice that means four things log management does not do:
Correlation across sources
A failed login is noise. A failed login, followed by a successful one from a different country, followed by a new inbox rule forwarding mail externally, is a story — and no single log source contains it. Correlation is the ability to hold those three events together and recognise the shape.
Detection logic that runs continuously
Log management answers questions you think to ask. A SIEM runs the questions constantly, whether or not anyone is thinking about them, and raises its hand when one of them is answered badly.
Context and enrichment
The raw event says an IP address connected. The useful version says it belongs to infrastructure associated with a known threat group, the account is a domain admin, and the device has not been patched in four months. Enrichment is what turns a line in a file into something a person can decide about.
Case management
An alert is not an investigation. A SIEM gives you somewhere to hold an incident, record what was found, show what was done and when, and close it with a verdict. Without that, "we investigated it" is a claim nobody can evidence — including to a regulator.
Why the line has genuinely blurred
It is worth being honest that the distinction is less clean than it was.
Modern log platforms have added alerting, and some do it well. Modern SIEMs are built on log platforms, so the boundary is inside one product rather than between two. Cloud-native tools have blurred it further by charging for ingest and analysis separately, which means you can buy the storage half of a SIEM and simply not turn on the other half — and many organisations have done exactly that without realising it.
So the useful question is not "which product is this" but "what is watching this data, and what happens when it finds something". That question has a clear answer in every case, and the product name often does not.
The compliance trap
This is where the distinction stops being academic.
Most frameworks require two separate things: that logs are retained, and that they are reviewed. Log management satisfies the first comfortably. It does nothing at all for the second.
An auditor asking "do you collect logs" is a question a log manager answers. An auditor asking "show me an event you detected, what you decided, and when" is a question it cannot answer, and the gap between the two is where a lot of organisations discover their compliance position is thinner than their evidence locker suggested.
Which do you actually need?
An honest framework, in the order the questions matter:
- If you need retention, search and forensic recall — and the security monitoring genuinely happens elsewhere — log management is sufficient and cheaper. This is a real answer and not a lesser one.
- If you need to know that something is happening while it is happening, you need detection, which means a SIEM or the equivalent capability inside an XDR platform.
- If you are regulated, read what the framework actually says. "Retain" and "review" are different words and they are usually both in there.
- If you already have a SIEM and it only really stores things, you have a log manager with a larger invoice. That is the most common version of this problem and it is worth checking before buying anything else.
The part that decides whether either one works
Neither tool detects anything. Both of them surface things, and a person or a process decides what to do about what was surfaced.
The failure we see most often is not a bad product choice. It is a good SIEM, correctly deployed, generating more alerts than the team who own it can triage — at which point the detection layer is theoretically present and practically absent. The logs are being kept, the rules are firing, and the queue is three hundred deep on a Monday morning.
A SIEM with nobody on the other end of it is log management that costs more. That is not an argument against buying one; it is an argument for deciding who works the queue before you decide which product fills it.
Where we stand
We run Managed SIEM and Managed Microsoft Sentinel, and the honest version of what that buys is the second half of this article rather than the first. The platform collects and correlates; the reason to have someone run it is that the alerts get worked at four in the morning on a Sunday by a named analyst rather than accumulating until somebody has time.
If you are trying to work out which of the two you need, the conversation worth having is not about products. It is about what you are collecting, what you would want to know within the hour, and who is on shift when it fires.