Top 10 SIEM Deployment Mistakes: What Goes Wrong and How to Fix It

Most SIEM deployments do not fail on the day the platform goes live; they fail quietly over the following year, as ingestion bills climb, log sources stop reporting without anyone noticing, and analysts learn to ignore alerts that never get tuned. This page ranks the ten SIEM deployment mistakes we see most often, each with what goes wrong, how to detect it in your own deployment and the fix. Most of the failure modes are also named in the 2025 joint government guidance on implementing SIEM and SOAR platforms published by the Australian Signals Directorate's ACSC with CISA and international partners, which we cite throughout. It is for SOC leads, detection engineers and security architects running or rescuing a SIEM, and for leaders deciding whether the problem is the product or the programme. For product selection read the SIEM Buyer's Guide; for moving platforms, the SIEM Migration Guide.

The Top 10 at a glance

1. Deploying without an owner, scope or use cases
2. Ingesting everything and letting cost decide coverage
3. Missing the log sources that matter most
4. Not noticing when a log source goes silent
5. Skipping parsing, normalisation and time synchronisation
6. Assuming the baseline is clean
7. Set-and-forget detection rules
8. Never testing detections end to end
9. Retention shorter than your time to detect
10. Under-staffing the platform, and buying SOAR too early

1. Deploying without an owner, scope or use cases

A SIEM bought to "get visibility" with no defined outcomes becomes an expensive log store. The ACSC and CISA practitioner guidance recommends naming an accountable system owner who maintains the platform, governs changes and answers scoping questions: objectives, stakeholders, in-scope risks and use cases, priority data sources, integration dependencies such as SSO and APIs, on premises versus SaaS, staff availability and existing incident response processes. It also recommends a proof of concept with feedback from analysts and engineers before committing to a platform.

Detect it: ask who approves a new log source or a rule change. If nobody can answer, or the answer is "the vendor", you have this problem. Count rules that map to a documented threat or requirement; anything below about half suggests rules were switched on by default.

Fix: write a use case register (threat, data sources needed, rule, response owner) and tie every log source and rule to at least one entry. Put the system owner on the change advisory board so new systems arrive with logging agreed, not discovered later. See the Detection Engineering Guide for running use cases as code.

2. Ingesting everything and letting cost decide coverage

Most SIEM pricing depends on log volume, and the guidance warns that uncapped licences can produce large bills if ingestion is not managed, and that vendor default settings often increase ingestion. The usual reaction is to switch off whole sources mid-year, which removes coverage at random rather than by risk. The guidance also lists hidden costs: lock-in, integration with multi-vendor estates, switching, training, outsourcing and query charges, and data residency.

Detect it: rank sources by daily volume and by number of rules and investigations that use them. High volume with no rule or search use is waste; a source dropped for cost that feeds a use case is a gap.

Fix: pre-process before ingestion, at the source, the forwarder or the ingestion point, and parse only the fields needed for security analysis. Send logs needed only for compliance or occasional investigation to cheaper storage such as a data lake and query them when needed. The guidance prefers a repository-first (data lake) architecture where the SIEM queries a log repository, and gives a common example: large PowerShell logs diverted to a data lake at the replication point. Its starting sizing table suggests, for example, a minimum of 250 GB and an ideal of 600 GB for organisations with 400 to 2,000 staff; treat these as planning figures, not targets.

3. Missing the log sources that matter most

Teams often ingest what is easy (firewall allow logs, verbose application logs) and miss what answers incident questions. The companion "Priority logs for SIEM ingestion" guidance lists, loosely in priority order: EDR, network devices, domain controllers, Active Directory security logs, Windows endpoints, virtualisation, OT, cloud platforms, containers, databases and MDM.

Detect it: build a coverage matrix of assets against required sources; the guidance's own example is 10 of 12 domain controllers ingested, leaving two blind spots. The Log Source Coverage Matrix Template gives a format.

Fix: close gaps in priority order, and accept partial coverage (for example a percentage of desktops) only through a documented risk assessment, as the guidance recommends. Non-human identity activity deserves explicit attention: service principal sign-ins, secrets manager reads such as AWS GetSecretValue and API key use are where many recent intrusions hide. See the Entra ID Sign-In and Audit Log Detection Guide.

4. Not noticing when a log source goes silent

Agents crash, API tokens expire, a firewall change blocks a forwarder, a cloud diagnostic setting is removed. Nothing alerts, and searches against the missing source return no results, which the guidance warns can look like a clean environment when the platform is actually blind. Attackers also disable or clear logging on purpose (MITRE ATT&CK T1685.001 Disable or Modify Windows Event Log, T1685.005 Clear Windows Event Logs).

Detect it: list every source with its expected volume and last event time. Any source with no expected-volume baseline is unmonitored.

Fix: heartbeat rules per source and per critical host (no events in [N] minutes, or volume below [x]% of the rolling baseline), an alert on event 1102 and on changes to cloud audit configuration, and a weekly feed health review. Protect the credentials the SIEM uses to pull cloud and SaaS logs: they are machine identities with broad read access and often expire silently. See the Log Management and Retention Guide.

5. Skipping parsing, normalisation and time synchronisation

A rule written against src_ip will not fire on a source that calls the same field sourceAddress. The guidance calls for correct parsing of structured and unstructured logs, standard field names across sources, and synchronised time across logs collected in different time zones. It also notes that Sigma rules can express detections in a vendor-neutral format that each SIEM query language implements.

Detect it: sample each source for unparsed events, fields stored as raw text, and timestamp skew between ingestion time and event time.

Fix: adopt one schema, store timestamps in UTC with the source time zone recorded, enforce NTP on sources (NIST SP 800-53 AU-8 Time Stamps), and add parser tests to your detection pipeline so a vendor log format change fails a test instead of silently breaking rules. See the Sigma Rules Guide.

