Exploiting a vulnerability is now the most common first known way into a breach, at 31% of breaches, up from 20% a year earlier. That is the Verizon Data Breach Investigations Report, on more than 22,000 confirmed breaches.
Most application security testing is still annual. That is the gap this post is about, and it is a shipping problem before it is a security one: the evidence you hold is dated to a build you have already replaced, and the people who ask for it, enterprise buyers and auditors, are asking about the one you are running now.
Below: what the published data actually supports, what it does not, what the EU regulations require, and why the useful unit of testing is a series rather than a test. Every figure here is published by someone else and linked. None of them are ours, deliberately: a vendor's own number about its own engine is the weakest possible support for a claim like this one.
The backdrop, from the 2026 DBIR
31% of breaches start with vulnerability exploitation, up from 20%.
26% of known-exploited vulnerabilities are fully remediated, down from 38%.
43 days median time to patch, up from 32.
The last two are patch-management figures. They set the scene; they are not the argument for a testing interval.
Exploitation is now the most common way into a breach
Verizon's 2026 Data Breach Investigations Report is built on more than 22,000 confirmed breaches across 145 countries. In it, exploitation of vulnerabilities is the single most common first known route to initial access, at 31% of breaches, up from 20% the year before.
A good part of that shift sits with infrastructure rather than with application code, and the rest of this post is careful about the distinction. What the number establishes is narrower, and still worth having: attackers are now spending their effort on reachable software weaknesses rather than on stolen credentials. Reachability is a property of the application you ship, not of a catalogue.
That is a change in where testing effort pays off. Credential theft is answered with identity controls. Whether a weakness in your own code is reachable and exploitable is the one question a scanner cannot settle and a pentest can.
Only 26% of known-exploited vulnerabilities get fixed
In the same report, across more than 13,000 organisations, only 26% of known-exploited vulnerabilities were fully remediated, down from 38% the previous year. Median time to patch rose to 43 days from 32. Between 60% and 70% of known-exploited vulnerabilities were still open a week after disclosure.
That number measures whether a fix was applied at all, not whether it worked. It is patch management rather than pentesting, and it is here as backdrop. It is still the right place to start, because the two failure modes compound: an organisation that has not closed 74% of its known-exploited vulnerabilities is not the organisation that has verified the 26% it did close. Verification is a separate, testable claim, and the only way to settle it is to test the same finding again after the fix.
Why time-to-exploit figures are not a pentest frequency argument
It would be easy, and wrong, to reach for speed-of-exploitation figures here. They are quoted constantly and they are usually two different measurements wearing the same label.
One is a median across every vulnerability that eventually turns up in a known-exploited catalogue, measured from CVE publication to the day the catalogue records it. That number sits in the tens of days and is dominated by how quickly the catalogue found out. The other is a single observed case: Cloudflare recorded exploitation attempts against a JetBrains TeamCity flaw 22 minutes after proof-of-concept code was published. Both are true. Neither is "the time you have".
More to the point, neither is an argument for pentest cadence. When a new CVE lands in a dependency you already run, the control is patch management and dependency scanning, and it operates in hours. A pentest running monthly is not a substitute for that and we are not going to pretend otherwise. What a pentest settles is different: whether the application you actually shipped, with your business logic and your access-control decisions in it, can be made to do something it should not.
That question has no CVE and no patch. It is created by your own changes, and it is the reason the interval matters.
Why one pentest is a sample, not a census
There is a second reason, and it is less widely understood: two competent tests of the same system do not return the same answer.
Researchers at Darmstadt University of Applied Sciences commissioned two independent providers to pentest the same IT environment under matched conditions: the same four applications, the same four days of testing, both providers citing the BSI penetration testing model and the OWASP Web Security Testing Guide. Their published conclusion: "While there was some overlap, the results show that the human component has a profound impact on the outcome of a penetration test." (Roring, Sauer and Massoth, The Same, but Different: The Pentesting Study, CYBER 2021, pages 65 to 70.)
Two testers, one target, different answers. A single report is therefore evidence of what one test found on one day. It is not an inventory of what is there, and anyone selling you an annual test as a complete inventory is selling a number nobody can produce.
The variable in that study was the tester, so read strictly it argues for using more than one provider. We are not going to pretend otherwise, and we are not going to claim a series removes the variance either. Every individual run is a sample, ours included. What a series changes is narrower: each run starts from what the last one already found, so the question stops being "what does one test see" and becomes "what has this one reached that the last one did not". That is a weaker claim than convergence, and it is the one we can actually stand behind.
The useful consequence is not that testing is unreliable. It is that the useful unit of security testing is the series rather than the test, because a series that carries its previous results forward starts each run where the last one stopped instead of starting over.
Why not a bug bounty, or scanning in CI?
Both are continuous, and neither produces the same thing. A bug bounty samples continuously but on the researchers' schedule, against a scope they choose to work on, and it yields no dated artefact saying what was examined and what was not. Scanning in CI runs on every commit, which is genuinely valuable, but it settles exposure rather than exploitability: it tells you a pattern is present, not that someone can chain it into something. A scheduled pentest is the option that produces a dated, scoped, evidence-bearing result on an interval you control, which is the shape every one of the regulations below asks for. If you already run all three, the pentest is the one that produces the evidence pack.
What the CRA, NIS2 and DORA require on testing frequency
Worth being precise here, because this area attracts confident overstatement. No EU regulation currently says "run a monthly penetration test". Several say something more demanding: test regularly, justify the frequency yourself, and test again when things change.
Cyber Resilience Act. Annex I, Part II, point 3 of Regulation (EU) 2024/2847 requires manufacturers to "apply effective and regular tests and reviews of the security of the product with digital elements", across the whole support period rather than once at launch. The CRA does not name penetration testing as the method and sets no interval. It does make "regular" a legal obligation rather than a good intention. Those essential requirements apply from 11 December 2027, with the reporting obligations from 11 September 2026. The evidence you will need then is evidence you have to start producing before then.
NIS2. Article 21(2)(e) of the directive covers security in acquisition, development and maintenance. For the entities in scope of Commission Implementing Regulation (EU) 2024/2690, which include cloud providers, managed service and managed security providers, DNS providers, TLD registries, online marketplaces, social networks and trust service providers, the Annex is explicit. Point 6.5.1 requires a documented security testing policy and procedures. Point 6.5.2(a) requires entities to establish "the need, scope, frequency and type of security tests" from their risk assessment, and 6.5.2(c) requires the type, scope, time and results of each test to be documented. ENISA's technical implementation guidance goes further, advising that systems "undergo continuous testing, particularly in environments utilizing continuous integration / continuous deployment practices", with testing after significant upgrades or modifications. That sentence is guidance rather than binding text, and the distinction matters: what binds is 6.5.1 and 6.5.2, and they put the burden of justifying your frequency on you.
DORA. Regulation (EU) 2022/2554 Article 24(6) requires appropriate testing at least yearly on all ICT systems supporting critical or important functions, and Article 25(1) names penetration testing in the list of appropriate tests. Article 25(2) goes further for central securities depositories and central counterparties: vulnerability assessments before any deployment or redeployment of applications and infrastructure components supporting critical functions. The trigger there is a change, not a calendar.
So: annual is the floor DORA sets for one sector. "Regular", "risk-based" and "after significant change" is what the CRA and the NIS2 instruments require. None of them defines an interval, which means the interval is yours to set and yours to defend, and NIS2 point 6.5.2(a) says so in as many words.
How often should you run a penetration test?
There is no single correct interval and no EU regulation names one. The defensible answer is the one you can justify: DORA sets a yearly floor for critical ICT systems, the CRA requires regular testing across the whole support period, and the NIS2 implementing regulation makes you derive the frequency from your own risk assessment and document it. In practice the interval that holds up is the one that tracks your deploy rate, because what a pentest settles is created by your own changes. If you ship weekly and test yearly, you are holding evidence about a build that no longer exists.
Monthly penetration testing: what we built
If the useful unit is the series, the product should be a series. SQUR Professional runs a full pentest every month on the same application for €995 per app, half the per-pentest price of a one-time engagement. Each run is handed the findings still open from previous runs, re-tests them, and classifies every finding as new, still open, regressed or fixed. Reports refresh each run, and a run with no high or critical findings refreshes the shareable certificate.
Twelve months is €11,940 per app. If one pentest a year for the audit file is all you need, the €1,995 one-time pentest is the cheaper choice, and we would rather say so than sell you a cadence you do not need. How continuous testing works.