Summarize the Content of the Blog
Key takeaways
MTTR is not one number. It is a sum of steps, and only some of those steps are automatable. The honest question is what fraction of your MTTR is mechanical.
The saving from SOAR is the automatable time multiplied by incident volume. A small per-incident saving on a high-volume incident beats a large saving on a rare one.
Manual response also carries a variance cost: humans are inconsistent, especially under load, and inconsistency causes missed steps. SOAR removes that variance.
If you cannot estimate your per-incident time and volume, you cannot justify SOAR honestly, and that is the first thing to measure.
What MTTR is actually made of
Mean time to respond gets quoted as a single figure, which hides the thing that matters. MTTR is a sum: the time to enrich, plus the time to investigate, plus the time to decide, plus the time to act, plus the time to document.
That breakdown is the whole analysis, because those steps are not equally automatable. Enrichment is almost entirely mechanical. Investigation is partly mechanical. The decision is human. The action is often mechanical. Documentation is mechanical.
So the useful question is never "will SOAR reduce our MTTR." It is "what fraction of our MTTR is the mechanical work SOAR can remove." For most incident types that fraction is large, because the decision, the one genuinely human step, is usually a small slice of the total clock time. Most of MTTR is the gathering and the doing around the decision, not the decision itself.
The manual cost, calculated
Take a real example and put numbers on it. These are illustrative; the point is the method, not the specific figures.
Suppose a user-reported phishing incident takes an analyst 15 minutes end to end: 8 minutes pulling the email and gathering context, 2 minutes deciding, 3 minutes acting (blocking sender, purging copies), 2 minutes documenting.
Now suppose your team handles 200 phishing reports a month. That is 200 times 15 minutes, or 50 analyst-hours a month, on one incident type. Put that next to an analyst's loaded hourly cost and you have a real, defensible number for what manual phishing response costs you annually.
This calculation is the entire foundation of a SOAR business case, and most teams have never done it. They know phishing triage is tedious. They have never multiplied it out. The multiplication is what turns "tedious" into a budget line.
What SOAR removes, and what it doesn't
Back to the 15-minute breakdown. What can a playbook actually take?
The 8 minutes of enrichment: yes, almost entirely. A playbook pulls the email, checks sender and links, detonates attachments, and searches for other recipients automatically.
The 2 minutes of decision: no. That stays with the analyst, and it should.
The 3 minutes of action: mostly, often behind an approval click.
The 2 minutes of documentation: yes, if case management populates the case automatically.
So of 15 minutes, roughly 11 to 13 are automatable and about 2 remain human. The per-incident time drops from 15 minutes to perhaps 3. That is not a guess about SOAR being "faster." It is a step-by-step accounting of which minutes are mechanical.
Notice what did not change: the analyst still makes the decision. SOAR did not replace judgment. It removed the 13 minutes of toil surrounding the 2 minutes of judgment. The buyer-level version of this argument, and where it stops being worth it, is in Splunk SOAR Services: Where Automation Delivers ROI.
The multiplication that decides it
Now multiply the saving by volume, because that is what decides whether SOAR pays off.
At 200 incidents a month, saving 12 minutes each returns 40 analyst-hours a month. Over a year, that is 480 hours on a single incident type, before counting any other playbook. Against the build and maintenance cost of one phishing playbook, that is a straightforward positive return.
Run the same math on a rare incident. Saving 12 minutes on something that happens twice a month returns 24 minutes a month, or about 5 hours a year. That will not cover the cost of building and maintaining the playbook. Same saving per incident, completely different verdict, because volume changed.
This is why the earlier advice to rank use cases by volume is not a preference, it is the arithmetic. The measurement methodology for playbook effectiveness once you are running is covered in Splunk SOAR Playbook Patterns That Cut MTTR.
The cost manual response hides
The time math understates the case, because manual response carries a second cost that does not show up on a stopwatch: variance.
A human doing 15 minutes of enrichment does it slightly differently each time, and very differently at 3am in month eleven of a hard year. That inconsistency is where steps get missed, and a missed step is how a containable incident becomes a breach. A playbook does the same thing every time, at any hour, in any month. The value of that consistency is real but hard to price, so it usually gets left out of the business case, which means the honest business case is stronger than the time math alone suggests.
There is a floor cost too. SOAR is not free time. Playbooks cost effort to build and maintain, and that maintenance is ongoing as tools and threats change. The arithmetic only works when the volume-driven saving clearly exceeds that maintenance cost, which is precisely why you calculate before you build.
bitsIO, a four-time Splunk Partner of the Year and Splunk Elite Partner, runs this calculation with clients before scoping any playbooks, through its Splunk SOAR practice, so the first automation is one the math already justified.
