How SIEM and SOAR fit together: logs, alerts and playbooks

SIEM and SOAR have a reputation problem. They cost a lot, they need weeks of tuning before they are useful, and plenty of teams end up with a dashboard full of alerts that nobody trusts. The guidance from the agencies says much the same thing, more politely: neither platform is a "set and forget" tool, and both need skilled people to keep them working (ASD/CISA executive guidance, section 3).

So rather than start with products, this post starts with a kitchen. Logs are the ingredients. The SIEM is the kitchen, where ingredients get washed, chopped and combined into a dish. SOAR is the recipe card pinned to the wall, telling a helper exactly what to do when a certain order comes in. Keep that picture in mind and most of the jargon falls into place.

The vocabulary: logs, events and alerts

The plainest definitions are still in NIST's SP 800-92, Guide to Computer Security Log Management, published in September 2006. It defines a log as a record of the events happening in an organisation's systems and networks. Logs are made of log entries, and each entry holds information about one specific event (SP 800-92, executive summary). Those entries come from security software such as firewalls and intrusion prevention systems, from operating systems, and from applications.

An alert is something different: it is the system telling a person that something needs a look. SP 800-92 links it to correlation. When related entries are correlated automatically, the result is generally a new entry that brings the pieces together in one place, and depending on what it shows, the system might also raise an alert to say the event needs more investigation (SP 800-92, section 3.2).

In the kitchen: a log entry is one onion, an event is "an onion arrived", and an alert is the ticket a chef puts on the pass saying "table 7 needs attention now".

SP 800-92 is old but not abandoned. NIST published a draft revision, the Cybersecurity Log Management Planning Guide (SP 800-92 Rev. 1), in October 2023. At the time of writing it is still an initial public draft (NIST CSRC).

SIEM: collect, normalise, correlate, alert

The 2025 practitioner guidance from Australia's ASD, CISA and their partners describes a SIEM as software that collects, centralises and analyses log data for security. A well-configured SIEM compares that data against a baseline of normal activity, plus rules and filters, to spot unusual activity (ASD/CISA practitioner guidance, section 1). Here are the four jobs, kitchen first:

1. Collect (deliveries). SP 800-92 describes two ways in: agentless, where the server pulls logs or hosts push them, and agent-based, where a small program on each host filters and normalises logs before sending them (SP 800-92, section 3.4).
2. Normalise (washing and chopping everything to the same size). Each data field is converted to one consistent format. NIST's own example is time: one source writes 2:34:56 P.M. EDT, another writes 14:34 and puts the time zone in a separate field (SP 800-92, section 3.2). The 2025 guidance gives a newer example: one source says src_ip, another says sourceAddress, and the SIEM has to know they mean the same thing (practitioner guidance, section 3).
3. Correlate (combining ingredients into a dish). NIST defines event correlation as finding relationships between two or more log entries. The most common form is rule-based: matching entries by timestamps, IP addresses and event types (SP 800-92, section 3.2). A related step is aggregation: NIST's example turns a thousand entries from one scan into a single entry that says how many hosts were scanned.
4. Alert (the ticket on the pass). The dish goes to a human.

 SIEM: collect · normalise · correlate · alert                  
                        \                                       
┌──────────┐              \                                     
│ FIREWALL▪│─·─────────·    \                                   
└──────────┘                  \            ┌─ ALERT ───────────┐
                               \           │                   │
                             ∙   \         │                   │
┌──────────┐                       \────── │ watching.         │
│ ENDPOINT▪│──·──────·──                   │                   │
└──────────┘                       /────── │                   │
                             ∙   /         │                   │
                               /           │                   │
┌──────────┐                  /            └───────────────────┘
│ CLOUD   ▪│───·──────·─    /  correlate                        
└──────────┘              /                alerts: 0            
                        /                  many in, few out     
                      normalise                                 
 in: 43 events/s                                                

The animation shows the point of the funnel: many lines in, few alerts out. One firewall deny is boring, and so is one new process. All three about the same host in a short time is worth a person's attention.

