How can workflows cut a SOC's response time?

Workflows cut response time by turning the steps analysts repeat, such as enriching an alert, checking an account and isolating a host, into documented, partly automated playbooks. Humans keep the judgment calls. Start with the three alert types you see most, and measure time to triage and contain.

Where does response time actually go?

Before automating, find the waiting. Most of an analyst's time on a routine alert is not thinking. It is switching between consoles to collect context: who owns this machine, has this account logged in from here before, is this address known, what else happened on this host in the last hour.

Add queue time, handoffs between shifts and teams, and approvals that sit unseen, and a ten minute decision can take three hours. Time each stage for a sample of recent incidents. The slowest stage tells you what to fix first.

What does the guidance say?

NIST SP 800-61 Rev. 3 recasts incident response as part of cybersecurity risk management and aligns it with the functions of the Cybersecurity Framework 2.0. It treats preparation, detection, response and recovery as continuous activities that feed lessons back into the program, not a one time sequence. The preparation step includes defining roles, procedures and tooling in advance, which is exactly what a workflow is.

How do you design a good workflow?

Keep it small, written and testable.

Pick the trigger. One alert type per workflow, such as a login from a new country or a flagged attachment.

List the steps in order. For each step, mark who does it, what data it needs and what it produces.

Mark each step as automate, assist or human. Gathering context is a safe candidate for automation. Disabling a user or isolating a server affects the business, so start with a one click approval by a person, and move to automatic action only for low risk, well understood cases.

Define the exit. Close as benign, escalate, or contain. Each exit has a required note so the next person can see why.

Add a time target. For example, triage in 15 minutes, containment decision in an hour for high severity. Alert when a case stalls.

Version and review it. Treat a workflow like code, with an owner, a change history and a test.

What should stay human?

Anything where being wrong is costly and context is thin: declaring a breach, notifying customers, wiping systems, contacting law enforcement. Automation should assemble the facts and present a recommendation. A person should make and record the decision.

Also watch for automation that hides problems. A workflow that auto closes alerts may quietly bury a real attack. Sample automatically closed cases weekly and check them.

A constructed example

A team gets about 40 alerts a day for impossible travel logins. Each one takes about 12 minutes by hand. They write a workflow that checks whether the user is travelling according to the leave calendar, whether the second login used a managed device, and whether multi-factor authentication was passed. Cases that pass all three close with a note. The rest go to an analyst with the evidence already attached and an approve button for a forced sign-out. Analysts now spend time on the ones that matter, and a weekly sample of closed cases checks that nothing was missed.

What should you measure?

• Median and 90th percentile time from alert to triage.
• Time from triage to containment for confirmed incidents.
• Share of alerts closed by workflow, and the error rate found by sampling.
• Analyst time per case, before and after.
• Number of stalled cases per week.

Percentiles matter more than averages, since slow outliers are where damage happens.

How to check or apply this

1. Time the stages of ten recent incidents and find the slowest one.
2. Choose the three most common alert types.
3. Write each response as numbered steps with owners and data sources.
4. Label each step automate, assist or human.
5. Automate context gathering first, and add approvals for actions that change systems.
6. Add time targets and stall alerts.
7. Review workflows after every incident and each quarter.
8. Sample automated closures weekly.

Quick check

Sources

• NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• NIST Cybersecurity Framework 2.0
• CISA: Ransomware and Data Extortion Guide

Last reviewed: 18 October 2026.