How often should you run a penetration test?

Why is annual testing the wrong default?

Because the interval bears no relationship to the rate at which your attack surface changes. An application under active development receives hundreds of changes between tests, including new endpoints, new integrations, changed authorisation logic and new third party dependencies. None of that is covered by a report written eleven months ago, and the older the report the more of its value is historical.

The compliance framing reinforces the habit. Schemes such as PCI DSS require testing at least annually and additionally after significant change, and organisations reliably implement the first half of that sentence and treat the second as optional. The second half is the part that tracks risk.

There is also a quieter cost. A single large annual engagement concentrates all findings into one period, produces a backlog nobody can absorb, and creates a predictable scramble before the next assessment. Smaller, more frequent engagements aimed at what changed produce fewer findings per cycle and a remediation load a team can actually clear.

What should trigger a test?

Change to the things that decide who can reach what. Not every release qualifies, and treating every deployment as a trigger is how testing budgets get exhausted in a quarter. The triggers below are the ones where a test reliably finds something, and the right scope for each is usually narrow.

How often for a system that ships weekly?

Split the problem. Continuous automated checks in the pipeline for the classes of issue automation is good at, a targeted human test on the triggers above, and one broader engagement a year that looks at the whole system rather than the recent diff. Most organisations shipping weekly land on two to four focused engagements per year plus automation, which is less expensive than it sounds because focused tests are short.

The broader annual engagement is worth keeping even with frequent targeted testing, because incremental tests inherit the previous scope's assumptions. Someone looking at the whole application with fresh eyes finds the things that accumulated between the seams of narrow engagements, and it is also the artefact auditors, customers and insurers ask for.

Rotate suppliers or at least testers on the annual engagement. Testers develop habits, and the second test by the same person against the same system tends to retrace the first. A different pair of eyes reliably finds a different class of thing, which is a cheap way to widen coverage without widening scope.

Does continuous scanning reduce how often you test?

It changes what the human test needs to cover rather than how often you need one. If a scanner and a pipeline gate are handling known vulnerabilities in dependencies and images continuously, the annual test should not be spending its days on patch levels, and you can direct that effort at logic and authorisation. That is a real gain, and it comes from the automation raising your baseline rather than from testing less.

In container estates the more useful continuous target is freshness rather than finding counts. A commitment that nothing running in production was built from a base image older than an agreed number of days keeps the known-vulnerability layer moving without human triage, and it is measurable from your own registry and cluster. Teams that track this find their scanner backlog shrinks without anybody working through it.

What automation does not do is reduce the need for testing after a change to identity, network policy or a trust boundary. Those are exactly the areas where scanners report nothing and where a misconfiguration is both easy to introduce and immediately consequential.

What counts as a significant change?

Write your own definition and keep it short, because if you do not, an assessor will apply theirs during an assessment. A workable definition covers anything that alters authentication or authorisation, anything that adds or removes an external interface, anything that changes network segmentation, any move between hosting environments or cloud accounts, and any change to how secrets are stored or distributed.

Things that are usually not significant, despite feeling like it: front end redesigns that do not touch the API, copy and content changes, dependency updates handled by the pipeline, and internal refactoring that leaves interfaces and permissions unchanged. Being explicit about the exclusions is what makes the definition usable rather than a licence for anybody to demand a test.

Keep a decision log. When a change is judged not significant, one line recording who decided and why converts an omission into a documented control, and it is the artefact that turns a difficult audit conversation into a short one.

How do you plan a calendar that survives a budget review?

Tie each engagement to an asset and a reason rather than to a date. A line item reading annual test for the whole estate is easy to defer. A line item reading test of the customer portal authorisation model, which handles payment data and is changing in the second quarter, is defensible because deferring it has a stated consequence.

Book capacity earlier than you need it. Competent testers are commonly booked weeks out, and the practical result of late booking is either a delay or whoever is available. If your test exists partly to satisfy a deadline, work backwards from the deadline through remediation time and retest time, not just the test dates.

A test you can run this week: list every internet-facing system you own, and next to each write the date it was last tested by a human. The rows with no date, or a date more than a year old on something holding customer data, are your calendar for the next twelve months, and the exercise takes an afternoon.