72 minutes to stolen data.Then the fix takes months.

This is not a piece about testing too rarely. It is a piece about two clocks running at different speeds, and about which one you can actually do something about.

Verizon publishes one of the industry's most cited annual studies of real data breaches. In the 2026 edition they find that nearly a third, 31 percent, of all breaches begin with someone exploiting a known security flaw. It is the first time in the report's nineteen years that this route has passed stolen credentials.[01]

Mandiant, which investigates breaches on behalf of affected companies, sees the same thing. Exploited vulnerabilities account for 32 percent of intrusions, and have been the most common way in six years running.[02]

A breach today is rarely one person at a keyboard. It is a chain of specialised groups selling access to each other, and that chain has become extremely fast.

Palo Alto Networks investigated over 750 major incidents across more than 50 countries during 2025. In the fastest quarter of cases it took 72 minutes from someone getting in until data was on its way out of the organisation. That is four times faster than the year before.[03]

And the road there is automated. When a serious flaw in the development tool TeamCity was disclosed in 2024, a security firm published a working demonstration of how it could be exploited. Cloudflare saw the first real attack attempt 22 minutes later.[04]

Sometimes the clock starts before the flaw is even known. GreyNoise, which measures scanning traffic across the internet, showed in 2025 that when attacker activity against a given product suddenly rises, a newly published vulnerability in that same product follows within six weeks in 80 percent of cases. The activity came first.[05]

Against 22 seconds and 72 minutes stand numbers in a completely different unit. A review of real environments found the fastest sector, software, needed 63 days on average to fix a flaw. The slowest, construction, needed 104. Larger organisations still had 45.4 percent of everything they had found unfixed after twelve months.[06]

Do not overdraw the conclusion. Fixing takes time for good reasons. The change has to be tested so it does not break something else, it has to go out in a release, and sometimes you are waiting for a supplier to fix their own product first. No security test shortens that.

In November 2025 the AI vendor Anthropic published an account of what it assesses to be the first espionage campaign where an AI did most of the work. Around 30 targets globally, 80 to 90 percent of the work carried out by the AI, and only four to six moments where a human had to make a decision. At its fastest it was sending thousands of requests, often several per second.[07]

That does not change which flaws exist in your application. It changes how long you have before somebody else finds them.

The honest conclusion is not that you should test more often because it sounds sensible. It is that what a test costs decides how often you can afford one, and cost is the only thing in this entire piece that is an engineering question.

A fully manual engagement taking weeks is something most organisations can afford once a year. If the same depth can be delivered in days, frequency becomes a budget question rather than a calendar question. That is why we build the way we do. The AI supplies breadth and tempo, the pentester supplies direction and accountability, and the price is set on how large the engagement is rather than on hours.