133 New Vulnerabilities a Day: Why Your Annual Pen Test Is Already Out of Date

When your team hired a firm to run a penetration test last spring, testers spent several days trying to break into your network the way a real attacker would. At the end of the engagement, they handed you a report describing exactly what they found. That report was accurate. It just didn't stay accurate for very long.

Here's why. Security researchers around the world discover roughly 133 new vulnerabilities every single day, on average, and publish them so other organizations can check whether they're affected. A vulnerability, in this context, simply means a flaw somewhere in a piece of software, a mistake in the underlying code, or a setting left in the wrong position, that someone could exploit to gain access they shouldn't have. Multiply 133 by the days in a year, and you start to see how much the threat landscape can shift between one annual test and the next. Your systems probably haven't changed much. The list of ways to attack them almost certainly has.

That number comes from the CVE program, short for Common Vulnerabilities and Exposures, the industry's shared catalog of known software flaws: when a researcher or vendor discovers a new one, it gets a CVE number and gets added to the list. In 2025, that catalog grew by 48,185 entries, a 20.6% increase over 2024, and the number added each year has grown 263% since 2020, according to NIST, the National Institute of Standards and Technology. Close to 40% of last year's entries were rated high or critical severity. None of this is a projection. It already happened.

The compliance minimum was never built to match your risk

Most regulated organizations run a penetration test once a year, and the honest reason is rarely that someone calculated the right amount of testing. It's that a regulation requires it: PCI DSS for companies handling card payments, CMMC for defense contractors, an NCUA examiner's expectations for credit unions, HIPAA's vaguer call for “regular” testing in healthcare, which quietly became “once a year” by default. None of these requirements are unreasonable, and testing once a year beats not testing at all. But they were written as a floor every organization could realistically meet, not a measurement of what any one organization needs. A regulator writing a rule for thousands of companies at once has to pick a number simple enough to apply to all of them. That number has nothing to do with how fast new vulnerabilities are showing up in the specific software you run.

Think of a penetration test as a photograph rather than an ongoing guarantee. It's completely accurate, but only for the moment it was taken. A test run in April tells you what your defenses looked like in April, and says almost nothing about the months that follow, months in which tens of thousands of new vulnerabilities get published, some of which will apply directly to your systems. Treating that one photograph as proof your defenses are still solid a year later is a bit like checking the weather once in January and packing for the whole year based on it.

Even the government's own tracking system is struggling to keep up. The National Vulnerability Database, or NVD, only completed full analysis on 28% of everything disclosed in 2025, a sharp drop from the year before, simply because the volume outran what the agency could process. In early 2026, NIST responded by triaging: it now fully scores only the 15 to 20% of incoming vulnerabilities tied to active exploitation, federal software, or a short list of high-priority categories, and logs everything else with minimal detail. If a federal agency built for this can't keep pace, an internal IT (information technology) team running one test a year has little chance of doing it manually.

Why scanning more often isn't the full answer

A reasonable first reaction is to assume the fix is running automated vulnerability scans more often. These tools are genuinely useful, checking your systems against a database of known issues and flagging matches, and running them more frequently does close part of the gap.

But automated scanning has a real limitation. It's good at recognizing known problems in known software, essentially checking whether a door has been left unlocked. It's considerably worse at finding the kind of layered weaknesses an experienced human tester notices, a permissions setting that's slightly too generous, an authentication flow left a little too open, two minor issues that mean nothing alone but together open a real path into the network. That's exactly the gap a fully automated “AI does everything” pen testing product hasn't closed, whatever the marketing claims, and those claims have gotten louder over the past year.

“Auditors, cyber insurers, and CISOs want a human on the hook for findings, not a black-box scanner with a slick interface,” said Gary Simat, CEO of RedZone Technologies, when Passpoint Security's AI Verified PTaaS was named a 2026 MSP Today Product of the Year. Simat added that the model was built on a different premise: “Experienced human testers, augmented by AI that expands what they can cover and how fast they can analyze it, delivered inside our Virtual Security Operations program where every finding is owned and acted on.”

That's the real distinction behind AI Verified PTaaS. The AI isn't doing the tester's job. It's widening how much ground one experienced tester can cover, and how fast they can make sense of what they find, so a team that used to justify one test a year can realistically test continuously instead, without hiring an internal red team. That continuous, subscription-based model has its own name: PTaaS, short for Penetration Testing as a Service.

