What a Security Team Does When the Backlog Is Gone

Every conversation about autonomous defense eventually stops being about the technology and starts being about the people.

Final post in a series on the throughput gap.

There is a moment that happens a few weeks into every deployment, and it is not the one I expected.

The team watches the backlog collapse. Millions of findings investigated, the false positives gone, the real risk closed. The number that defined their working life for years stops being the number that defines their working life. And then somebody asks the question quietly, usually offline: so what do we do now?

I want to answer that seriously, because the flippant answer - “strategic work” - is exactly the kind of thing vendors say when they have not thought about it.

The fear underneath the question

Let me name it plainly. When you tell a security team that machines will now execute the work they have been doing, some of them hear a headcount conversation. That is a reasonable thing to hear. It would be dishonest to pretend otherwise, and it would be worse to answer it with a slogan.

So here is the honest version.

A skilled analyst can thoroughly investigate 10 to 20 vulnerabilities a day. That is not a comment on the analyst. It is arithmetic, and it has been the constraint on this profession for its entire existence. The consequence is that most security professionals have spent most of their careers doing work that is beneath their training - reconciling scanner outputs, chasing asset owners, confirming that a finding is real, re-explaining the same risk to the same team. Seventy-seven percent of the CISOs we surveyed this year said vulnerability management contributes at least moderately to burnout.

That work is not the profession. It is the tax the profession has been paying because there was no other way to manufacture certainty.

Removing human execution from the remediation loop does not remove the human from security. It removes the part of the job that never should have required one.

What actually changes

Three things, from what we have watched happen.

The unit of work gets bigger. When your team's throughput is 20 findings a day, your planning horizon is the queue. When throughput is not the constraint, you can ask questions you could never afford to ask before: why does this class of vulnerability keep appearing, which parts of the estate generate disproportionate risk, what would it take to make an entire category of finding impossible rather than merely handled. That is engineering work, and it is what most security leaders thought they were signing up for.

Coverage stops being a rationing decision. One customer improved asset classification and ownership identification from 17% to 93% across 150,000 assets in under six hours, and surfaced 30,000 shadow IT and OT assets nobody had accounted for. Nobody had chosen not to know about those assets. There was simply never enough capacity to go find them. Capacity constraints produce blind spots that look like decisions in hindsight, and they are not.

The team moves from executing to governing. This is the substantive shift, and it is the one worth designing for deliberately. Someone has to decide what the machine is authorized to do, where the boundary between autonomous action and human review sits, which risks the business is willing to carry and which it is not. Those are judgment calls with real consequences, and they are exactly what a senior practitioner is good at and has almost never had time to do properly.

Our CISO, Alfredo Hickman, put it better than I have: security teams can no longer be the sole execution engine of cybersecurity. They should be the strategic control plane. I would add one thing to that. A control plane is not a lighter job. It is a harder one, and it requires people who understand the systems deeply enough to set the rules. The expertise does not become less valuable. It gets pointed at something worth its cost.

The uncomfortable part

I do not want to make this sound frictionless, because it isn't.

Fifty-two percent of the security leaders we surveyed named lack of trust in automated decisions as their biggest barrier to adopting autonomous remediation. Only 32% permit automated remediation actions today. Thirty-five percent describe their vulnerability management as mostly or primarily machine-led, and they expect that to reach 45% within 18 months.

That is a real distribution and it is moving, but it is moving at the speed organizations change, not the speed technology changes. Which means the gap between the teams that make this shift early and the teams that make it under duress is going to be wide, and the second group will make the transition in the middle of an incident, with worse options and less room to design it well.

Capability that nobody deploys protects nobody. An attacker does not have to onboard a hospital. A defender does.

Why I think this is the right side of it

I have been on the other side of an argument like this before.

When we built Claroty, the objection was that IT and OT could not be unified - different teams, different priorities, different definitions of risk, and a cultural gap that people described as unbridgeable. It was bridged. Not because anyone was persuaded by an argument, but because the threat stopped respecting the boundary and the organizations that reorganized around that fact did better than the ones that didn't.

This is the same shape. The line between what humans execute and what machines execute is being redrawn, and it is being redrawn by attackers who already stopped respecting it. Every organization gets to choose whether it redraws that line deliberately, with its own people designing the boundary, or has it redrawn for them.

The teams doing this well are not the ones with the biggest budgets. They are the ones that decided early that their people were too valuable to spend on triage, and built the operating model to match.

The goal has always been zero. What I did not fully appreciate when we started is that reaching zero is not the end of the story for a security team. It is the beginning of the part where they finally get to do the work they were hired for.

And we're just getting started.