GetPentest

How often should you be penetration tested?

Annual testing is a habit rather than a rule, and for some teams it is the wrong answer in both directions. Five questions, then a twelve month calendar and the events that should pull a test forward.

Last reviewed 2026-09-14Written by Jacob Masse, TrazTech Inc.

Most teams test once a year because that is what the first customer contract said, and then never revisit it. A team shipping to production twice a day has released several hundred times between tests. A team that froze its product two years ago is buying the same report annually and learning nothing new.

This builds a calendar for the next twelve months from how you actually ship, who is asking, and what data you hold, and it lists the events that should pull a test forward regardless of the calendar. The plan appears on this page. Nothing is emailed anywhere unless you ask for it at the end.

How often do you ship to production?

Who is asking for testing?

Tick every one that applies. Each brings its own timing, and the strictest of them sets the floor.

What data does the system hold?

How much is changing architecturally in the next year?

Authentication, tenancy, payments and anything that moves where data lives. Feature work on a stable architecture does not count.

How many distinct things need testing?

A web application and the API behind it is one thing. A web application, a mobile app and a corporate network is three.

What sets the cadence

Four things, in order of how much they move the answer. Compliance drivers set a floor, because an auditor will ask for testing at a stated interval and no amount of engineering judgement changes that. Architectural change sets the real need, since a test measures a design and a design that changed has not been measured. Release frequency decides how much drift accumulates between tests. Data sensitivity decides how much that drift costs when something is missed.

Surface count multiplies the work rather than the frequency. Four systems tested annually is four engagements a year, usually spread across the calendar so the same team is not preparing for all of them in the same month.

What goes between the tests

Nobody finds a serious authorization flaw in September because a test is booked for November. The activity between engagements is what keeps the number of findings down: authenticated vulnerability scanning on a schedule, dependency and container scanning in the pipeline, and a security review of any change to authentication, tenancy or payments before it ships. That last one is cheap and catches the class of problem that testing is most expensive at finding.

If your release rate is high and the gap between tests is long, a continuous or subscription model is worth pricing. What it is and where it fits is on penetration testing as a service, and the general case is set out in how often should you pentest.

Common questions

Does any Canadian regulation state a testing interval?

PCI DSS is the explicit one: internal and external penetration testing at least annually and after any significant change, with segmentation testing on its own schedule. SOC 2 and ISO 27001 name no interval at all, which surprises people. Both ask that you have a policy, follow it, and act on what testing finds, so the interval you write down becomes the one you are audited against.

Is testing more than once a year worth the money?

It depends on what changed. A second test on an unchanged system tends to rediscover the same classes of issue. A second test after re-authentication work, a tenancy change or a cloud migration is testing something nobody has looked at. Spend on the change rather than on the calendar.

Can we alternate between surfaces instead?

Yes, and many teams do: the application every year, the internal network every second year, social engineering when there is a reason. Write the rotation down as a policy with the reasoning. An auditor accepts a risk-based rotation; what fails is a rotation invented after the question was asked.

What counts as a significant change?

Anything that alters how a user proves who they are, how one tenant is kept from another, where regulated data lives, or what sits at the edge. New screens over the same model are not significant. A new identity provider is, even when nothing visible changed for users.

Our customer asks for a report dated within twelve months. How do we plan for that?

Work backwards. The report has to be dated inside their window at the moment they ask, not at the moment you booked. Testing ten to eleven months after the last report, with two weeks for the report to be written, keeps you inside a rolling twelve month requirement without a scramble during renewal season.