A SIEM gathers logs from across your environment, correlates them and raises alerts. A SOAR takes an alert and runs a defined response, such as enriching an address, opening a ticket or disabling an account. SIEM answers "what is happening," and SOAR answers "what do we do about it, automatically."
What is a SIEM?
NIST's glossary, quoting SP 800-92 on log management, describes security information and event management software as a program that provides centralized logging capabilities for a variety of log types. In practice it also normalizes events, correlates across sources and alerts on rules. The SP 800-92 guide itself is about the underlying discipline: deciding what to log, keeping logs, protecting them, and analyzing them.
A SIEM is only as good as what feeds it. If authentication logs, endpoint logs and cloud audit logs are missing, no rule can find what they would have shown.
What is a SOAR?
SOAR stands for security orchestration, automation and response. NIST does not define it the way it defines SIEM in the glossary entry we checked, so treat the following as a general description. A SOAR tool connects to other systems through integrations and runs playbooks, which are step by step workflows. A playbook might take a phishing alert, pull the message headers, check the sender domain against threat intelligence, search for other recipients, and delete the message from all mailboxes after approval.
It sits on the response side of incident handling, which NIST SP 800-61 Revision 3 organizes as detection, analysis, response and recovery inside the Cybersecurity Framework.
How do they differ side by side?
- Main input: SIEM takes raw logs and events. SOAR takes alerts and cases.
- Main output: SIEM produces detections. SOAR produces actions and documented cases.
- Skill needed: SIEM needs detection engineering and log knowledge. SOAR needs workflow design and integration work.
- Failure mode: a SIEM with poor data misses attacks. A SOAR with a bad playbook does the wrong thing quickly.
Do you need both?
Not on day one. Small teams often start with centralized logging and a handful of alerts, then automate the response tasks they repeat most. Automation pays off when a task is frequent, well understood and low risk. Automating a step you do not yet understand only makes mistakes faster.
Some products bundle both functions. Judge by what each function does for you, not by the label.
A constructed example
A SIEM rule fires when one account logs in from two countries within ten minutes. Without SOAR, an analyst checks the account, looks up both addresses, contacts the user and resets the password, which takes about twenty minutes of attention. With a playbook, the lookups and the user message happen automatically, and the password reset waits for one click of approval. The detection came from the SIEM. The speed came from the SOAR.
What are the common mistakes?
Teams often buy automation before they have good detections, then automate responses to noisy alerts and create more work. Others write playbooks as one long script that nobody can read, so a change breaks something silently. A better habit is to build small steps, name them clearly, give each an owner and a test, and record what each run did so an analyst can see why an account was disabled.
How to check or apply this
- Confirm the SIEM receives the logs you need, such as identity, endpoint, cloud and network sources.
- Write down your five most repeated response tasks, and measure how long each takes.
- Automate read-only steps first, such as lookups and enrichment.
- Put a human approval on any step that changes something, such as blocking or deleting.
- Test playbooks against past incidents before they run live.
- Review playbook runs each month, since the environment drifts.
- Protect the logs themselves from tampering, as SP 800-92 advises.
Quick check
Can a SOAR replace a SIEM?
No. A SOAR acts on alerts and needs a source of them. The detections usually come from a SIEM or other tools.
Which should a small team buy first?
Usually centralized logging with detections, because you cannot respond to what you cannot see.
Sources
- NIST SP 800-92, Guide to Computer Security Log Management
- NIST glossary, Security Information and Event Management
- NIST SP 800-61 Rev. 3, Incident Response Recommendations
Last reviewed: 18 October 2026.
