SIEM Deployment Lessons from Two Very Different Organizations
Earlier in this series
I have run a SIEM in two settings that could hardly be less alike.
The first was a wholesale and retail company in Kuala Lumpur, where I was the ICT systems administrator. I deployed the SIEM myself, alongside the servers, the network, the EDR, the backups, and everything else — because I was the infrastructure team. The second was a major telecom in Tallinn, where I worked as a SOC analyst inside a mature operation: dedicated detection content, an engineering function to partner with, processes that had survived years of contact with reality.
Each environment taught me something the other could not. And each environment held confident, wrong beliefs about the other. This piece is about both.
The one-admin SIEM
Deploying a SIEM as a lone administrator strips the technology of its mystique fast. Three lessons from that job have stayed with me.
Log source selection is the whole game. The instinct is to ingest everything. I tried. What I got was cost, storage pressure, and a haystack. What I actually needed, for a company of that size, was a short list: authentication events from the domain, the perimeter firewall, the critical servers, and the endpoint agent. A handful of sources, chosen because they answered the questions I would actually ask during an incident. Every source beyond that added expense faster than it added answers.
An alert is only real if someone will act on it. I was the someone. All of them. That constraint was clarifying in a way no enterprise deployment ever is. A detection that fired daily with nothing actionable behind it was not a detection; it was a tax on the only responder. So my rule set stayed brutally small — a dozen alerts I would genuinely get out of bed for — and everything else became dashboards and reports I reviewed on a schedule instead of interrupts. The formal triage and prioritization procedures I built there existed precisely because attention was the scarcest resource in the building.
The SIEM's real value at that scale was investigative, not detective. Honestly, the searches mattered more than the alerts. When something broke or looked wrong, having months of logs in one queryable place turned "no idea" into "here is the timeline." If I could redo that deployment, I would market it internally as an investigation tool with some alarms attached, because that is what it was.
The telecom-scale SIEM
Inside a mature SOC, the SIEM stops being a product and becomes an ecosystem — and the lessons invert.
At scale, the SIEM is a pipeline, not a box. Ingest, parse, normalize, enrich, correlate, route. Whole categories of work existed that had never crossed my mind as a lone admin: parsing failures silently dropping a log source, schema changes upstream breaking correlation downstream, enrichment services the detections quietly depended on. The alert an analyst sees is the end of a long supply chain, and the supply chain needs its own monitoring.
Detection content is a living codebase. Rules were written, reviewed, tuned, documented, and retired — the discipline I described in SOC Analyst Diary: What Detection Engineering Really Looks Like. Nobody assumed the vendor's defaults fit; the assumption was permanent, staffed iteration. And process wrapped it all: alerts mapped to procedures, procedures refined after every incident, in the way I laid out in Incident Response Playbooks That Actually Get Used.
Specialization is what the money buys. The point of a mature SOC is not better software. It is that tuning, triage, engineering, and response are different jobs done by people who get good at them. The tooling was better, but the division of labor was the actual capability.
What the big SOC gets wrong about the small org
Sophisticated security organizations tend to imagine the small company as a scaled-down version of themselves: same architecture, fewer nodes. It is not, and advice built on that assumption fails.
Telling a company with one IT generalist to "establish a detection engineering function" is telling them to do nothing. The 24/7 assumption fails — nobody is watching that console at night, so a real-time alert at 2am is a morning email. The staffing assumption fails — the person reading the alert is also the person patching the server it fired on. Enterprise reference architectures pushed downmarket produce shelfware: a SIEM installed, ingesting, unread. I have met that deployment in consulting engagements more than once. It reassures management and defends no one.
The small org does not need a smaller version of the big SOC. It needs a different design: fewer sources, fewer alerts, investigation-first, sized to one part-time human.
What the small org gets wrong about the big SOC
The error runs the other way too, and I held a version of it myself before Tallinn.
From the outside, a mature SOC looks like a purchase — as if the capability lives in the license, and the enterprise simply bought a bigger one. So the small org buys the same product, expecting the outcome, and gets the empty console instead. What is invisible from outside is that the product is maybe a fifth of the capability. The rest is the pipeline maintenance, the content lifecycle, the playbooks, the specialization — running costs, in skilled hours, forever.
The other misreading: "we're too small for any of that to apply." The scale does not transfer, but the disciplines do. Know which log sources you trust and check that they still flow. Treat every noisy alert as a defect to fix, not weather to endure. Write down what you will do when a real alert fires. Those transfer to a team of one. I know because I ran the team of one, and the parts of my deployment that worked were exactly the parts that resembled, in miniature, what the telecom did deliberately.
If you are about to deploy one
My compressed advice, either context: start from the incidents you plausibly face and work backwards to the log sources that would let you see them — not forwards from what can be ingested. Budget ongoing human hours honestly before licenses; an unwatched SIEM is expensive storage. Begin with five alerts you will always act on rather than fifty you will learn to ignore. And measure the deployment by one question only: when something strange happens, does this system help you find out what it was, faster?
Everything else — including where you get the threat information that tells you what to look for in the first place — builds on that. The threat-information question deserves its own piece, and it is next.