Disclaimer: Opinions expressed are solely my own and do not reflect the views or opinions of my employer or any other affiliated entities. Any sponsored content featured on this blog is independent and does not imply endorsement by, nor relationship with, my employer or affiliated organisations.

The SOC playbook. It's been the backbone of security operations since cybersecurity became a thing. I started my career in this field 15 years ago, and honestly, not much has changed about the concept. A playbook is like a recipe; it's a simple idea that just works, and there's not a whole lot you can do to change the core concept. What has changed is how we interact with it.

Initially, it was just humans following the steps. Then, automation came along, and we started using SOAR platforms to automate bits and pieces of the playbook. Now, we have AI, and surprise, we're using it to write playbooks or have it follow the steps for us.

The whole point of a playbook was to solve the "tribal knowledge" problem. It's simple: document your processes so everyone is on the same page.

But here’s the sad story: they are broken, and they have been since we started using them.

Don't get me wrong, there are cases where playbooks work perfectly. In highly regulated environments, for instance, they have to be followed to the letter (which, in my view, is a fast track to analyst burnout). But in most SOCs? Not so much.

From what I’ve seen, someone writes them, and they’re great for new joiners to understand how a specific organisation works. But are they followed consistently? Nope. Unless you have a deterministic automation platform that forces those exact steps, analysts tend to go off-script.

Experienced analysts, especially those who have been in the SecOps space for a while, usually go by instinct. If I asked you to pull the alerts from the past year, analyse the summaries, and check if the playbook steps were followed, you'd find a huge percentage are outliers.

And you might think, "who cares, as long as the job gets done?" Yeah, that's true. But I think this is the one loose brick in the SecOps tower that causes the butterfly effect, making everything else seem broken afterward. Now you're wondering, "ok, this seems off."

Let's break it down.

So yeah, I can go on, but I think many of the biggest problems in the SOC trace back to one thing: a broken playbook equals a broken process. It’s funny because of the classic PPT (People, Process, Technology) model, the process is almost always the thing that’s broken.

Ok, enough ranting. You came to this blog to hear about solutions. Can we fix it?

I think yes. I was able to build and implement a framework that helps fix this. The main idea is to implement automation as much as possible, but you have to do it in a specific way.

Start on the left side: Data Ingestion and Detection Engineering. This part is closely tied to threat hunting and threat intel, where your hypotheses and threat profiles begin. You know the basics: understand your environment, know what you need to defend, and know who you're defending it from. Build that basic structure of Assets and Identities—the key to good detections is having this context.

Once you have a new detection (after you evaluate, develop, and test it), you need to figure out what the playbook will be for it. This is the first breaking point for most teams. A detection without a playbook is one of the main causes of bad processes.

Here's a classic example: a new, scary threat emerges. You rush to develop a detection and throw it into production. The first week, everyone knows what it’s about. The first month, maybe. But then the alert goes quiet for a while. The analyst who wrote the detection leaves the company. A year later, you have this shadow detection that no one understands. Now it’s broken, spewing false positives like crazy, and the analysts are just closing them on autopilot.

So yes, stop and build the damn playbook. It's easier than ever. You can throw the alert context into a GenAI tool, and it will spit out a decent draft in seconds. You can even get fancy and embed this step into your detection engineering automation process.

Once you have the playbook, you have the foundation to explore which steps can be automated. Simple, right? Even if it's just one or two steps, it’s a win. That’s how you start. Eventually, you can get to full end-to-end automations. You can even script this whole thing (I’m working on an open-source project for this, but it’s going slow, so stay tuned... subscribe to the blog, because LinkedIn might not show you my posts).

Now imagine this. What if a tool took a different approach? What if you just let your analysts do their job, letting them go wild and investigate alerts however they see fit? And what if this tool just monitored their investigation in the background and built the playbook by itself? Once it's done, the analyst could review it and turn it into an automation.

You might be thinking, "Filip, you just described an RPA solution." Yes, that's true. Sadly, no RPA solution has ever really worked for cybersecurity. The tech wasn't there, and the cyber environment is just too dynamic and unpredictable.

But now we have AI and Agents. We can add an undeterministic approach to these automations when needed. This approach is worth exploring, and there are vendors already working on it (check out the vendor spotlight section).

So, what's the big takeaway here? For years, we've been trying to patch the SOC. We throw more tools at it, we hire more people, we buy more threat intel feeds. It feels like we're just adding more features to a pile of spaghetti code. The real problem is in the core logic—the playbooks.

Those analysts going by "instinct"? They're not breaking the rules. They've just found a better, undocumented way to get the job done. They've built a more efficient process in their heads because the official one is slow, clunky, or just plain wrong. The issue is that this knowledge walks out the door when they do.

This is where that new approach I mentioned gets really interesting. Instead of forcing analysts to follow a rigid script, what if we had a system that could watch them work, learn their shortcuts, and turn that "instinct" into a documented, automated, and up-to-date playbook? This isn't about replacing the analyst. It's about cloning their expertise. It’s about building a process that adapts, instead of one that just gets old.

At the end of the day, a broken playbook is a broken process. And a broken process means your people and your expensive tech are never going to work as well as they should. So maybe, just maybe, before you buy the next shiny AI tool that promises to solve all your problems, take a hard look at your playbooks. That's the bug that's been causing your whole system to crash.