Three years inside a SOAR platform: what security automation actually looks like

When people hear that I run the automation platform for a security team, they picture something cinematic. A dark room, a wall of screens, robots quietly neutralising threats while the humans sip coffee and occasionally nod at a dashboard. The vendors sell it that way too: buy the platform, flip it on, and the SOC runs itself.

I've spent the past few years actually living inside one of these platforms, a SOAR, which stands for Security Orchestration, Automation and Response, and I want to tell you what it's really like. Because the reality is less Iron Man suit and more a very capable, very literal intern who has to be taught every single thing, never improvises well, and occasionally does something catastrophic at 2am because a vendor renamed a field.

What SOAR actually is, under the marketing

Strip away the acronym and a SOAR platform does three things. It orchestrates, meaning it connects all your separate security tools so they can talk to each other. It automates, meaning it runs sequences of steps, the playbooks, so a human doesn't have to click through them by hand. And it handles response, meaning it can actually take action: quarantine a mailbox, isolate a host, open a ticket.

The playbook is the heart of it. A playbook is just a flowchart that executes: alert comes in, pull the indicators, check them against threat intel, decide, act. Written down like that, it sounds trivial. Building one that survives the real world is anything but, and that gap is where the entire job lives.

The first law: automate a process only after it survives reality manually

Here is the hardest lesson, and I learned it the way everyone does, by ignoring it first. If your analysts cannot perform a process consistently by hand, automating it does not fix the inconsistency. It just produces the inconsistency faster, at scale, with more confidence, and now nobody's watching.

Automation is not a substitute for a process. It is a multiplier of one. Point it at a clean, well-understood workflow and it is magnificent. Point it at a messy, ambiguous, "it depends who's on shift" workflow and you have simply built a machine for making the same mistake a thousand times before lunch. So the real first step of automating anything is the unglamorous one: define the process so precisely that a literal intern could follow it. Then, and only then, hand it to the machine.

Measure before you automate (or: curiosity is a terrible prioritisation function)

My second lesson was more embarrassing. When I started, I automated the alert class I found most interesting. Naturally. It was a satisfying technical problem and I wanted to solve it.

It was also about [X]% of the actual queue. I had spent my effort on the alerts I enjoyed, not the alerts that were eating the team's hours. Curiosity, it turns out, is a wonderful engine and a catastrophic prioritisation function for operational work.

What you actually do is instrument the queue first: measure the touch time per alert class and the volume per alert class, and multiply them. The product tells you where the hours genuinely go, and it is almost never the class anyone wanted to work on. The highest-value automation is usually the most boring, highest-volume, lowest-prestige alert in the building. Automate that, and you give the team back real time. Automate the fun one, and you give yourself a nice afternoon.

What automates beautifully, and what doesn't

3 years in, I can draw the line fairly cleanly. The mechanical, deterministic parts automate beautifully: pulling indicators out of an email, enriching them against intel feeds, gathering context, opening and routing tickets. These are lookups and plumbing. A machine should always do them, and do them the same way every time.

The judgment parts do not automate, and pretending otherwise is how you get burned. "Is this ambiguous thing actually malicious, given everything we know about this specific environment today?" is not a lookup; it is a decision, and decisions that carry real consequences keep a human in the loop. And anything irreversible, wiping a device, disabling a senior person's account, stays behind an explicit human approval, because a playbook that can be wrong should never also be able to detonate.

The part nobody tells you: it's mostly plumbing

The unglamorous truth is that a great deal of this work is integration plumbing. API quirks. Rate limits. Authentication that expires at the worst possible moment. A vendor silently changing a response format so a playbook that worked perfectly for six months breaks at 3am and pages me. The automation that looks effortless from the outside is held together by a surprising amount of careful, defensive, deeply unglamorous engineering on the inside.

And that's fine, because it's the actual job. The measure of a SOAR platform isn't how clever its playbooks are. It's whether it keeps working when the real world does what the real world does, which is change without telling you.

What it's really for

The thing the cinematic version gets most wrong is the goal. Good automation is not about having fewer analysts. It's about freeing the analysts you have from the mechanical grind so they can spend their scarce attention on the part that actually needs a human: the thinking.

The real deliverable of a security automation function isn't a robot SOC. It's a team that no longer loses its best hours to copy-paste enrichment, and a set of processes so well-defined that capability no longer depends on one particular person being awake. Because capability that lives in one person's head isn't capability. It's a single point of failure with a pulse.

SOAR, in the end, isn't magic. It's discipline, wearing a very expensive costume. The wins are boring, measured in hours returned and mistakes prevented, and they are completely real.

If you work in a SOC: what's the one alert class you'd automate first if you could, and have you actually measured whether it's the one eating your hours? I'd bet half of you are about to automate the fun one.