A SIEM, short for security information and event management, collects security data from many systems into one place so analysts can search it, correlate events and raise alerts. In a security operations center it is the shared window onto what happened. It is only as good as the logs it receives and the people who tune it.
How does NIST define it?
NIST's glossary, quoting SP 800-128, describes a SIEM tool as an application that provides the ability to gather security data from information system components and present that data as actionable information through a single interface. Two ideas sit in that sentence. Gathering means the work of collecting and normalizing logs from different formats. Actionable means the output has to help someone decide what to do.
What are the main jobs?
Collect. Logs arrive from servers, identity providers, firewalls, cloud accounts, applications and endpoint tools. Each source has its own format, so the system parses them into common fields.
Retain and search. Analysts can look back across months of data, which is how you scope an incident: who else signed in from that address, what else did that account touch.
Correlate. A rule can link events from different sources, such as a password failure burst followed by a success, then an unusual mailbox change.
Alert. Rules and models produce alerts for a human to triage.
Report. Evidence for auditors and management: log retention, access reviews, incident timelines.
How does it fit into incident response?
NIST SP 800-61 Revision 3 places incident response inside broader cybersecurity risk management, covering preparation, detection, response and recovery. The SIEM mainly serves detection and the investigation that follows. It supports response by giving analysts the evidence to decide on containment, but it does not contain anything itself unless connected to other tools.
Constructed example: the tracing question
An analyst receives an alert that a finance account signed in from an unfamiliar country. In the SIEM she searches that account's activity for the last thirty days and sees a pattern: several failed attempts from one address, a success, then the creation of a forwarding rule. She searches the same address across every source and finds two other accounts attempted. Three searches took minutes. Without central logs she would have asked three teams for exports.
This example is constructed, but it describes the core value: shortening the path from "something odd" to "here is what happened".
What commonly goes wrong?
Too little data. Teams send only network logs and miss identity and cloud activity, which is where many attacks now live.
Too much noise. Default rules fire constantly, analysts learn to ignore the queue and real signals drown. Tune rules to your environment and retire the ones that never lead to action.
Cost. Pricing often tracks data volume, and teams discover that ingesting everything is expensive. Decide which sources earn their place by the questions they answer.
No owner. A SIEM with no one responsible for parsing, rules and health silently degrades. A source stops sending and nobody notices.
Time. Clocks must agree across systems or event order becomes guesswork.
What are the alternatives?
Smaller teams sometimes use a managed service that runs the SIEM for them, or lean on the built in logging and alerting of their cloud and identity platforms. The right size depends on how many systems you run and who will look at the output at 2 a.m.
How to check or apply this
- List the questions you need to answer in an incident, such as who signed in, what changed and what data left.
- Map each question to the log source that answers it, and onboard those first: identity, cloud control plane, email, endpoints.
- Synchronize time on all sources.
- Write a short list of alerts with an owner and a response step for each.
- Monitor source health and alert when a log source goes quiet.
- Review alert quality monthly and retire rules that never produce action.
- Set retention to match your legal and investigative needs.
Quick check
Is a SIEM the same as a log management tool?
Not quite. Log management stores and searches logs. A SIEM adds correlation, alerting and security specific analysis on top of that collection.
Do I need a SIEM to meet compliance requirements?
Frameworks usually ask for logging, retention and review rather than a named product. Check the exact control wording for the framework you are assessed against.
Sources
- NIST Computer Security Resource Center Glossary, SIEM tool (from SP 800-128)
- NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
Last reviewed: 18 October 2026.
