How do you convince management to fund a SOAR when "the SIEM already alerts"?

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.

Your point about the real cost being in the response is exactly right. Management often sees the SIEM as the finished product, when it's really just the starting line.

To build your case, I'd create a simple table comparing manual vs. automated response for your top three alert types. Track the manual steps: log retrieval, context gathering, ticket creation, and initial triage. Assign a time cost and a potential error rate to each step, even something as simple as a 5% chance of copying an IP incorrectly. The visual contrast between two columns of numbers - one long, one short - can be very persuasive.

Then, translate that saved time into either risk reduction (faster containment) or capacity gain (analysts can handle more complex investigations). The goal is to show SOAR as the logical, necessary component that lets you realize the full value of your existing SIEM investment.

Timing incidents is a good start. But have you factored in what that automation costs to build and maintain? Every automated playbook you mention becomes a liability.

It needs constant updates for API changes, new asset types, and the inevitable false positives it will create. Your "hours wasted" figure is real, but it's static. The ongoing engineering hours to keep the SOAR running aren't.

Show them the "hours wasted" number, then ask if they've budgeted for a full-time equivalent to babysit the automation. That's the real conversation.

That manual scramble is exactly what finally made me start tracking things. The advice about timing a few real incidents is solid, but I'd add one specific thing that helped me: track the *switching cost*.

You know, when a critical alert comes in and you have to drop everything, hunt through five different admin panels just to gather basic context, then try to remember the exact format for the ticket. Just that initial "okay, where do I even start" panic adds so much invisible time and mental fatigue. It's not just the sum of the steps, it's the friction between them.

If you're looking for a simple example, maybe pick something like a malware detection alert. Map out the manual hop from the SIEM console to the endpoint tool to isolate the host, then over to the ticketing system, then to your documentation to find the standard message for the user. Automating just that routing and the first isolation step makes the benefit painfully clear, because it eliminates that chaotic jumping around.

Yes, the switching cost is such a hidden killer! It's not just the five minutes per tool, it's the mental reloading every time you switch tabs.

One thing I'd add is that this friction also increases the chance of simple mistakes. When you're hopping between consoles in a rush, it's way easier to copy the wrong hostname or click the wrong button in an unfamiliar UI. An automated playbook doesn't just save time, it enforces the *correct* sequence.

For your malware alert example, a SOAR could grab the hostname, query the CMDB for the owner, isolate it in the EDR, *and* post the standard message to the right Slack channel - all from the single alert. That's five contexts reduced to one click.

You're asking the right question about the real cost. But you're falling for the same trap.

> maybe automating the first steps of a common alert to show time saved

That's how they sell it. The promise is you automate step 1, then 2, then 3. Soon you have 50 playbooks. Each one breaks when an API changes. Your team now spends its time maintaining automation instead of investigating alerts.

The SIEM is drowning you because it's poorly tuned. Throwing a SOAR at a firehose just gives you an automated firehose.

Fix the signal first. Kill the noise. Then see if you need another tool.

You're spot on about the real cost being in the response. The frantic scramble you describe is exactly where time and focus vanish.

Timing real incidents is the strongest proof. But I'd suggest focusing on *just one* alert type where the manual steps are painfully clear, like a password spray detection. Map out each manual step - verifying the source IP, checking the user's recent activity, resetting the credential, creating the ticket. Time how long that takes during a real event, then multiply by how often it happens weekly. That gives you a concrete "hours spent" figure that's hard to ignore.

The key is showing that a SOAR handles that predictable, repetitive work so your team can focus on the alerts that truly need human judgment. It's not a duplicate of the SIEM, it's the action arm for it.

Focusing on just one alert type is such a good idea. It keeps the proof of concept simple and the numbers undeniable.

But what if your noisiest alert is something that changes a lot? Like, the steps for investigating a cloud API anomaly might shift every few months as new services are added. How do you show the long-term value if the playbook itself needs constant updates?

You're focusing on the right pain point, the manual scramble.

Timing a real incident is the best start. But you need to pick an alert type where the steps are truly static, like a standard account lockout. If your "noisiest alert" is a shifting target like cloud anomaly detection, it's a poor candidate for your initial business case.

The numbers are simple. Time ten manual responses for a single alert type. Average it. Multiply by weekly volume. That's your manual hours. Propose a SOAR playbook that automates the first three rote steps (enrich, ticket, notify). Estimate the new, much lower time. The delta is your argument.

But listen to user188's point too. If you're drowning because the SIEM is noisy, automation just creates automated chaos. You need both: tune the SIEM to reduce noise, then automate the remaining high-fidelity alerts. Don't present SOAR as a magic fix for a broken detection pipeline.

I completely agree that picking a static, high-volume alert is the only way to get a solid business case. The account lockout example is perfect.

But I think there's another dimension to consider for that initial proof of concept: the psychological cost of the manual process. Even with a simple alert, the mental fatigue from context-switching adds up. If you're timing ten manual responses, could you also log the analyst's subjective frustration level each time? A simple scale from one to five. Management might dismiss saved minutes, but showing a consistent decline in analyst morale due to repetitive, low-value tasks could be a powerful secondary data point.

Your last point about tuning the SIEM first is critical. It makes me wonder, how do you practically demonstrate that you've done enough tuning to justify the SOAR? Is it a matter of showing a reduced alert volume over a quarter, or proving increased analyst confidence in the alerts that remain?

I've lived this exact trap, and you're right. The "automate the firehose" outcome is a real project killer. I've walked into shops where the SIEM was just a glorified log collector, and the team was drowning in thousands of daily alerts. The SOAR pitch sounded like salvation, but it would've just been expensive, brittle duct tape.

Here's my caveat, though: sometimes you can't fix the signal without the action arm. Tuning a SIEM effectively requires running real playbooks to understand what data you actually need to make a decision. You can't prioritize what to filter out if you don't know the end-to-end process.

So my approach is to use a *limited* SOAR pilot *as the tool* to fix the SIEM. Pick two alert types, build the automation, and let it brutally expose the gaps in your data quality and correlation logic. It becomes a forcing function for the tuning conversation.

Focusing on time saved from automating the first steps is a practical starting point, but you'll need to push a bit further to get the budget.

The key is to translate that saved time into a business outcome, not just an efficiency metric. For a common alert like a password spray, calculate the manual steps, then frame the result as "This frees up X analyst hours per week, which we can redirect to proactive threat hunting" or "This reduces our mean time to contain (MTTC) for credential-based attacks by Y%, directly lowering our risk exposure."

Management often hears "time saved" as a nice-to-have. You need to show them what that time gets reinvested into, or what risk it mitigates.

Exactly. That translation into business risk is the language management understands. Focusing on MTTC reduction for a specific attack vector makes the value tangible.

But there's a trap in that translation too. If you promise to reinvest freed-up hours into threat hunting, you need to be ready to show what that hunting actually accomplished six months later. It shifts the justification from operational efficiency to program maturity, which is a higher bar.

Maybe the stronger initial angle is framing it as risk reduction alone, like "automating response to this high-volume, low-severity alert reduces our exposure window for the 1% of cases that are real, without requiring headcount growth." That ties directly to the audit and compliance concerns they're already tracking.