You can see the same ideas in a commercial product's documentation. Microsoft describes Sentinel as a cloud-native SIEM that normalises data from different sources at ingestion time and at query time (its ASIM model), and uses analytics to group alerts into incidents to cut noise (Microsoft Learn).

SOAR: the recipe card

The ASD/CISA guidance describes SOAR as a platform that automates the response to anomalous activity by applying predefined playbooks, which set out some of the actions to take when a specific security event happens. The guidance is clear that these automated actions do not replace human incident responders. They take over some steps so the team can focus on harder problems (practitioner guidance, sections 1 and 2). Some SOARs have a SIEM built in; many sit on top of a separate one.

That is the recipe card. When ticket type X arrives, the helper follows the card: look up the customer, check with the chef, plate it, send it out. In security terms, a playbook might enrich an alert with user and host details, ask an analyst to decide, isolate the host, and open a ticket.

 SOAR playbook: the recipe card       case notes                
                                     ┌─────────────────────────┐
    ┆   ┌────────────────────────┐   │                         │
 [!]┆   │ 1 ENRICH   auto        │   │                         │
    ┆   └────────────────────────┘   │                         │
    ┆                                │                         │
    ┆   ┌────────────────────────┐   │                         │
    ┆   │ 2 DECIDE   analyst     │   │                         │
    ┆   └────────────────────────┘   │                         │
    ┆                                │                         │
    ┆   ┌────────────────────────┐   │                         │
    ┆   │ 3 CONTAIN  auto        │   └─────────────────────────┘
    ┆   └────────────────────────┘                              
    ┆                                 steps run in order        
    ┆   ┌────────────────────────┐                              
    ┆   │ 4 TICKET   auto        │    repeatable steps: auto    
    ┆   └────────────────────────┘    judgement: a person       
                                                                

In Microsoft Sentinel, for example, playbooks are workflows built in Azure Logic Apps. They can run on demand, or automatically when an automation rule triggers them on an alert or incident, and connectors let them open tickets in systems such as ServiceNow or Jira (Microsoft Learn).

The guidance also lists the risk. A badly configured SOAR can mistake normal behaviour for an incident and isolate things automatically, which disrupts the business. For that reason it says SOAR is usually not suitable for immature environments (no SIEM yet, a brand-new SIEM, or no experienced team). Getting the SIEM right comes first (practitioner guidance, section 3). One of the executive guidance's key actions says it in one line: test SIEM before deploying SOAR (executive guidance).

That is why the playbook in the animation has a human step in the middle. Automating a recipe you have never cooked by hand is how you burn the kitchen down.

Shop for staples first: the priority logs

The third document in the 2025 set, Priority logs for SIEM ingestion, is the shopping list. It lists log sources in a loose order of priority. The authors say plainly that the list is incomplete, that the order will not suit every organisation, and that it is a starting point for a typical enterprise network. The order is:

The advice around the list matters as much as the list:

• Build up gradually. Add data sources a few at a time, not all at once.
• No logging for the sake of logging. For each source, think about its purpose, its priority, how much volume it makes and what it is worth for analysis. The guidance notes that firewall or DNS logs can be so large that the volume overshadows the useful information in them.
• The SIEM is not the pantry. The agencies strongly discourage using a SIEM as the central store for all logs. Logs kept for compliance can live in a data lake or other cheaper storage, and only security-relevant logs should go to the SIEM.

The practitioner guidance explains why this matters for your budget: most SIEM pricing is based on how much log data you ingest, and some default settings push that number up (practitioner guidance, principle 4). For organisations new to detection it also suggests a starting point for retention: at least one year for administrative and security logs, and 90 days for informational logs (principle 7).

Recipes you can carry between kitchens: Sigma

If every SIEM has its own query language, every detection you write is locked into one product. Sigma is an attempt to fix that. Its README calls it a generic, open signature format for describing log events, and puts it this way: Sigma is "for log files what Snort is for network traffic and YARA is for files". The main repository holds more than 3,000 detection rules, released under the Detection Rule License (DRL) 1.1.

