Jatin Mannepalli, CISSP, CCSP, challenges the common “collect everything” SIEM mindset, arguing that effective security monitoring starts with business risks and detection goals, not log volume. Drawing on his practical experience, he outlines his own approach to SIEM implementation that prioritises threat modelling, data governance, detection engineering and continuous improvement.
Disclaimer: The views and opinions expressed in this article belong solely to the author and do not necessarily reflect those of ISC2.
I’ll be candid: security information and event management (SIEM) can fail even when the technology is working exactly as designed. That became clear to me when I stopped treating SIEM as a compliance checkbox and started asking whether it was really helping us detect and investigate risk. It’s easy to collect everything, hope the platform finds threats – and to end up with analysts buried in noise. My approach changed when I began with the threats that mattered most, the evidence needed to investigate them, and the decisions my team had to make quickly.
External identity-abuse research helps me pressure-test our own assumptions. Rather than treating those examples as stories to retell, I use them to ask a practical question: would our logs, MFA events, VPN activity and endpoint telemetry let me reconstruct a similar incident in our environment?
At the same time, the environments I have worked with keep producing more telemetry from cloud services, SaaS tools, remote access, identity platforms, endpoints and network controls. Without a plan, that volume becomes a storage and cost problem. With a plan, it becomes the foundation for stronger detection, faster investigation and better response.
The rollout model that has worked best for me is a roughly 13 week path that keeps the focus on detection value instead of raw ingestion volume. Here’s how it works for me.
Week 1-2: Strategy, Data Management and Threat Modeling
My first step is to achieve clarity. Before deciding what to ingest, I define the threats that matter most to the business and map each one to the data needed to detect, investigate and explain it. I try to avoid loading logs simply “because they’re available”.
I also align the SIEM strategy with compliance requirements early. PCI DSS, HIPAA, GDPR and similar obligations can affect which logs we collect, for how long we retain them and who can access them. Considering and accounting for those requirements at the beginning reduces the risk of expensive rework later.
A particular design choice that has worked well for me is the separation of detection data from long-term investigation data. The SIEM handles high-value security events that need alerting and operational attention, while a lower-cost data lake stores full-fidelity telemetry – for hunting, deeper investigations and compliance retention.
Week 3-4: Architecture and Governance
Once my detection goals are clear, my focus shifts to structure. This is where I define schemas, access controls, retention policies, documentation standards and ownership for each data source.
Experience has taught me that investigations slow down if and when we cannot explain from where data came, how it was transformed, or whether a field can be trusted. My goal is for an analyst to understand the source, meaning and limitations of the data, without having to reverse-engineer the pipeline during an incident.
The pricing model of my SIEM also needs my attention, before ingestion scales. Some tools charge based on ingestion volume, queries, or data scanned. I choose to understand those cost drivers before we make those architectural choices that look harmless during testing, but become expensive during real investigations.
Week 5-8: Build The Data Pipeline and Onboard Priority Sources
With the architecture in place, I build the pipeline and onboard the highest-value sources first: identity provider logs, endpoint detection alerts, cloud control plane activity, firewall events and the telemetry most closely tied to our threat model.
Multiplexing the data flow is something I’ve found especially useful: detection-relevant events go to the SIEM while full datasets are forwarded to the data lake. This gives us fast alerting where it matters and broader visibility when we need to hunt or reconstruct activity later.
Data culling is another deliberate choice. I’ve determined that removing those fields which add little investigative value can reduce ingestion costs by 30% or more, without weakening detection. The key is that I make those decisions consciously, document them and revisit them when the threat model changes.
Week 9-12: Detection Engineering and Validation
Once data is flowing, my work shifts from plumbing to detection engineering. I learned – the hard way – not to enable hundreds of vendor-supplied rules at once: that approach creates alert fatigue, frustrates analysts and makes the SIEM feel untrustworthy. Now, I build detections around our threat model and baseline normal behavior across users, systems and network traffic, before writing or enabling rules.
For each detection, I define the behavior it’s meant to identify, the data sources on which it depends, the expected response and the owner responsible for tuning it; every alert should have a purpose and a path to action.
Validation is as important as rule writing. During one purple team exercise, a simulated lateral movement scenario exposed a parsing issue: firewall logs were silently dropping the source port field. That gap would have stayed hidden until a real incident, if we hadn’t tested the detection end to end.
Week 13 and Beyond: Operations and Continuous Improvement
After go-live, I treat the SIEM as a living system; our work doesn’t stop when logs are onboarded and rules are enabled. We tune noisy alerts, refine detection logic, improve workflows and update priorities as our environment and threat landscape change.
Pairing SIEM with SOAR has also been valuable. When we automate enrichment, orchestrate response playbooks and give analysts the context they need inside the alert workflow, the SIEM becomes more than a detection console. It becomes part of the response engine.
Our analysts need clear triage guidance, escalation paths and evidence requirements. I also track metrics such as mean time to detect, mean time to respond and false positive rates so we can measure whether the program is, actually, improving.
What Have I Learned?
The main lesson I have taken from SIEM work is, like this conclusion, simple: collecting everything is not the same as seeing clearly. I achieve better results when I treat the SIEM as a detection and data engineering program: grounded in our risks, shaped by our environment and improved continuously through testing, tuning and analyst feedback.
Jatin Mannepalli, CISSP, CCSP, has over 10 years of experience in cybersecurity and risk management across IT, finance, management consulting and high-frequency trading. He has held security engineering, architecture, management and consulting roles, with responsibility for designing secure systems, mitigating risks and aligning cybersecurity strategies with business goals.
