Once a Year Is Not Enough: How Often Should You Actually Run a Penetration test?

Annual penetration testing made sense in a different era. Infrastructure changed slowly. Applications had quarterly release cycles at best. The attack surface was mostly on-premises and well-defined. Running a pentest once a year gave organizations a reasonable snapshot of their security posture because that posture did not change dramatically between tests.

That era is over.

Today, the average company ships code weekly. Cloud infrastructure is provisioned and modified continuously. SaaS integrations are added by individual teams without central oversight. Third-party APIs connect to core systems. Employees change roles, leave, and join. Each of these events can introduce new vulnerabilities, and in most organizations, those vulnerabilities sit undiscovered until the next scheduled test arrives.

The annual pentest has not kept pace with the speed at which organizations now change. This article examines why the annual default persists, what it misses, and how to build a testing cadence that reflects how your organization actually operates.

Why the Annual Pentest Became the Industry Default

The annual cadence did not emerge from a careful analysis of risk. It emerged from compliance frameworks and cost constraints.

PCI DSS requires penetration testing at least annually and after any significant change to the environment. ISO 27001 does not specify a fixed frequency but requires testing as part of a broader vulnerability management program. SOC 2 auditors look for evidence of regular testing without mandating a specific interval. In the absence of more precise guidance, organizations defaulted to the minimum: once a year, timed to coincide with the compliance audit cycle.

Cost reinforced this pattern. A comprehensive penetration test is a significant investment. Conducting one annually feels manageable. Conducting one quarterly feels expensive. Conducting one continuously feels prohibitive, at least under the traditional engagement model where each test requires scoping, contracting, and scheduling from scratch.

The third factor is awareness. Many organizations running annual pentests have not stopped to ask whether that frequency matches their actual risk profile. The test happens, the report arrives, remediation occurs on some findings, and the cycle repeats the following year. It feels like a security program. In many cases, it is a compliance exercise.

What Changes Between Pentests That Creates New Risk

The gap between annual tests is not a stable period. It is a window during which the organization continues to change in ways that directly affect its attack surface.

New product features introduce new code. A web application that was tested in January looks different in October after two major releases and a dozen minor updates. Authentication flows change. New endpoints are added. Third-party components are updated or replaced. None of these changes are reflected in the January test results.

Cloud infrastructure changes faster than most organizations track. A new S3 bucket is created and misconfigured. A developer opens a port for testing and forgets to close it. A Terraform module is reused from a previous project without reviewing its security settings. Cloud environments are dynamic by design, and that dynamism creates continuous configuration drift.

Team changes carry security implications that are rarely treated as security events. A developer who held administrative access to a production environment leaves the company. The access is not revoked promptly. A new engineer joins and is given broad permissions to get started quickly. A contractor is brought in for a specific project and connected to internal systems with credentials that are never rotated after the engagement ends.

Third-party integrations are added constantly and rarely audited. A marketing team connects a new analytics tool to the company's data warehouse. A sales team installs a browser extension that touches CRM data. A finance team adopts a new payment processing integration. Each connection extends the attack surface in ways that are invisible to a pentest conducted six months earlier.

The 2025 Verizon Data Breach Investigations Report highlights that many breaches exploit vulnerabilities soon after they are disclosed, sometimes within days or weeks. If your testing schedule is six or twelve months, that leaves a long window of exposure.

The Numbers Behind the Gap

The scale of the problem becomes clear when testing frequency is set against the pace of vulnerability discovery.

In 2025, 131 new vulnerabilities are being discovered daily, representing a 16% increase from 2024's already record-breaking numbers. That is roughly 47,000 new CVEs per year. An organization that tests once annually is validating its security posture against a threat landscape that has added tens of thousands of new entries since the last test was completed.

Approximately 32% of companies conduct pentests only annually or biannually, leaving extended security gaps between assessments. Meanwhile, 67% of U.S. enterprises experienced a breach in the previous 24 months despite large security stacks and existing security measures.

