Over 13 years across SOC, audit and GRC, I’ve seen the same pattern many times. An organisation buys a top-tier SIEM, onboards every log it can find, and 18 months later has a large licence bill, thousands of untuned alerts, and very few real detections.
The platform is rarely the problem. The design is. These are the decisions that matter most.
1. Start with use cases, not data
Define what you need to detect before you decide what to collect. Map each use case to MITRE ATT&CK techniques and to your enterprise risk register. Every log source you onboard should support at least one detection, investigation or compliance requirement. If it doesn’t, ask why you’re paying to ingest it.
2. Prioritise log sources by detection value
Not all telemetry is equal. Identity (AD, Entra ID, IAM), EDR, DNS, proxy and firewall, and the cloud control plane usually give the highest coverage per GB. CIS Control 8 and NIST SP 800-92 are good baselines for what to log and how to manage it.
3. Normalise once, at ingestion
Choose one data model, such as Splunk CIM, Elastic ECS or Microsoft ASIM, and enforce it. Without normalisation, every detection has to be rewritten for every source, and correlation across sources quietly fails.
4. Size the architecture for year three
Capacity planning covers EPS, daily ingestion volume, hot, warm and cold storage tiers, high availability, and forwarder and collector placement. Design for growth and for business continuity. A SIEM that goes down during an incident is a blind spot exactly when you need visibility most.
5. Treat detection as code
Rules should be version-controlled, peer-reviewed, tested against known-bad data, and tuned on a schedule. Measure false-positive rate per rule alongside MTTD and MTTR. A rule nobody trusts is a rule nobody investigates.
6. Build compliance in, don’t bolt it on
Retention, integrity and review requirements belong in the design phase:
PCI DSS v4.0 Requirement 10: at least 12 months of audit log history, with the most recent 3 months immediately available.
ISO/IEC 27001:2022 Annex A 8.15 (Logging) and 8.16 (Monitoring activities).
CBUAE ISR and NIST CSF 2.0 (DE.CM) for continuous monitoring expectations.
Designing for these from the start avoids costly re-architecture after the first audit finding.
7. Define the operating model
Tooling without process is shelfware. Before go-live, define who triages, the escalation paths, the SOAR playbooks, and how detections feed back into risk reporting. The SIEM is a SOC capability, not an IT project.
Bottom line: a SIEM’s value is measured by what it detects and how fast you respond, not by how many terabytes it holds.
What design decision made the biggest difference in your SIEM deployment?
References
NIST SP 800-92, Guide to Computer Security Log Management
NIST SP 800-137, Information Security Continuous Monitoring
NIST Cybersecurity Framework 2.0, Detect function (DE.CM)
CIS Critical Security Controls v8, Control 8: Audit Log Management
PCI DSS v4.0, Requirement 10
ISO/IEC 27001:2022, Annex A 8.15 and 8.16
MITRE ATT&CK Framework, attack.mitre.org
