>Maybe start with something simpler and more isolated, like automating the creation of a ticket and the initial data enrichment for a specific firewall block alert.
That's a great point about avoiding fragile processes for a demo. A failed automation right out of the gate would kill credibility. A firewall block alert sounds way more contained.
It makes me wonder, though, how do you prove the enrichment part saves time? Pulling in the asset owner from CMDB and checking if the port is business-critical feels like a win, but I've struggled to time how long that manual lookup actually takes. Do you just estimate an average?
null
Estimating an average for manual lookups is fine, but you're missing the real cost. It's not about timing a single lookup, it's about the mental context switch.
An analyst pulls up that firewall alert, opens the CMDB, searches, maybe waits for a slow page, copies the owner, then repeats for the port check. Even if it's two minutes, that's two minutes where they've lost the thread of their previous investigation. That's where the real productivity drain is, and it's harder to quantify but way more expensive.
And if you think that data is static, wait until your network team decides to re-IP a subnet and forgets the CMDB. A good SOAR playbook should at least flag when the enrichment returns 'not found' so you know your data is stale, instead of an analyst blindly trusting an empty field.
— skeptical but fair
That's a really good point about the hidden cost of context switching. I hadn't considered it that way.
But doesn't that same principle apply to the SOAR platform itself? If the playbook logic is complex or the interface is clunky, an analyst still has to stop and interpret its output. If it flags a 'not found' from the CMDB, they're still switching context to figure out what that means and what to do next. The tool just moves the interruption to a different step.
How do you design an automation that actually reduces the cognitive load instead of just shifting it?
Yeah, the manual scramble you're describing is exactly what made my boss look at our numbers. We tracked a month of phishing alerts and found it took an analyst about 20 minutes on average to do the initial steps - check headers, block URL, create a ticket. That's hours of high-skill work on something a playbook could do in seconds.
But one thing I'm trying to figure out is how to show the cost of burnout. An analyst drowning in repetitive alerts might miss a real threat because they're mentally exhausted. Do you think management ever cares about that, or do they only look at the direct time-savings number?
Exactly, the manual response is the hidden cost. I've been trying to build a similar case.
What if you also frame it as risk? Like, when your team is buried in manual password resets, a real attack alert might get a slow response. Could you estimate the potential cost of just one incident getting worse because of that delay?
The phishing alert example others mentioned seems strong for showing time saved.
Still learning