The gap between growing automation investment and disabled automatic blocking
Automated response is no longer a rare capability in security operations. Security orchestration, automation, and response (SOAR) platforms and individual security appliances commonly ship with functions that terminate a session, change a firewall policy, or lock an account in response to a detection event. The operations floor looks different. Detection, notification, and ticket creation run automatically, but the final step, the one that actually blocks the traffic, still waits for human approval or is switched off altogether.
Survey data confirms the pattern. A 2025 study of vulnerability remediation found that 62% of responding organizations still relied on manual remediation workflows, and only 2% had reached full automation (Mondoo 2025 State of Vulnerability Remediation Report). Vulnerability remediation is an adjacent field, but its structure matches the reality of automatic blocking exactly. Detection and identification are automated, and the process stops at the last step, where the action executes. A wide gap separates the recognition that automation is needed from the decision to actually turn automated action on.
Conservatism does not explain that gap. Behind the decision to disable automatic blocking lies a rational calculation.
The cost of one false block: six-figure downtime costs per hour
A false positive in automated response has a different impact from one at the alert stage. When an alert fires wrongly, an analyst loses time. When a block executes wrongly, normal business stops. The cost of that stoppage has already been measured.
In a downtime cost survey, more than 90% of midsize and large enterprises said an hour of downtime costs them USD 300,000 or more. For 41%, the hourly figure ran from USD 1 million to more than USD 5 million (ITIC 2024 Hourly Cost of Downtime Report). Narrow the scope to high-impact outages and the figure grows. A 2025 observability survey of roughly 1,700 IT practitioners and managers in 23 countries put the median cost of a high-impact IT outage at USD 2 million per hour (New Relic 2025 Observability Forecast).
Read those figures from the standpoint of automatic blocking. Enabling it while the false-positive rate is anything but low creates a structure in which a single wrong judgment turns directly into a loss of hundreds of thousands of dollars per hour. Alert false-positive rates on the operations floor remain high. In a survey of 300 security managers and analysts at US security operations organizations, 45% of the alerts they received were false positives. Overwhelmed by alert volume, 35% said they ignore alerts (IDC InfoBrief, The Voice of the Analysts, 2021). When nearly half of all alerts are false positives, wiring alerts directly to blocking lets false blocks execute unchecked.
For security teams, then, disabling automatic blocking is not risk avoidance but the result of a cost calculation. The problem is that the cost of responding late is growing at the same time.
Automated versus manual response: speed and cost compared
Faster attacks change the security team’s cost calculation. In eCrime attacks, breakout time, the average time an attacker takes to begin moving laterally to other systems after initial access, was 29 minutes in 2025, 65% faster than the year before. The fastest case took 27 seconds, and in one observed intrusion, data exfiltration began within four minutes of initial access (CrowdStrike 2026 Global Threat Report).
A manual response path, in which a person checks the alert, investigates, and approves, runs in hours rather than minutes, however short it is kept. When attacks start spreading within 29 minutes, a single manual approval step is enough to make the defense fail.
The effect of automation also shows in the numbers. According to the 2025 data breach cost report, organizations that applied AI and automation extensively across security operations shortened the breach lifecycle by an average of 80 days compared with those that did not. They also saved an average of USD 1.9 million per breach. Against a global average breach cost of USD 4.44 million, that saving exceeds 40% (IBM Cost of a Data Breach Report 2025). The two approaches compare as follows.
The comparison does not show either side winning. Automated response has the edge in speed and breach cost reduction, but that gain comes only when the judgment is correct. Automation without trusted judgment takes on downtime risk; forgoing automation takes on breach cost. The industry chose staged autonomy over that dichotomy.
The industry’s direction: staged autonomy, not full autonomy
The trend in the security operations market is not an either-or question of whether to enable automated response. It is an approach that divides the level of autonomy by scenario and raises it in stages.
In practice, it works like this. Automation starts with scenarios in which a false positive is extremely unlikely and the side effects of the action are limited, for example blocking communication with known malicious infrastructure. Behavior that is hard to separate from normal work, for example bulk data access by an internal account, keeps a human approval step. Once operating data accumulates and proves the accuracy of judgment in a given scenario, that scenario moves up a level of autonomy. In this structure, the adopting organization, not the vendor, decides the level of autonomy.
This approach is spreading because tolerance differs by organization and by industry. In regulated industries and always-on service environments, the cost of a false block is high, so a conservative setting is rational. In environments where a breach would be catastrophic, the incentive to accept a higher level of autonomy is strong. Even within one organization, different network segments can sit at different levels. Instead of a single goal called full autonomy, a roadmap that widens the autonomous scope as trust accumulates is settling in as the realistic adoption path.
For an adopting organization, the implication is clear. When evaluating an automated response solution, the question to ask is not which actions it can automate. It is how the levels of autonomy can be divided and how the accuracy of judgment at each level can be verified.
The grounds for raising the level of autonomy
Raising a level depends on one check: whether the grounds for the action can be verified. Trust is established only when Explainability (XAI) records the raw transaction/session data that confirmed the threat, the items that deviated from the behavioral baseline, and the grounds for choosing the action. With alerts and logs alone, that verification stops at inference. Closed-loop automation that runs from detection through analysis and judgment to response, or autonomous security operations, also rests on trust accumulated this way. Structurally reducing false positives in automated response is a question not of response features but of the context data fed into the judgment: Raw Transaction/Session, Behavioral Baseline, and Explainability (XAI).
Frequently asked questions
Q. Can automatic blocking be turned on as soon as it is deployed?
The recommended approach is to set levels by scenario rather than turn it on across the board. Start with scenarios in which a false positive is unlikely and the side effects are limited, and widen the scope once operating data proves the accuracy of judgment. That path is the realistic way to manage the risk of a false block and the risk of a delayed response together.
Q. How does staged autonomy differ from the SOAR playbooks already in place?
SOAR is a tool that executes response procedures automatically; staged autonomy is the operating framework that decides how far that execution may proceed without human intervention. If the playbooks exist but an approval step applies uniformly to every scenario, the next step is to differentiate the level of autonomy by scenario, according to how far its judgment can be trusted.
Q. What decides whether the level of autonomy can be raised?
The criterion is whether the grounds for an action in that scenario can be verified after the fact. Three things must be checkable: whether the raw transaction/session data confirms the threat, what deviated from the behavioral baseline, and whether Explainability (XAI) explains why the action was chosen. Only then can the organization measure the false-positive rate and accumulate trust.
