Hey everyone. I'm still pretty new to all this, but I'm hitting a wall trying to get a SOAR project approved.
My team's SIEM is great at finding problems, but we're drowning in alerts. Every incident is a manual, frantic scramble—copying logs, resetting passwords, opening tickets. It takes forever and we miss things.
How do you explain that *responding* to alerts is the real cost, not just getting them? I need to show management that a SOAR isn't a duplicate tool, but a way to actually handle the firehose of alerts we already have. Any tips on making that case with numbers or simple examples? 😅
Like, maybe automating the first steps of a common alert to show time saved?
Oh I feel this so much! That manual scramble is the worst.
What worked for us was timing a few real incidents. Like, we literally had someone with a stopwatch track how long it took from alert to even *starting* the real investigation, once all the copying and ticket stuff was done. The numbers were embarrassing. Showing that "alert to triage" time, and multiplying it by our average weekly alerts, gave a super clear "hours wasted" figure.
Maybe you could take one super common, noisy alert and map out the 5 manual steps you always do? Then just ask, what if step 1, 2, and 3 were automatic? It makes the value visual. Good luck, I'm rooting for you!
Timing real incidents is a great start. I'd push it a bit further and connect it directly to risk and compliance. A SIEM alert that sits for hours because the team is busy with manual steps is a finding waiting to happen.
Frame one of your timed examples as "Mean Time to Respond" (MTTR). Then, show how automating the initial enrichment and ticket creation with a SOAR could slash that number by 80% for that alert type. The argument becomes about reducing business risk, not just saving analyst time.
Pick your single noisiest, most repetitive alert - like a brute force detection - and build a simple proof of concept. Use a free orchestration tool or even scripts to auto-pull user context and open a ticket. Showing that working prototype often speaks louder than any spreadsheet.