Definition
What is a diagnostic SIEM?
A diagnostic SIEM is a SIEM whose unit of output is a diagnosis, not a search result: a named condition, the evidence chain supporting it, and a reading on which of your tools saw it, missed it, or saw nothing.
The term has a specific history and a specific meaning. This page gives both, and a set of tests you can run on any vendor that claims it — including us.
A diagnosis and a search result are different objects
A conventional SIEM's success condition is that it had the log. Its output is a record you can search and an alert you can triage, and the work of turning either into a conclusion belongs entirely to the analyst. That is not a flaw in the design — it is the design. The system is a very good filing cabinet with a very good index.
The comparison that makes the difference obvious comes from aircraft maintenance. Before he worked in security, WitFoo's co-founder spent six years fixing F/A-18s, where a fault meant walking to the aircraft and pressing a button: “I went into the forward wheel well of the F/A 18 and pushed a button that displayed a three digit code. I looked up that code and it pointed me to a flowchart.” The code named the condition. The flowchart said what to do about it.
Arriving in security operations in 2002, he went looking for the equivalent and found “no flowcharts or playbooks – just vague guidance.” Two decades later that is still mostly true, and it is the gap the word “diagnostic” is pointing at. A diagnostic system hands you a code and a procedure. A storage system hands you the evidence and a query language.
Three things a SIEM has to do to earn the word
All three, not two. The third is the one almost nothing does.
-
Assemble incidents, not list alerts
The output is one thing with a name and a boundary — this happened, to these assets, in this order — rather than a few hundred rows that happen to share a field. If a human still has to do the assembling, the system has handed over materials, not a finding.
-
Carry the evidence with the conclusion
A conclusion that arrives without its evidence is an opinion, and cannot be argued with. One that arrives with the records it rests on can be checked, disputed and overturned. That is not a nicety; it is the difference between a finding you can act on and one you have to take on faith.
-
Report on the health of its own instruments
This is the clause that makes a system diagnostic rather than merely investigative. A system that cannot say which sensor was silent cannot tell you whether a clean result means nothing happened or nothing was watching. Those are opposite conclusions from identical output.
Requirement two is the subject of deterministic versus probabilistic analytics, and requirement three is what WitFoo Reporter is built to produce. Neither is re-argued here.
Where the term comes from, and what it is not
The idea predates the label. In 2013 Charles Herring sorted security data platforms into three levels: those that limit input to understood fields and keep context, those that accept everything without understanding it, and those that process everything and discover its context. He was explicit that the third did not yet exist — the piece compares it to a starship computer and says that on the day of writing, nothing could do it.
That concession is the honest part of the history, and it is why this page is a definition rather than a claim of arrival. Building toward level three is what WitFoo has spent the years since doing.
The word “diagnostic” attached to the product later. It was used for WitFoo Precinct, which was renamed WitFoo Analytics — if an old product listing, a video or a partner document brought you here under that name, the history is here and the current product is WitFoo Analytics.
What the term never became is an industry category. No analyst firm defines it. No competitor uses it. It has never appeared in a market quadrant, and there is no vendor landscape behind it. We think it names a real distinction, which is why the definition is worth writing down — but it is our definition, offered as one, and you should treat a vendor who presents it as an established category with the suspicion that deserves.
Four things to ask on the demo call
A definition you cannot test is decoration. Run these against any vendor claiming the word, this one included, and judge by what the screen actually does rather than what the deck says.
- Show me one incident, start to finish.
- Not a dashboard, not an alert list. One named thing with a beginning and an end. Count how much assembly the analyst is still doing after the system has finished.
- Now show me the evidence underneath it.
- Every record that contributed, reachable from the conclusion. If the path from finding to source records runs through a query the analyst has to write, the system stopped short of a diagnosis.
- Which of my tools saw this, and which saw nothing?
- The question almost nothing answers. A system that cannot distinguish a quiet sensor from a quiet network cannot tell you what its own clean results mean.
- Run it twice and show me both answers.
- If the same inputs can produce different conclusions, you have a system that estimates rather than establishes. That may be fine — but you should know which you bought.
What this page does not claim
-
That “diagnostic SIEM” is a recognised category. It is not one, and a page arguing for evidence should not invent an industry consensus to lean on.
-
That WitFoo is the only product that could meet this definition. The tests above are deliberately vendor-neutral, and we would rather you ran them on us than took the label at face value.
-
That the definition is finished. The 2013 piece this descends from said the hardest level did not exist yet. Some of it still does not.
Questions people actually ask
What is a diagnostic SIEM?
A diagnostic SIEM is one whose unit of output is a diagnosis rather than a search result: a named condition, the evidence chain that supports it, and a reading on which of your own tools saw the condition and which saw nothing. The distinction is about what lands on the analyst’s desk. A conventional SIEM succeeds when it has the log and gives you somewhere to query it; a diagnostic system succeeds when it names what is wrong and shows its working, including the state of the instruments that produced the evidence.
Is “diagnostic SIEM” an industry category?
No, and we are not going to pretend otherwise. No analyst firm defines it, no competitor uses it, and it has never appeared in a market quadrant. It is a term WitFoo has used for its own products since around 2019, and it survives mainly in older product listings and partner documents. We think it names a real and useful distinction, which is why this page defines it properly — but it is our definition, offered as one, not a category anyone else recognises.
What happened to WitFoo Precinct?
WitFoo Precinct was renamed WitFoo Analytics. If a product listing, a video or a partner document brought you here under the old name, the rename and what carried across are covered on our Precinct page, and the current product is WitFoo Analytics.
How is a diagnostic SIEM different from XDR?
XDR describes where the telemetry comes from — endpoint, network, identity, cloud, correlated across those domains by one vendor. Diagnostic describes what the system produces once it has the telemetry. They are answers to different questions, and a product can be either, both or neither. An XDR that hands you a correlated alert list has not produced a diagnosis; a single-source tool that names a condition and shows its evidence has.
Is this the same as a SIEM with good dashboards?
No. A dashboard summarises what was collected; a diagnosis states what is wrong. The test is whether the analyst still has to assemble the conclusion after the dashboard has done its work. Most do — which is not a criticism of dashboards, only of treating them as the finished product.
Run the four tests on us.
WitFoo Analytics assembles incidents, carries the evidence with them, and reports on which of your tools contributed and which stayed silent.