Most penetration testing programs still run on the same clock they did a decade ago: once a year, scoped narrowly enough to pass an audit, then set aside until the next renewal comes due. That cadence made sense when the systems being tested didn’t change much between one round of penetration testing and the next. It doesn’t fit how fast cloud environments, APIs, and AI-integrated applications actually move today, and the gap between the old cadence and the new attack surface is now large enough to show up directly in how fast real vulnerabilities get fixed.
Cobalt’s 2026 State of Pentesting Report, drawing on five years of penetration testing data and a survey of 450 security professionals, found a 25-fold gap in how long a high-risk vulnerability survives between the best and worst penetration testing programs: a 10-day “half-life” for the top 10% versus 249 days for the bottom 10%.
Cobalt’s own description of those two groups points to where the gap comes from. The leaders treat penetration testing as a continuous program. The laggards often treat it as a one-time compliance task. A program designed around a compliance deadline and a program designed around actual risk can run a similar number of engagements a year and still produce very different outcomes.
Six findings below walk through what that cadence gap looks like in practice: how many organizations still run penetration testing only once, what the regulations that do mandate penetration testing actually require, how fast new attack surfaces are outgrowing an annual cycle, and why AI systems in particular are where the once-a-year model is failing hardest. None of this argues for running penetration testing constantly for its own sake. It argues for matching the cadence to how fast the thing being tested actually changes, which for most organizations today is faster than once a year.
Most penetration testing programs still stop at one test a year
Before looking at what more frequent penetration testing buys an organization, it’s worth establishing how rare it actually is. For a large share of companies that run a penetration test at all, the default is to run exactly one, and then not repeat it unless something forces the issue: a new client contract, a renewed insurance policy, an incident.
That default isn’t always a conscious decision. A single round of penetration testing often gets commissioned to satisfy one specific requirement, and once that requirement is met, there’s no standing budget line or calendar trigger that brings a second one back around on its own.
78% of Astra’s customers now run recurring penetration testing, but 22% still stop after one
Astra’s 2026 State of Continuous Pentesting Report, built from 6.8 million findings across more than 150,000 scans and 8,000 engagements in 2025, found 78% of its customers now run recurring penetration testing of some kind. The other 22% ran a single engagement and didn’t come back. Astra’s numbers describe its own customer base rather than the whole market, but even within a group of companies that chose a continuous testing platform, close to a quarter tested exactly once. That leaves every vulnerability introduced after that single engagement unchecked until whatever event eventually triggers a second one. For a web application or cloud environment that ships changes weekly, that single snapshot is stale within months, not years.
40% of programs are still built primarily to pass an audit, not find real risk
Frequency isn’t the only part of the gap. Cobalt’s report found that while 53% of organizations now take what it calls a programmatic approach to penetration testing (continuous, integrated into development, and driven by actual risk), 40% are still running compliance-driven programs built primarily to satisfy an auditor’s checkbox. A compliance-driven program isn’t necessarily running penetration testing less often than a programmatic one on paper, but it’s scoped to prove a control exists, not to find everything an attacker actually could.
The two approaches can produce a similar-looking line item on a compliance report and a very different security posture underneath it, and the difference often only becomes visible once something is actually found and someone has to decide how urgently it gets fixed.
The real cost of infrequent penetration testing shows up in remediation speed, not detection
It’s tempting to assume the value of frequent penetration testing is in catching more vulnerabilities. That’s part of it, but the sharper difference in the data is how fast an organization closes what it already found. A vulnerability sitting open for ten days is a very different risk than the same vulnerability sitting open for eight months, even if both organizations’ testing eventually surfaced it. The test itself is only half the exercise. What happens after the report is delivered is where the security outcome gets decided.
Programmatic teams are 4.5 times more likely to fix critical findings within three days
Cobalt tracked how often organizations resolve their critical findings within three days. Organizations running a continuous, programmatic penetration testing approach were 4.5 times more likely to hit that mark than those operating under a compliance-driven or ad hoc model. The finding itself often isn’t the bottleneck, since a round of penetration testing tends to surface the same categories of flaw regardless of how often it runs. What changes is whether a fix ships while the finding is still fresh, before the context of who owns it and why it matters has faded, and before the engineer who understood the system has moved to a different project.
Across five years of data, the best and worst programs sit 25 times apart
Across the full dataset, that difference in remediation habits shows up in the headline figure: a high-risk finding’s half-life (the point at which half of all open findings of that severity have been closed) sits at 10 days for the top 10% of penetration testing programs in Cobalt’s data and 249 days for the bottom 10%. Eight extra months of exposure, on the same class of vulnerability, is the practical difference between a program built around continuous validation and one that often treats testing as an annual deadline.
A single annual penetration test doesn’t create that gap by itself, but it structurally can’t close it either. There’s no mechanism in a once-a-year cadence for a finding to get caught, fixed, and reverified in ten days, because the next test isn’t scheduled for another eleven months, and nothing in between is checking whether the fix that was promised actually shipped.
PCI DSS already treats annual penetration testing as a floor, not a target
Not every company gets to decide its own penetration testing cadence freely. For organizations handling payment card data, the frequency is already written into a compliance standard, and it’s worth looking at what that standard actually requires, because it’s stricter than the “annual penetration test” shorthand most teams default to.
Reading the requirement correctly matters beyond the audit itself. A team that reads the schedule incompletely can end up technically non-compliant without ever realizing it.
Internal and external tests are due every 12 months, and again after any significant change
PCI DSS v4.0.1 Requirement 11.4 requires both internal (11.4.2) and external (11.4.3) penetration testing at least once every 12 months, but that’s a floor, not the whole requirement. Both tests are also due again after any significant change to the relevant infrastructure or application, which in a modern deployment pipeline can mean several retests a year on top of the annual one. A company that reads the requirement as “once a year, done” is already out of step with what the standard actually asks for.
Service providers face a six-month clock on segmentation testing specifically
Requirement 11.4.6 tightens the clock further for service providers: segmentation testing, which confirms that the cardholder data environment is actually isolated from the rest of the network, is due at least once every six months, not annually. The distinction matters because segmentation is exactly the kind of control that erodes quietly between tests, as new services, integrations, and shortcuts get added to a network without anyone revisiting whether the original isolation still holds.
A network that was cleanly segmented at the time of the annual penetration test can drift out of that state well before the next one is scheduled, which is precisely the gap the six-month clock is designed to close. PCI DSS isn’t the only regulation making a similar bet on tighter testing cycles: DORA’s threat-led penetration testing requirement for financial entities runs on its own fixed schedule against live production systems, which makes cadence a regulatory question, not just a security preference, for any EU financial firm in scope.
The attack surface is moving faster than an annual penetration test can track
Compliance requirements aside, there’s a simpler argument for running penetration testing more often: the systems being tested aren’t static, and in cloud environments specifically, they’re changing faster than most testing programs account for. A scope document written a year ago describes an environment that, in most companies, no longer exists in the same shape.
Cloud vulnerabilities grew 44 times over while cloud penetration testing grew 1.23 times
Astra’s report found cloud vulnerability volume on its platform grew 44 times over in a single year, from roughly 60,000 findings in 2024 to 2.6 million in 2025. Cloud penetration testing engagements grew just 1.23 times over the same period, which Astra calculates as vulnerability growth outpacing testing growth by 37 times.
That mismatch means the fastest-growing part of most companies’ attack surface is also the part getting the smallest share of additional scrutiny, and an annual test scoped the same way it was scoped last year simply won’t catch what changed. By the time the next annual engagement rolls around, a scope built for one cloud footprint is often testing an environment that has already been replaced underneath it.
A critical vulnerability now surfaces every 48 seconds, not every 12 minutes
The same report found a critical vulnerability was discovered somewhere in Astra’s dataset every 48 seconds in 2025, down from every 12 minutes in 2024, a roughly fifteen-fold increase in the rate critical issues are turning up. Part of that reflects Astra’s own platform growth, but the direction is hard to ignore.
Cloud also overtook the web as the primary attack surface in three separate months of 2025, even as many security budgets continued to prioritize web application penetration testing the way they did when the web was the obvious place to look. A penetration testing cadence built around last year’s attack surface is built around the wrong one, and the cost of that mismatch isn’t visible until the environment that actually matters goes untested for another twelve months.
AI and LLM systems are where the once-a-year model fails hardest
If any part of a company’s stack should be tested more than annually, it’s the part being rebuilt the fastest. For most companies in 2026, that’s whatever uses AI or large language models, and the data on how those systems hold up under penetration testing is worse than for other software across almost every measure the research tracks.
AI and LLM applications show high-risk findings at 2.7 times the overall rate
Cobalt’s report found 32% of AI and LLM findings were rated high risk, against 12% across its overall penetration testing dataset, nearly 2.7 times the rate. Some of that gap is explained by how new the discipline of AI-focused penetration testing still is. Some of it is explained by the fact that AI-integrated applications, including ones built on protocols like MCP, inherit trust assumptions that conventional vulnerability scanning was never designed to catch.
Two CVEs Fyld covered earlier this year showed exactly that pattern: a proxy vulnerability and a silent configuration bypass, both found in widely used MCP implementations, neither of which would have been caught by a scanner looking for a known signature. A team running penetration testing against that kind of system once a year is testing a category of risk that barely existed in its current form the last time anyone looked.
Only 38% of AI and LLM high-risk findings get resolved, the lowest rate of any category
Finding the vulnerability through penetration testing is only half the data point. Cobalt’s report also found AI and LLM high-risk findings get resolved at just 38%, the lowest remediation rate of any application type it tests. Cobalt attributes much of that to flaws inside the models themselves, which security teams often can’t fix directly and have to work around.
Security professionals’ own confidence in their AI systems dropped from 64% to 51% year over year even as adoption kept climbing. A category that’s producing more high-risk findings, resolving fewer of them, and changing fast enough that last year’s penetration test doesn’t describe this year’s deployment is the clearest argument against leaving AI-integrated systems on the same annual clock as everything else.
Executives and the people running penetration testing don’t agree on whether the cadence is working
Part of why the once-a-year default persists is that the people deciding the budget and the people doing the remediation work are often looking at two different pictures of how well their penetration testing program is going. Cobalt’s survey of 450 security leaders and practitioners put a number on that disconnect, and the gap is bigger than most people assume going in.
57% of executives believe their SLAs are being met. 15% of practitioners agree.
Asked whether their organization consistently meets its own remediation SLAs, 57% of C-suite respondents said yes. Among the practitioners actually doing the remediation work, only 15% agreed. That’s not a rounding gap. It’s two groups answering the same factual question and landing on almost opposite answers, which suggests the executives setting penetration testing budgets and cadence may be working from a picture of program performance that the people closest to the work don’t recognize.
77% of practitioners report struggling to hit remediation SLAs, against 37% of executives
The same pattern shows up from the other direction: 77% of practitioners described meeting their organization’s remediation SLAs as a genuine struggle, against just 37% of executives. A program that looks adequately resourced from the boardroom can look understaffed and permanently behind from inside the team actually closing findings. A once-a-year penetration testing cadence makes that gap easier to miss, because there’s no monthly or quarterly data point forcing the two pictures back into alignment.
The cost of that disconnect eventually shows up elsewhere. IBM’s 2026 Cost of a Data Breach Report put the average breach lifecycle, the time to identify and contain a breach, at 247 days, and found that breaches running past 200 days cost an average of $5.65 million against $4.32 million for those closed faster. Speed, in other words, is a cost line, and it’s the same speed a 10-day remediation half-life is built to deliver.
What this means for teams planning penetration testing cadence
None of the six findings above argue that every organization needs to run penetration testing continuously starting tomorrow. They argue that “once a year” has stopped being a neutral default and become an active choice to leave a measurable gap in place: a 25-fold difference in how long a high-risk finding survives between the best and worst programs, cloud vulnerabilities growing 37 times faster than the testing pointed at them, and an AI-integrated stack that’s both riskier and slower to fix than everything else in the environment.
Cyber insurance underwriters are paying attention too. A majority of carriers now require or strongly recommend an annual third-party penetration test for policies above $1 million in coverage, and some are starting to distinguish between point-in-time annual testing and continuous programs when they assess risk. The “once a year, minimum” cadence many companies treat as sufficient is increasingly the floor, not the standard.
The practical starting point isn’t a wholesale switch to continuous penetration testing. It’s matching cadence to the two things that change fastest: whatever’s covered by a specific compliance deadline, whether that’s PCI DSS’s 12-month and 6-month clocks or a sector-specific requirement like DORA’s, and whatever’s being rebuilt often enough that last quarter’s penetration test no longer describes what’s actually deployed, which for most companies today means the cloud environment and the AI-integrated features inside it.
Getting that match right doesn’t require abandoning annual penetration testing entirely. It requires treating it as the floor for the slowest-moving parts of the environment, not the ceiling for all of it. Talk to Fyld about where your own penetration testing cadence has the widest gap between how often you test and how often the thing you’re testing actually changes.
