The pitch for SOAR platforms was straightforward: automate your tier-1 SOC workflow. Reduce the manual triage work. Free analysts for higher-value tasks. This pitch was not wrong — it just described a narrower slice of the problem than most buyers realized. Implementing a SOAR platform typically automates alert routing, ticket creation, and notification delivery. These are genuine improvements. They are also, strictly speaking, forwarding — moving alerts from one queue to another more reliably. The tier-1 problem is not forwarding. It's evidence quality.
What Tier-1 Actually Does (And What Automation Gets Wrong)
When an L1 analyst reviews an alert, the decision they're making is not primarily "is this a real threat?" It's "do I have enough evidence to form a position on whether this is a real threat?" Those are different questions. The first is a verdict. The second is an evidence-gathering threshold. A skilled L1 analyst can often get to a preliminary verdict in 3-5 minutes — but only because they've already spent 8-12 minutes on enrichment: looking up the IP in VirusTotal, checking the user account's recent authentication history, pulling the process lineage from the EDR, verifying the asset's criticality in the asset management system.
Most SOC automation automates the forwarding step — the alert moves from SIEM to SOAR to ticketing system. It doesn't automate the enrichment work that makes the forwarded alert actionable. The analyst still opens the ticket, still pulls the enrichment manually, still spends the same 8-12 minutes per alert on context gathering. The ticket now has a JIRA number and a Slack notification, but the investigation time hasn't changed.
This is the fundamental design error in how tier-1 automation was initially conceived: it optimized for process visibility (everything in one ticketing system) rather than analyst throughput (faster time to evidence-based decision).
What Real Tier-1 Automation Looks Like
Genuine tier-1 automation — the kind that actually moves MTTD and reduces analyst load — front-loads evidence gathering before the alert reaches a human. The goal is that when an analyst opens a ticket, the enrichment work is already done. The analyst's job is judgment, not lookups.
A well-designed automated tier-1 workflow for a critical-severity alert might look like this: alert fires in Splunk (or Sentinel) at 03:17 UTC. Automated process begins immediately. Within 60 seconds: the source IP is queried against VirusTotal, Shodan, and an internal threat intel feed; the associated user account's last 7 days of authentication activity is pulled and baseline-compared; the process creation event is enriched with parent process lineage from the EDR; the affected host's asset criticality and business function are pulled from the CMDB. Within 90 seconds: the enriched context package is assembled and attached to the ticket. Within 2 minutes: if the enrichment shows the IP has a VirusTotal conviction rate above 15 vendors, the alert is auto-prioritized and an analyst is paged. If the IP is clean and the user activity shows no anomalies, the alert is soft-closed with evidence logged and placed in review queue.
This is evidence-first automation. The analyst paged at 03:18 UTC opens a ticket that already contains the enrichment context, the behavioral baseline comparison, and a preliminary risk assessment. Their first action is a judgment call, not a lookup. The 10 minutes of pre-work happened in under 2 minutes, automatically.
The SOAR Playbook Drift Problem
SOAR platforms introduce their own class of operational risk: playbook drift. A playbook written six months ago may reference API endpoints that have changed, data fields that have been renamed in a new SIEM version, or threat intelligence sources whose response schemas have been updated. When the playbook silently fails on a field lookup, it returns empty context rather than an error. The analyst sees a ticket with incomplete enrichment and doesn't know whether the field is empty because the artifact is unknown, or because the playbook is broken.
We're not saying SOAR platforms are fundamentally flawed — the automation architecture is sound. The maintenance burden is underestimated. Playbook maintenance requires the same discipline as detection rule maintenance: version control, documented dependencies, change notification from upstream data sources, regular validation runs against synthetic test cases. Most organizations implement SOAR playbooks as a project deliverable and treat them as finished. They're not finished. They're running software that has external dependencies that change.
A practical playbook maintenance cadence: after any SIEM version upgrade, any EDR platform update, any changes to integrated threat intel feed APIs, any network or naming changes that affect asset data — run the playbook test suite. If you don't have a playbook test suite, build one before deploying automation that closes alerts without analyst review. Silent playbook failures in auto-close workflows produce the most dangerous blind spot in SOC operations: alerts that were generated correctly but disappeared from the queue without being reviewed.
Analyst Approval Workflows: Where to Draw the Line
There is genuine debate in the SOC community about how far automated response should go without human approval. The conservative position: automate enrichment and triage, but require analyst approval before any response action (blocking, isolation, account suspension). The aggressive position: for well-characterized high-confidence playbooks, automate response to reduce the seconds-to-minutes gap between detection and containment.
The right answer depends on the cost asymmetry in your environment. Auto-isolating a compromised endpoint has a recovery cost — help desk ticket, analyst verification, endpoint re-image if necessary — but the cost of not isolating a ransomware payload spreading laterally to domain controllers is vastly higher. For endpoint isolation during active ransomware execution (T1486 indicators present), auto-response with post-hoc notification is often the right call. For account suspension (T1078.004 — valid account abuse in cloud services), auto-suspension risks disrupting legitimate operations if the confidence threshold is miscalibrated. The business impact asymmetry should drive the approval workflow design, not a blanket policy.
Measuring Tier-1 Automation Effectiveness
The metrics that reveal whether tier-1 automation is working are more specific than "alerts processed per day." More useful signals:
Time-to-first-action (TTFA): the gap between alert generation and the first automated enrichment action. This should be seconds to single-digit minutes. If TTFA is exceeding 10 minutes on your SOAR, you have a queue backlog problem in the automation layer itself.
Analyst-open-to-decision time: how long between an analyst opening a ticket and making a triage decision. If this hasn't decreased after implementing tier-1 automation, the automation is routing, not enriching. Target should be under 3 minutes for enriched alerts, compared to 10-15 minutes for manually-enriched alerts in a pre-automation environment.
Playbook success rate: the percentage of playbook executions that complete without error. Track this per playbook, with trending over time. A playbook that was running at 98% success rate three months ago and is now at 87% has a degrading dependency — find and fix it before it reaches 70% and starts corrupting analyst context at scale.
The teams that get the most from tier-1 automation are the ones that built it around what analysts actually need to make decisions — not around what SOAR vendors demonstrated in their sales proof-of-concept. The proof-of-concept always shows a perfectly executed playbook auto-resolving a textbook false positive. Production shows a 3am alert with a partially-enriched context block, a broken threat intel API, and an analyst who needs to make a call in the next four minutes. Build the automation for that scenario.