A Sigma rule is a YAML file. The required parts are a title, a logsource (category, product, service) and a detection block with a condition (Sigma docs). Here is a small illustrative rule I wrote for this post. It watches for the Windows "audit log cleared" event (1102), which the priority logs guidance lists for Windows endpoints:

title: Windows security log cleared
status: experimental
logsource:
    product: windows
    service: security
detection:
    selection:
        EventID: 1102
    condition: selection
falsepositives:
    - Planned log maintenance by administrators
level: high

The official converter, sigma-cli, turns rules into a specific SIEM's query language with a backend plugin, for example sigma plugin install splunk and then sigma convert -t splunk -p sysmon <rules>.

This is where detection-as-code comes in. When detections are text files, you can keep them in Git, review changes and test them in CI, just like application code. Sigma's docs describe exactly this under "bringing CI/CD to your detection workflow", including version control over your detections (Sigma docs). The ASD/CISA guidance makes a related point: standardising your log events can let you use common detection rules from community or vendor sources, and deploy them faster (practitioner guidance, section 2).

Why the cooks matter more than the oven

The most useful part of the guidance, in my opinion, is how much of it is about people and tuning rather than features:

• Good analysis means true positives and true negatives. An alert when something is happening, silence when nothing is. Too little data or weak rules give false negatives. Too much data and noisy rules give false positives and alert fatigue. The guidance says the second problem is the more common one, because teams prefer to collect too much (practitioner guidance, section 3).
• Baselines take weeks. You need to know what normal looks like before you can spot unusual activity, and building that takes at least several weeks of collecting, querying, investigating and tuning (principle 6). If the network is already compromised, there is a risk that malicious activity gets accepted as normal.
• Silence can be a fault. A failed query often returns nothing, which looks the same as "nothing to report". Teams need a way to notice when systems stop sending logs (principles 6 and 7).
• Plan for people. If you run the platform yourselves, expect several staff working on it full time, plus ongoing training (section 3 and principle 5).
• Test it. Run regular exercises with well-known attacker techniques, so you know the logs arrive, the alerts fire and the playbooks do what you expect (principle 11).

Tasting and adjusting the seasoning never stops. The menu changes, the suppliers change, and so do the customers trying to sneak into the kitchen.

A small-team starter view

If you are a small team looking at all this, here is how I would read the guidance. These are my suggestions, not an official checklist:

1. Write down what you want to detect before you choose a product. The guidance recommends a scoped proof of concept with a named system owner (principle 1).
2. Start with the top of the priority list. EDR and network devices first, then identity (domain controllers and AD), and check each source is actually useful before adding the next.
3. Separate the pantry from the kitchen. Keep compliance logs in cheaper storage; send security logs to the SIEM.
4. Write detections as files (Sigma or your SIEM's own format) and keep them in version control.
5. Leave SOAR for later, and when you do start, automate the boring, low-risk steps (enrichment, tickets) before anything that isolates a machine.

If budget is the blocker, open-source options exist. CISA's Logging Made Easy is a no-cost, open-source platform for small and medium organisations, built on Wazuh, Elastic and ElastAlert. One caution: CISA retired support for it on 22 May 2026. You can still use it, but CISA no longer maintains it, so treat it as a learning lab or a community project rather than a supported product.

The kitchen only works when the ingredients are fresh, the cooks know the menu and the recipe cards have been cooked by hand first. The products help, but they are the oven, not the chef.

Sources

• NIST SP 800-92, Guide to Computer Security Log Management (CSRC page)
• NIST SP 800-92 (PDF)
• NIST SP 800-92 Rev. 1 (initial public draft), Cybersecurity Log Management Planning Guide
• CISA: Guidance for SIEM and SOAR Implementation
• ASD/CISA: Implementing SIEM and SOAR platforms, Executive guidance
• ASD/CISA: Implementing SIEM and SOAR platforms, Practitioner guidance
• ASD/CISA: Priority logs for SIEM ingestion, Practitioner guidance
• Microsoft Learn: What is Microsoft Sentinel SIEM?
• SigmaHQ: Sigma rule repository
• Sigma docs: Rules
• Sigma docs: About Sigma
• SigmaHQ: sigma-cli
• CISA: Logging Made Easy (GitHub)