What continuous testing changes

Strip away the marketing language and the real advantage comes down to timing. Roughly 70% of breaches trace back to a failure somewhere in vulnerability management, not an unknown, unpatchable flaw nobody could have predicted. Most of the time, the vulnerability was already public. Somebody just hadn't found it, prioritized it, or fixed it before an attacker did. Testing continuously instead of annually shrinks that window, and that window is exactly what an opportunistic attacker is counting on.

There's a budget argument too. Continuous, subscription-based testing is usually billed as an operating expense, a steady monthly cost, rather than a capital expense paid once a year. For an IT director defending a security budget to a CFO (chief financial officer) every cycle, a predictable monthly number is an easier conversation than a lump sum and a hope that nothing changes before the next renewal.

What to do with this

Most organizations never consciously chose their current testing schedule. Trace it back far enough and it's usually whatever frequency an auditor mentioned years ago, never revisited since. That's worth a second look, not because the requirement was wrong, but because it was never built to answer the question that matters: how fast is your environment changing, and does your testing schedule keep pace? A regulator's minimum has to work across thousands of companies it will never examine closely. Your environment changes every day whether anyone's watching or not.

A simple way to check: pull the CVEs published in the last year, see how many touched software you actually run, then ask honestly whether your last pen test would have caught the ones that mattered. If you're not sure, that's the answer. It's not a testing problem. It's a timing problem, and the fastest way to find out where you stand is a current security posture snapshot rather than waiting for next year's scheduled test.

If that sounds like where your organization is right now, talk to RedZone about AI Verified PTaaS and what a continuous testing model would look like for your environment.

FAQ

How often should a regulated organization run a penetration test?

There's no single number that fits every organization, but it helps to understand that whatever your compliance framework requires is a legal minimum, not a measurement of your actual risk. Vulnerability disclosures have grown 263% since 2020 and now average around 133 new entries a day, so an organization whose technology environment changes throughout the year, which describes nearly every organization, is generally better served by testing continuously or quarterly rather than relying on a single test scheduled twelve months apart.

What's the difference between a traditional pen test and PTaaS?

A traditional penetration test is a single, scheduled project, usually happening once a year, that produces one report describing your security at that specific moment in time. PTaaS, short for Penetration Testing as a Service, works differently: testing happens continuously through an ongoing subscription, so new findings reach you as they're discovered throughout the year rather than arriving all at once in a single annual document. This approach also tends to change how the service gets paid for, shifting the cost from one large upfront expense to a smaller, predictable monthly fee.

Is AI-verified penetration testing the same as fully automated AI scanning?

No, and the difference matters quite a bit. A fully automated AI scanner runs entirely on its own, with no human reviewing or interpreting what it finds. AI Verified PTaaS, which is how Passpoint Security delivers this service, uses artificial intelligence differently: it helps an experienced human tester cover more ground and analyze results faster, but a real person still reviews and takes ownership of every finding before it reaches you, someone capable of explaining that finding to an auditor or an insurance company if they have follow-up questions.

Why did so many more vulnerabilities get published in 2025 than in past years?

There are two main reasons behind the increase, and both are worth understanding. First, the number of ways attackers can target modern technology has genuinely expanded, as organizations adopt more cloud services, more connected devices, and more complex software than they used to. Second, more organizations have become what's called a CVE Numbering Authority, meaning they've been officially authorized to assign new CVE identifiers themselves, which has led to more thorough and consistent reporting industry-wide. Whatever the exact mix of these two causes, the practical result for a security team is the same: there's simply more to track and prioritize than there used to be.

What percentage of breaches are caused by vulnerabilities that testing should have caught?

Roughly 70% of data breaches can be traced back to a failure somewhere in an organization's vulnerability management process, meaning the flaw that ultimately got exploited wasn't some undiscoverable mystery. In most of these cases, the vulnerability had already been publicly disclosed well before the breach occurred. It simply hadn't been found by the affected organization, hadn't been treated as urgent, or hadn't been fixed in time.

Does a more frequent testing cadence cost more overall?

Not necessarily, and this is often a pleasant surprise for organizations weighing the switch. Continuous testing delivered through a subscription is typically priced to compete with what a full year of traditional, periodic testing would already cost. The real difference is in how that cost gets structured: instead of one large invoice once a year, you pay a smaller, predictable amount every month, which most budgets are built to accommodate more easily.