6. Assuming the baseline is clean

Anomaly detection and allow-listing depend on knowing normal activity. The guidance says baselining tools, software, account behaviour, network traffic and system communications takes at least several weeks, and warns that a compromised system can make malicious activity look like the baseline. Learning "normal" during an undetected intrusion teaches the SIEM to ignore it.

Detect it: check whether exclusions and allow-lists were reviewed by a person or simply generated from the first month of data.

Fix: validate the baseline with targeted threat hunts before relying on it, keep it under review as assets change, and record who approved each exclusion and why.

7. Set-and-forget detection rules

The guidance names "set and forget" as a pitfall: over-collection and broad rules cause false positives and alert fatigue, which leads to missed incidents, while under-sensitive rules and incomplete data cause false negatives. It recommends continuous tuning, a standard alert naming convention linked to MITRE ATT&CK to speed triage, retiring obsolete rules and using community or vendor rules to speed deployment.

Detect it: for each rule, measure alert volume, true positive rate and median time to close. Rules closed as benign more than [90]% of the time, or closed in seconds, are being ignored.

Fix: give every rule an owner, a review date and a tuning log; tune by narrowing conditions, not by blanket suppression; retire rules that no longer map to a threat. The Alert Fatigue Reduction Guide covers the triage side.

8. Never testing detections end to end

A rule that has never fired on a real or emulated attack is an assumption. The guidance recommends regular, repeated exercises against well-known techniques, and names test areas including Active Directory and PowerShell modification, LSASS dumps, Golden Ticket (T1558.001), living off the land, DCSync (T1003.006), command and control, and internal reconnaissance. It asks for the whole pipeline to be tested: log production, ingestion, true positive and true negative results, and any SOAR action.

Detect it: count rules with a recorded successful test in the last [6 months].

Fix: schedule adversary emulation in a controlled, authorised test window, record each result against the use case register, and re-test after parser, agent or platform upgrades. See the Detection Engineering Maturity Model.

9. Retention shorter than your time to detect

If intrusions are found months after they start, 30 days of searchable logs means the start of the story is gone. The guidance says retention must cover the organisation's mean time to detect and allow enough time for investigations, and suggests, as a starting point for new programmes, a minimum of one year for administrative and security events and 90 days for informational logs that add context. Regulation may require longer.

Detect it: compare retention per source with dwell times from your own incidents and any regulatory minimum.

Fix: tier retention: hot searchable storage for recent data, cheaper storage for the rest, with a tested restore path. Define how logs are aged off and deleted, and protect them from change (AU-9, AU-11).

10. Under-staffing the platform, and buying SOAR too early

The guidance says SIEM operation needs dedicated specialist staff, possibly several full-time people in house, with initial and ongoing training in logging, querying, investigations, ATT&CK, alerting and feed health, and support for a stressful role. It cautions that outsourcing can create visibility gaps and recommends in-house capability for organisations handling sensitive data or critical services. On SOAR, it says SOAR is usually unsuitable for immature environments and an effective SIEM is the higher priority, and that misconfigured automation can treat normal behaviour as an incident and disrupt services.

Detect it: look for alert backlogs, rules waiting months for an engineer, and SOAR playbooks that are disabled or run only in notify mode because nobody trusts them.

Fix: fund engineering time alongside the licence; automate enrichment first and containment actions (quarantine, credential revocation) only after the underlying detections have proven precise. If you use an MSSP or MDR, contract for access to raw data and rule content. See the SIEM RFP Template for staffing and service requirements.

Measuring whether the deployment is healthy

Mapping to OWASP

For applications you build, the OWASP Application Security Verification Standard 5.0 chapter V16 Security Logging and Error Handling (security logging documentation, general logging, security events, log protection) sets what applications should emit so the SIEM has something to detect on; see the Secure Logging Vocabulary and Application Security Events Guide. Wider framework mapping:

Where to start

1. Name the system owner and build the use case register (mistake 1); everything else hangs off it.
2. Run the coverage matrix and heartbeat rules this month (mistakes 3 and 4): blind spots matter more than noisy rules.
3. Do a volume and value review before the next licence renewal (mistake 2).
4. Pick the ten highest-risk techniques and test their detections end to end (mistake 8).
5. Then start the tuning lifecycle and set retention against your dwell time (mistakes 7 and 9).

Practitioner checklist

• A named system owner sits on change control and approves new sources and rules.
• Every log source and rule maps to an entry in the use case register.
• Coverage of domain controllers, identity providers, EDR and cloud audit logs is measured per asset.
• Every source has a heartbeat rule, and log clearing (event 1102) and cloud audit configuration changes alert.
• Fields are normalised to one schema with UTC timestamps, and parser tests run on change.
• Exclusions and baselines are reviewed by a person and validated with hunts.
• Each rule has an owner, review date, true positive rate and tuning log.
• Detections are tested end to end on a schedule and after upgrades.
• Searchable retention covers at least one year of security events or your worst dwell time, whichever is longer.
• SIEM collector credentials and service accounts are inventoried, least-privileged and monitored.

Standards and references

• ASD's ACSC: Implementing SIEM and SOAR Platforms, Practitioner Guidance
• ASD's ACSC: Priority Logs for SIEM Ingestion, Practitioner Guidance
• CISA: Guidance for SIEM and SOAR Implementation
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0
• OWASP: Application Security Verification Standard 5.0
• MITRE ATT&CK: Clear Windows Event Logs
• MITRE ATT&CK: OS Credential Dumping: DCSync

Related NHI Mgmt Group resources: SIEM Guide · SIEM Buyer's Guide · SIEM Migration Guide · Detection Engineering Guide · SOC Maturity Model