I once worked on two SIEM onboarding projects at the same time for two companies that were almost identical — same industry, same region, and nearly identical IT and security stacks. You'd expect their SIEM implementations to look alike. But they didn't.
One prioritized network monitoring. The other focused on endpoints and Active Directory. The difference? At Company A, the lead came from a networking background. At Company B, the project was driven by someone who came up through systems administration.
This is a good example of how personal experience can shape technical decisions, often without us realising it. To get around that, you need a structured way to define what matters for your security monitoring program.
Finding the Security Value in Your Data
Security monitoring at scale relies on SIEM tools. At their core, SIEMs take in data and produce security value through alerts, dashboards, reports, and by supporting activities like threat hunting and incident investigation. In simple terms: data goes in, security value comes out.
If the data doesn't support detection, reporting, investigation, or hunting — it probably doesn't belong there. So how do you decide what to send? Ask yourself: What do I want to alert on? What should I report on? What dashboards do I need? What's my plan for threat hunting?
You can bring your teams together for a working session, but personal experience and bias always play a role. A more data-driven approach is to use threat intelligence as the primary input for deciding what security value you want from your SIEM — and in turn, what data to send into it.
Threat Intelligence as Input for Security Monitoring Decisions
A good starting point for deciding what detection capabilities an organisation needs is understanding which threat actors are most likely to target it. This involves gathering intel on the tactics, techniques, and procedures (TTPs) of relevant threat actors based on factors like industry, geography, infrastructure, and internal context such as ongoing projects, past incidents, and known unmitigated risks.
Once relevant TTPs are identified, the next step is to look for patterns. Techniques that appear repeatedly across multiple threat actors should be prioritised. The outcome is a focused list of the most-used techniques likely to be deployed against your organisation — and that list becomes the foundation for your detection strategy.
Practical tool: The MITRE ATT&CK Navigator heatmap is highly effective here. Overlaying multiple threat actor profiles on the ATT&CK matrix visually surfaces the techniques with the highest frequency across adversaries targeting your sector.
Turning Intelligence into Detections
Once the top techniques are identified, the next step is designing detection methods within your environment. From there, you define the necessary SIEM use cases — detections, dashboards, reports, and monitoring capabilities. MITRE's list of data sources (attack.mitre.org/datasources/) is a useful reference at this stage.
This process gives you a clear understanding of which logs are needed to support your desired use cases — and allows you to plan the onboarding of those data sources into your SIEM in a purposeful, prioritised way rather than ingesting everything and hoping for the best.
Making It a Recurring Exercise
The threat landscape is constantly evolving, and detection capabilities must evolve with it. As a starting point, refreshing SIEM content every three months is a practical cadence. Over time, the goal should be to shorten that cycle to once a month — resulting in 12 focused content updates per year.