Executive summary
Security teams spent twenty years learning to see. SIEM, EDR, NDR and their successors made the modern enterprise more observable than it has ever been. That work paid off: more than half of intrusions are now caught by the victim's own team rather than by an outsider [1]. But the same investment produced a side effect nobody budgeted for. A mid-size organisation now generates thousands of alerts a day, and two-thirds of them are never investigated at all [2].
The constraint on security outcomes has moved. It is no longer whether you can detect an attack. It is whether anyone can respond to what you detected, at the speed and volume the alerts arrive. Detection is a data problem, and data problems scale with compute. Response has stayed a people problem: every alert needs someone to ask whether it is real, how far it goes, and what to do about it. People do not scale the way alert volumes do, and the 4.8 million unfilled security roles worldwide say the industry cannot hire its way out [3].
This paper examines that gap: how it formed, why the standard fixes (more analysts, outsourcing, playbook automation) each stall, what the gap costs in analyst hours and breach exposure, and what an autonomous approach to response has to deliver before a security leader should trust it. CounterShadow's own platform appears in the final section; the framework before it is deliberately vendor-neutral, and you can use it to evaluate anyone, including us.
Three questions frame the argument, and they are worth asking of your own operation before reading on:
- What happens to an alert that fires at 3am on a Sunday?
- How long passes between an alert firing and the threat being contained?
- If alert volume grew 50% next year, what would it cost you to keep up?
If the honest answers are "it waits", "hours, on a good day" and "headcount we cannot get", the rest of this paper is about you.
1. The state of the SOC: overwhelmed and under-protected
The numbers describing security operations in 2026 are not subtle. Organisations face between 4,000 and 10,000 alerts a day, and 67% are never looked at [2]. The global shortfall in security staff sits at 4.8 million people, with 59% of teams reporting critical skills gaps [3]. When a real threat slips through, the average breach now costs $4.99 million [4].
Behind the aggregate figures sits a workforce problem that surveys keep finding and organisations keep failing to fix. The most common fully-staffed SOC has between two and ten people. Typical tenure is three to five years; only 4% of staff stay past ten. 62% of SOC professionals say their organisation is not doing enough to retain its best people [5]. The work itself explains a lot of that: 69% of SOCs still lean on manual or mostly manual processes, and 42% pour incoming data into a SIEM without a plan for retrieving or managing it [5]. Tier 1 triage, the entry point of the profession, is repetitive judgment work performed under time pressure with the knowledge that most of the queue will go unexamined. People leave, and every departure takes months of context with it.
None of this is an argument that detection was the wrong investment. It worked. Internal teams now catch 52% of intrusions themselves, up from 43% a year earlier [1]. The problem is what happens next. Detection produces a queue; the queue needs judgment; and judgment is the one input the industry cannot buy in volume.
Attackers automated first
The gap would be serious even in a static threat environment. The environment is not static. AI-enabled attacks grew 56% year on year, and their involvement adds roughly $1 million to the average breach [4]. Tooling that once needed real skill now rents for about $200 a month on dark-web markets: generated spear-phishing at industrial scale, malware that rewrites its own signatures faster than threat databases update, and lateral movement that runs without an operator at the keyboard.
The speed change is easiest to see at the moment of hand-off. In 2022, when an initial-access broker sold a foothold to a ransomware crew, the transfer took a median of eight hours. By 2025 it took 22 seconds, because the second group's malware is now pre-staged during the initial infection [1]. Mean time to exploit a new vulnerability has gone negative: exploitation is observed before the patch ships [1]. Meanwhile the defender's clock runs in a different unit altogether. Median global dwell time, the period an attacker sits inside a network before being found, got worse last year, rising from 11 to 14 days [1].
That is the asymmetry in one sentence: the attacker's critical steps are measured in seconds, and the defender's are measured in days. A human-staffed response process cannot close a gap of five orders of magnitude by working harder. Machine-speed offence gets answered by machine-speed defence, or it does not get answered in time.
2. Why response resists scaling
To see why response stayed hard after detection got easy, look at what responding to a single alert actually involves. Five things happen, or should:
- Triage — is this real, or one more false positive?
- Investigation — if it is real, what is the scope? Which users, hosts and data are touched? Where did it start?
- Decision — given scope and severity, what is the right action, and is it safe to take?
- Action — isolate the host, disable the account, block the domain, remove the mailbox rule.
- Documentation — record what was found and done, in a form an auditor or a colleague can follow.
Each alert is a small, bespoke reasoning task. The evidence lives in half a dozen systems; the next question depends on the last answer; and the investigation branches. A phishing alert might resolve in four minutes as a false positive, or it might unravel into credential theft, a forwarding rule on a payroll mailbox and an attacker two hops into the estate. You do not know which until you look. That variability is exactly what makes the work resistant to the tools that scaled detection, and it is why each of the standard fixes stalls.
Fix one: hire more analysts
The direct fix fails on arithmetic before it fails on anything else. If a manual investigation takes about 20 minutes, a ten-person SOC investigates roughly 164 alerts a day; at 1,500 alerts a day that is 11% coverage. The maths of full coverage appears in the next section, and it is not a number any CFO signs. Even funded, the plan collides with a market of 4.8 million unfilled roles [3] and with turnover that drains experience as fast as recruitment adds it. Hiring is necessary. It is not sufficient, and it never catches the queue.
Fix two: outsource it
A managed provider moves the queue; it does not shrink it. The MSSP runs the same human process with the same economics, spread across many customers, and with less context about your environment than your own team has. The providers know this best of all: scaling analyst-heavy operations profitably is the defining problem of the MSSP business, not something an MSSP contract makes disappear. Outsourcing has real uses, 24/7 coverage among them. Solving the response bottleneck is not one of them.
Fix three: automate it with playbooks
Orchestration platforms promised to script the SOC, and for a class of work they deliver: enrichment, ticket handling, notification, containment steps with fixed preconditions. The limits show up where investigations live. A playbook is a decision tree written in advance, which means it encodes the paths someone already thought of. Investigations branch on evidence, and the branches that hurt are the ones nobody predicted. So playbook estates grow: a playbook per alert type, per data source, per edge case, each one an engineering artifact that breaks when an API changes and drifts out of date the week after it ships. Teams end up with an automation backlog next to their alert backlog. The field's own satisfaction data reflects this: security AI and automation tooling ranks lowest for satisfaction among SOC technologies even as interest in it stays high, and 42% of SOCs run such tools out of the box with no tailoring to their environment [5].
The pattern across all three fixes is the same. Response requires judgment; judgment was the one ingredient that could not be scripted, bought or delegated at scale. What has changed since is that judgment, of the kind Tier 1 and most Tier 2 work requires, can now be performed by machine reasoning. That claim deserves scepticism, and section 4 sets out the tests it should have to pass.
3. What the gap costs
Costs hide comfortably in security operations, so it is worth working one scenario in the open. Take a representative mid-size SOC: ten analysts, 1,500 alerts a day, about 20 minutes per manual investigation, roughly $31 of loaded analyst time consumed by each one [6]. Nothing about this SOC is unusual; the most common SOC size is smaller [5].
| The ten-analyst SOC today | What full coverage would take |
|---|---|
| ~164 alerts investigated per day (20 min each) | 1,500 alerts per day, every day, 24/7 |
| 11% alert coverage — 89% never seen | 100% coverage |
| ~40,000 alerts uninvestigated every month | ~92 analysts required |
| ~$31 of analyst time per investigation performed | ~$8.8M per year in analyst cost |
Every figure above comes from a public model you can run against your own numbers at countershadow.com/roi: your alert volume, your team size, your loaded costs [6]. We publish it precisely so the arithmetic is checkable rather than asserted.
The uninvestigated 89% is where the real exposure sits. Those 40,000 monthly alerts are mostly noise, which is exactly the trap: it only takes one that is not, and the average cost when a real threat gets through is $4.99 million [4]. An attacker inside the estate has a median of 14 days before discovery [1], ample time given that the critical attacker actions now run in seconds and minutes.
Regulation is converting slow response from an operational weakness into a reportable one. GDPR set a 72-hour breach notification clock. NIS2 tightened it for essential and important entities in Europe: an early warning within 24 hours of becoming aware of a significant incident. DORA holds financial entities to fast, structured reporting on major ICT incidents. Each regime assumes you can establish what happened quickly. An organisation that takes days to scope an incident is not late; increasingly, it is non-compliant. And the trend line makes the queue worse every year: alert volumes grow with the estate, while ransomware crews now spend their dwell time on recovery denial — destroying backups and encrypting hypervisor datastores — so the cost of the missed alert keeps rising [1].
4. What autonomous response has to deliver
If judgment can now be automated, the market will fill with claims that it has been. Some of them will be thin. This section is a set of tests: five requirements any autonomous response capability should meet before it earns a place in your SOC, and a maturity model for locating where an operation stands today. It is written to be usable against any vendor.
Requirement 1: it acts, it does not just recommend
A system that investigates an alert and hands back a well-written summary has automated the report, not the response. The threat is contained when the host is isolated, the account disabled, the rule removed — and if a human still performs every one of those steps, the human is still the bottleneck and the 3am alert still waits for morning. The test: can the system execute containment and remediation actions across your stack, under your rules, end to end?
Requirement 2: it shows its reasoning
Security teams are right to distrust verdicts they cannot inspect. Every conclusion needs a visible trail: what was queried, what came back, what was inferred, why the verdict follows. That trail is how an analyst audits a decision, how trust builds case by case, and how you satisfy an auditor asking why an action was taken. The test: for any closed investigation, can you reconstruct every step and every piece of evidence?
Requirement 3: it follows your procedures without code
Autonomy that ignores your SOPs is a liability, and autonomy that requires an engineering team to encode them is playbooks again under a new name. Operating procedures, escalation rules and compliance constraints should be expressible by the people who own them, in plain language, and the system should follow them on every investigation. The test: can a SOC lead, not a developer, change how the system behaves?
Requirement 4: autonomy is a dial, not a switch
No security leader should be forced to choose between full autonomy on day one and nothing. The system should run the full spectrum: gated approval, where it investigates and proposes while a human authorises; full autonomy for alert classes where confidence is established; different settings for different actions, since blocking a hash is not disabling a CFO's account. Trust is earned in stages, and the tooling has to support the stages. The test: can you start supervised and widen autonomy at your own pace?
Requirement 5: it runs where your data lives
Investigation means reading your most sensitive telemetry; response means holding credentials that can take action across your estate. Deployment model is therefore a security decision, not a procurement detail. Regulated, sovereign and classified environments need private-cloud, on-premise and fully air-gapped options, not a cloud-only control plane with a compliance annex. The test: can the platform, including its AI models, run entirely inside your boundary if your risk posture demands it?
A maturity model for response
| Stage | How alerts are handled | What scales | Where it breaks |
|---|---|---|---|
| 1. Manual | Analysts triage and investigate by hand across consoles | Nothing — capacity is headcount | Coverage: most of the queue is never seen |
| 2. Assisted | Enrichment, correlation and copilots speed up human work | Minutes per investigation shrink somewhat | A human still touches every alert; the bottleneck stays |
| 3. Playbook-automated | Predefined workflows handle known alert patterns end to end | The predictable, repetitive fraction of the queue | Anything novel; playbook maintenance becomes its own backlog |
| 4. Autonomous | A reasoning system investigates every alert, reaches a verdict and acts or seeks approval, per your SOPs | Coverage, speed and consistency, without added headcount | Requires the five tests above to be met — otherwise trust fails |
Most SOCs in 2026 sit between stages 1 and 2, with pockets of stage 3 where the engineering effort was affordable. The five requirements describe what a credible stage 4 has to look like. Anything sold as stage 4 that fails one of the tests is a stage 2 or 3 product with better marketing.
5. How CounterShadow closes the gap
CounterShadow builds AMI, an AI responder that performs the work described in section 2: it takes an alert, investigates it, reaches a verdict and responds — with reasoning rather than playbooks. This section follows one alert through the system and maps what happens back to the five requirements.
An alert arrives from your SIEM, EDR, cloud tooling or a custom source. AMI ingests it, extracts what matters and forms an investigation plan — there is no playbook lookup, because there are no playbooks to look up. It applies your context: the instructions, process flows and scenarios your team has defined (requirement 3, and it is done in plain language, not code). It enriches the users, hosts, IPs and hashes involved through your existing integrations, then interrogates your stack for the evidence to prove or break its working hypothesis. The loop repeats, plan revised by evidence, until AMI reaches a verdict: true or false positive, severity assessed.
What comes out the other side is a resolved incident, not a summary. Mitigation actions are executed or surfaced for one-click approval, depending on the autonomy setting you chose for that alert class (requirements 1 and 4). A full investigation report records every step, conclusion and gap; an evidence pack preserves every artifact gathered; and every query, response and reasoning step is logged to the investigation timeline (requirement 2). End to end, this takes about eight minutes, against roughly twenty for the same investigation done by hand [6].
The consequences for the worked scenario in section 3 are direct. Coverage goes to 100% of automatable alerts, around the clock: nothing waits for a shift change, and the 3am Sunday alert gets the same investigation as the 3pm Tuesday one. The 89% of the queue that was never seen gets seen. Operating cost per investigation falls to a fraction of the ~$31 manual figure — about 2.5 times lower cost overall in the modelled scenario [6] — and the ten analysts stay ten, redeployed from queue triage to threat hunting and the Tier 3 work that actually needs them, while the operation absorbs 20% annual alert growth without a hiring plan. The same model behind these figures is the public calculator cited throughout [6].
On deployment (requirement 5), the platform runs four ways: SaaS for the fastest start; private cloud, where the platform sits in your environment with CounterShadow hosting the AI; fully self-hosted, where everything including the models runs inside your boundary, suitable for air-gapped, defence and classified estates; and MSSP variants with strict per-tenant isolation and a dedicated action runner per customer. In every model, connectivity is outbound-only over SSL, with no inbound firewall rules required. Integration is broad enough that rip-and-replace is not on the table: 100+ native integrations and 1,200+ out-of-the-box actions across the security stack.
A word on why we built it this way. CounterShadow's founders, Jonathan Zulberg and Tony Massé, spent more than two decades each in security, much of it at LogRhythm and Exabeam, building the detection stack this paper credits. We watched the alerts get better and the queue get longer. AMI is the product of that frustration: the judgment layer the detection era never shipped.
Conclusion
Return to the three questions from the start. What happens to the 3am Sunday alert? In most SOCs it waits, inside a queue where two-thirds of alerts are never examined, against an adversary whose hand-offs take 22 seconds. How long from alert to containment? Manual investigation runs about twenty minutes when someone is free, and the honest answer includes the hours or days before someone is. What would 50% more volume cost? Under the manual model, headcount you cannot hire; the market is short 4.8 million people.
Detection got solved because the industry accepted that machines see better than people at scale. Response will be solved the same way, by accepting that machine reasoning can carry the routine judgment work, under human-defined rules, with human oversight where it matters. The five requirements in section 4 are the standard that acceptance should demand. Hold every vendor to them. Hold us to them.
If you want to see what the numbers look like for your own operation, the model behind this paper's scenario is public: countershadow.com/roi. Run your alert volume, your team, your costs. Then, if the gap it shows you looks familiar, talk to us.
References
- Mandiant / Google Cloud, M-Trends 2026. Global median dwell time, internal detection rates, access hand-off timing, time-to-exploit, initial infection vectors, ransomware recovery-denial tactics.
- Vectra AI, State of Threat Detection, 2023. Daily alert volumes and share of alerts never investigated.
- ISC2, Cybersecurity Workforce Study, 2024–25. Global workforce gap and skills-gap reporting.
- IBM, Cost of a Data Breach Report, 2026. Average breach cost; growth and cost impact of AI-enabled attacks.
- SANS Institute, SOC Survey 2025 (C. Crowley). SOC sizing, tenure and retention, manual process prevalence, SIEM data management, AI/ML tool adoption and satisfaction.
- CounterShadow ROI model, countershadow.com/roi. Worked scenario: 1,500 alerts/day, 20-minute manual investigations, US-loaded analyst costs. Investigation timings and cost figures derive from this model; run it with your own inputs.
© 2026 CounterShadow. This paper may be shared freely in unmodified form. Product figures reflect the modelled scenario stated above; individual results depend on environment and configuration.