How Often Should You Run a Penetration Test?

Annual penetration testing became the default because compliance frameworks needed a frequency to specify. It was not derived from an analysis of how quickly environments change, how frequently new vulnerability classes emerge, or how long an attacker needs to move through an environment once they have found a way in. For a static environment facing a low-sophistication threat, annual testing may be sufficient. Most organisations are neither of those things.

The question of how often to run a penetration test is really a question about how much residual risk you are comfortable carrying between test cycles. A penetration test is a snapshot. It tells you what was exploitable on the day the test was conducted, under the conditions that existed at that time. Everything that changes after that snapshot -- new deployments, new configurations, new vulnerability disclosures, new attack techniques -- is outside the frame. The right testing frequency is the one that keeps the gap between the snapshot and the current environment within your risk tolerance.

Factors That Increase the Required Frequency

Several characteristics of your environment and risk profile increase the rate at which your last test becomes stale:

• High rate of change -- organisations that deploy new applications, modify existing architectures, or migrate to new infrastructure platforms frequently are generating new attack surface faster than annual testing can track.
• Internet-facing services -- the more services you expose directly to the internet, the more frequently you should verify that those services hold up under active testing conditions.
• Regulated sector -- financial services, healthcare, and critical infrastructure organisations face higher-sophistication threats and carry greater consequences from a breach, both to their customers and under applicable regulatory frameworks.
• Customer-facing applications that handle sensitive data -- applications that process payment card data, health records, or government credentials represent targets that attract motivated attackers with specific objectives.
• Significant vendor or supply chain exposure -- organisations with large third-party integrations face attack paths that originate outside their direct control and change as vendor platforms evolve.

For organisations with most of these characteristics, quarterly testing of critical applications alongside annual testing of the broader environment is a reasonable target. Threat-led or continuous testing programmes can provide higher coverage for organisations with the internal capacity to act on findings continuously.

The Change-Triggered Testing Model

A more useful mental model than calendar-based frequency is change-triggered testing. Under this approach, testing is scheduled at a baseline frequency -- typically annual for the broader environment -- and additional testing is triggered by specific events:

• A new application is moved to production
• An existing application receives a significant feature addition or architectural change
• A new authentication or authorisation mechanism is implemented
• A migration to a new hosting environment or cloud platform is completed
• A new third-party integration is added to a production system
• A significant vulnerability is disclosed that affects software in use across the environment

Change-triggered testing is not necessarily more expensive than purely calendar-based testing. A scoped test of a specific new application costs less than a broad annual assessment and is more likely to find the specific weaknesses introduced by that application. The total annual spend may be similar, but it is distributed more precisely across the points of highest risk.

What Your Compliance Framework Requires

If you operate under a compliance framework that specifies testing frequency, that framework sets a floor, not a ceiling. The Essential Eight maturity model at Level 2 and above requires that penetration testing be conducted in line with the rate of change in the environment. APRA CPS 234 requires that testing frequency be commensurate with the criticality of assets and the nature of threats. Neither framework says annual testing is sufficient -- both imply it is the minimum for a stable, low-criticality environment.

PCI DSS, which is relevant for organisations handling payment card data, requires annual penetration testing of the cardholder data environment and testing after any significant infrastructure or application changes. ISO 27001 does not mandate a specific frequency but requires that the organisation's testing programme be proportionate to risk, which auditors will interpret in light of the organisation's change rate and threat exposure.

Making the Decision

The right testing frequency for your organisation is a business decision, not a technical one. It should be made with input from the people who understand your environment's rate of change, your regulatory obligations, and your risk appetite. What it should not be is a default inherited from a compliance framework that was designed for the minimum case.

A practical starting point for most organisations is to define a baseline annual schedule for the broader environment, identify the three to five highest-risk applications or systems that warrant quarterly or change-triggered testing, and build a lightweight process for triggering additional tests when significant changes occur. That framework covers most situations without requiring a security team to make a fresh decision every time something new is deployed.

To discuss how often your organisation should be running penetration tests, contact Cyberlinx at info@cyberlinx.com.au.