How often should you get a penetration test? The short answer is at least once a year, and again after any significant change to your systems. That’s the baseline nearly every security standard and testing provider works to. Whether you need to test more often than that comes down to three things: what your compliance obligations demand, how quickly your systems change, and how sensitive your data is.

For a lot of businesses, an annual test plus testing after major changes is exactly right. For fast-moving software companies, or anyone handling particularly sensitive data, once a year on its own leaves gaps. This guide walks through how to work out the right frequency for your organisation, rather than just defaulting to “once a year and hope”.

The general rule: annually, and after significant change

The annual baseline exists because your security posture doesn’t stand still, even when your systems do. New vulnerabilities are discovered constantly, attacker techniques evolve, and a test that was accurate twelve months ago tells you very little about where you stand today. A yearly test keeps your assurance current.

The second half of the rule matters just as much, and it’s the part people forget. A penetration test is a snapshot in time. The moment you make a meaningful change to your environment, that snapshot starts to age, because you may have introduced weaknesses that weren’t there when you tested. That’s why “after significant change” sits alongside the annual cadence: the calendar catches the slow drift, and the change trigger catches the sudden shifts.

What counts as a “significant change”?

There’s no universal checklist, but the principle is simple: anything that materially alters your attack surface. In practice that usually means:

• A major application release or a significant new feature
• Infrastructure changes, such as a cloud migration or a new hosting setup
• New integrations or connections to third-party systems
• Changes to your network architecture, firewall rules or remote access
• Adding a new office, site or major system
• A merger or acquisition that brings new environments into your estate

A minor bug fix or a routine content update doesn’t warrant a fresh penetration test. A new customer-facing feature, a re-platform, or a change to how data flows through your systems almost certainly does.

What your compliance requirements say

If you’re bound by a standard or a customer requirement, that sets your floor. The most common ones line up like this:

PCI DSS is the strictest and most explicit. It requires internal and external penetration testing at least every 12 months and after any significant change, with segmentation testing at least annually (every six months for service providers). If you handle card data in scope, this isn’t optional. (See our guide to PCI DSS penetration testing requirements.)

SOC 2 doesn’t name penetration testing outright, but auditors expect it, typically annually and within your audit period. For longer Type II observation windows, they’ll want to see regular testing rather than a single test. (See our guide to what SOC 2 auditors expect.)

ISO 27001 also doesn’t mandate testing by name, but most certified organisations test annually to evidence their vulnerability management, and auditors expect to see it. (See our ISO 27001 penetration testing page.)

Cyber Essentials Plus is recertified annually, though it’s worth being clear that its technical assessment is a vulnerability scan, not a penetration test. (We explain the distinction in our Cyber Essentials Plus guide.)

Cyber insurance increasingly expects current testing, and many insurers effectively assume annual testing when they assess your risk. (See our cyber insurance penetration testing page.)

Whatever your framework says, treat it as the minimum. Compliance sets the floor, not the ceiling.

It also depends on your risk profile

Two businesses with the same compliance obligations can still need very different testing schedules, because frequency should track risk. Turn the dial up if any of these apply to you:

• You hold sensitive data, such as payment details, health records, personal data at scale, or valuable intellectual property.
• You’re heavily exposed, with public-facing applications, APIs and a lot of internet-facing infrastructure.
• You change constantly. Frequent deployments mean your attack surface shifts week to week.
• You operate in a high-threat sector, or one that attracts targeted attacks.
• You’ve been breached before. A history of incidents is a reason to test more, not less.

The more of these that describe you, the harder it is to justify testing only once a year.

When annual testing isn’t enough

For fast-moving or higher-risk organisations, the annual model has an obvious weakness: it’s a single snapshot of an environment that may change dozens of times before the next test. A SaaS company shipping code every week could introduce and expose a serious flaw two months after its annual test and not find out for another ten.

There are two ways to close that gap, and the best approach usually combines them.

The first is testing more often, whether that’s quarterly, tied to major release cycles, or through a more continuous testing arrangement for teams that ship constantly. The second, and this is essential regardless of how often you pen test, is regular vulnerability scanning in between. Scanning gives you ongoing, automated visibility of known weaknesses across your systems, catching a lot of what emerges between the deeper, human-led penetration tests. The two are complementary: scanning for continuous coverage, penetration testing for periodic depth. (We’ve explained exactly how they differ in our guide to vulnerability scanning versus penetration testing.)

Events that should always trigger a test

Whatever your regular schedule, some moments warrant a test in their own right:

• Before launching a new application or product, so you find the problems before your customers, and attackers, do.
• After any significant change, as covered above.
• Ahead of a compliance audit or certification, to fix issues before your assessor finds them.
• For a cyber insurance application or renewal, so your evidence is current.
• When a customer or partner requires it as a condition of doing business.
• After a security incident or breach, to confirm the gap is closed and check for anything else. (See our page on penetration testing after a data breach.)
• When it’s simply been over a year. If you can’t remember your last test, you’re overdue.

So, how often should you test?

Pulling it together, here’s a simple way to decide. Start with your compliance floor, whatever your framework or customers require. Then raise the frequency based on how fast you change and how sensitive your data is. Fill the gaps between deeper tests with regular vulnerability scanning, and layer in a test whenever a significant change or a key event demands one.

For most organisations, that lands on: an annual penetration test, an additional test after significant changes, and ongoing vulnerability scanning throughout the year. For fast-moving software businesses and higher-risk operations, it means testing more frequently than annually, and treating testing as a continuous discipline rather than a yearly event.