The relationship between these numbers is not coincidental. Organizations that test infrequently are validating a static picture of a dynamic environment. The picture is accurate on the day it is taken and increasingly unreliable from that point forward.

Organizations using proactive testing programs saved an average of $1.9 million per breach and shortened their breach lifecycle by 80 days. The financial case for increased testing frequency is not theoretical. It is measurable.

Triggers for an Unscheduled Pentest

Regardless of the baseline testing cadence a company adopts, certain events should trigger an additional assessment outside the regular schedule.

A major product release represents a significant change to the attack surface. If a new feature involves authentication, payment processing, data storage, or external API connections, it should be tested before or immediately after release, not at the next annual cycle.

Infrastructure migration changes the environment in ways that can invalidate previous test findings entirely. Moving from on-premises to cloud, changing hosting providers, adopting a new networking architecture, or implementing a new identity provider all create conditions that require fresh validation.

Mergers and acquisitions introduce a new network, new applications, new users, and new third-party relationships. Acquired companies may carry vulnerabilities that were unknown before the transaction closed. A post-acquisition pentest is not optional: it is how a company understands what it has taken on.

A new compliance requirement may specify testing that goes beyond the organization's current program. DORA, for example, requires financial entities and their critical ICT providers to conduct advanced threat-led penetration testing. Meeting this requirement on an annual pentest schedule may not satisfy the standard's intent.

A security incident, even one that appears contained, warrants a fresh assessment. An incident reveals that an attacker was present in the environment. It does not necessarily reveal everything the attacker accessed, modified, or left behind. A post-incident pentest helps confirm that the breach was fully remediated and that no persistence mechanisms remain.

Frequency by Company Type

There is no universal answer to how often a company should test. The right cadence depends on the organization's risk profile, rate of change, and regulatory obligations. The following framework reflects industry practice and risk-based reasoning.

Pre-launch startups should conduct a pentest before releasing a product to customers, particularly if the product handles user data, payment information, or integrates with third-party services. This is not about compliance. It is about not shipping a product with exploitable vulnerabilities that will be discovered by someone other than your own security team.

Growth-stage SaaS companies shipping code frequently and onboarding new enterprise customers should test at least twice per year, with additional testing triggered by major releases or significant infrastructure changes. Enterprise customers increasingly request recent pentest reports as part of vendor due diligence, and a 12-month-old report often does not satisfy that request.

Regulated industries including financial services, healthcare, and critical infrastructure face sector-specific requirements that typically imply more frequent testing. For organizations subject to PCI DSS, testing after any significant environment change is mandatory in addition to the annual minimum. For organizations subject to DORA, threat-led penetration testing requirements go beyond what a standard annual pentest delivers. Quarterly testing is a reasonable baseline for most regulated environments.

Enterprises with complex, multi-system environments, large teams, and continuous deployment pipelines should consider continuous or near-continuous testing models. The attack surface is too large and changes too frequently for periodic point-in-time assessments to provide meaningful assurance.

---

Building a Testing Program That Reflects How You Actually Operate

Security testing is most effective when it aligns with how your organization develops, deploys, and changes its environment over time — not just with minimum compliance requirements.

ESKA Security provides penetration testing programs designed for organizations that need ongoing visibility into their security posture as infrastructure, applications, and business processes evolve.

For companies with frequent releases, expanding cloud environments, growing external attack surfaces, or increasing regulatory obligations, periodic testing often leaves long gaps in visibility. A structured testing program helps identify issues earlier, validate remediation continuously, and adapt assessments to changes in the environment throughout the year.

Many organizations still rely on testing schedules originally defined by compliance frameworks rather than by operational reality. If your infrastructure, applications, or exposure change faster than your assessment cycle, it may be time to reassess whether your current approach provides sufficient coverage.

Contact ESKA Security to discuss what a penetration testing program tailored to your environment, release cycle, and risk profile could look like.