How often should you run a pentest?
Annual testing is the industry answer and it is a compromise between what changes in your system and what your budget tolerates. The better question is what events should trigger a test, because a system that shipped a new payment flow in March does not care that the last test was in January.
Annually, plus after any significant change. Every framework that says anything says roughly that. Buyers act on the annual half. The second half is what finds things. If you ship a new authentication flow, add a tenant model, migrate a database or acquire a company, the last test told you about a system that no longer exists.
12 months The default, and what most contracts name
6 months PCI DSS segmentation testing, service providers
$15,000 to $40,000 Typical annual testing budget, mid-size SaaS, CAD
What each framework actually requires
| Framework | Required cadence | Is a penetration test named |
|---|---|---|
| PCI DSS v4.0 | Internal and external at least every 12 months and after significant change, under 11.4.2 and 11.4.3. Segmentation testing every 12 months, or every 6 months for service providers, under 11.4.5 and 11.4.6 | Yes, and it is prescriptive about content |
| SOC 2 | Nothing stated. The Trust Services Criteria never name a penetration test or a frequency | No. Your own policy sets the cadence and the auditor tests you against it |
| ISO 27001:2022 | Nothing stated. A.8.8 covers technical vulnerability management and A.8.29 security testing in development | No. Frequency follows your risk assessment and your Statement of Applicability |
| Customer contracts | Almost always "annually by a qualified independent third party" | Usually yes, and this is the real driver for most Canadian SaaS companies |
| Cyber insurance | Rarely mandated. Asked about at application and renewal | Sometimes, and see cyber insurance and penetration testing |
Vendors imply otherwise, so: neither SOC 2 nor ISO 27001 requires an annual penetration test. What they require is that you have a policy, that the policy is reasonable for your risk, and that you follow it. Writing "annually" into your own policy and then missing it is worse than writing "every 18 months" and hitting it. The detail is on SOC 2 penetration testing and ISO 27001 penetration testing, and the one framework that does prescribe content is on PCI DSS penetration testing.
The events that should trigger a test
Write these into your testing policy as named triggers, and the annual date becomes a floor rather than the whole plan.
- A change to authentication or authorisation. New single sign-on, a new role, a tenant model change, a permissions refactor. This is where the serious findings live, and a change here invalidates the most valuable part of the previous report.
- A new external surface. A newly public API, a customer portal, a partner integration, a migration that moved something from behind the VPN to the internet.
- An acquisition. You inherited an estate nobody on your team has tested and probably cannot fully inventory. Test it before you connect it to yours, not after.
- A cloud architecture change. A new account structure, new cross-account roles, a move to Kubernetes. Permission chains are where cloud findings come from, per cloud penetration testing.
- Payment flow changes, if you handle cards. PCI DSS calls this significant change and means it.
- An incident. After remediation, to confirm the path is closed and to look for the neighbours of whatever was used.
What "significant change" means, since nobody defines it
PCI DSS leaves it to you and expects you to have written a definition down. A workable one: any change that alters the authentication or authorisation model, adds or removes a network boundary, adds a new externally reachable service, or changes where cardholder or personal data is stored or transmitted. Version bumps, copy changes and internal refactors that touch none of those are not significant. Write your definition into the policy so the argument happens once rather than at every audit.
Comparing firms for this? Tell us what you need and it goes to the ones in the directory that do this work. No charge, and no phone number required.
Cadence by what you actually are
| Profile | Cadence | Annual budget (CAD) |
|---|---|---|
| Pre-revenue startup, no customer asking | None yet. Fix the obvious things and spend the money on engineering | $0 |
| Early SaaS, first enterprise customer asking | One annual web and API test | $12,000 to $25,000 |
| SaaS, 50 to 200 staff, SOC 2 Type 2 | Annual application test, plus external network, plus a trigger test after major releases | $20,000 to $45,000 |
| SaaS shipping continuously | Annual scoped test for the artifact, continuous testing between, per pentest as a service | $35,000 to $80,000 |
| Merchant or service provider under PCI DSS | What 11.4 says, including segmentation testing every 6 months if you are a service provider | $25,000 to $70,000 |
| Regulated or public sector supplier | Annual, plus whatever the contract adds, plus internal network testing | $30,000 to $90,000 |
| Sanity check on any of these | Tester days times $1,500 to $2,800 CAD a day | |
Those figures come from tester days at Canadian rates, derived on penetration testing cost in Canada. The cost calculator prices a specific scope.
When more often is genuinely wrong
Quarterly full penetration testing is sold more than it is warranted. If your application changes materially every three months, a quarterly scoped test is defensible. If it does not, you are paying four times for the same report and the fourth tester finds what the first three found, because your team has been too busy hosting tests to fix anything.
The pattern that produces value at higher frequency is different work at different intervals, not the same engagement repeated. Continuous automated scanning weekly, developer-driven security review per release, and one deep manual engagement per year against the surface that matters. That combination costs less than quarterly manual testing and finds more. The line between those two kinds of work is on vulnerability assessment against penetration test.
The honest case for an automated scan on its own
If your entire external surface is a marketing site and a handful of hosts, nothing you run touches payment or health data, and no customer has asked for anything, a continuous vulnerability scanning service at $2,000 to $5,000 CAD a year is the correct purchase. It will find the expired certificate and the unpatched service, which are the things that get small companies compromised. Buying a $20,000 CAD manual engagement instead is not more security, it is a more expensive way to learn the same six facts. Move to manual testing when you have an authorisation model worth attacking or a customer who has asked.
Getting the date right
Two scheduling mistakes cost Canadian buyers money. The first is booking the test to finish the week the audit window closes, which leaves no time to remediate and forces you to hand your auditor a report full of open findings. Test early in the window, not at the end of it. The second is letting the retest window expire while tickets sit in a backlog, which turns an included retest into a $1,500 to $6,000 CAD invoice. The retest planner works out the dates backwards from the report.
Book four to eight weeks ahead. Good Canadian firms are not available next week, and a firm that is available next week is telling you something you should factor into the questions you ask.
Work out what to test and when
Answer six questions and get a testing plan pointed at the right surface for the reason you are actually buying.
Which test do you needCommon questions
How often should a company do penetration testing?
At least once every 12 months, and again after any change to authentication, authorisation, network boundaries or externally reachable services. The annual cadence is what contracts and frameworks name. The change-driven tests are what find things, because a report describes the system as it was on the day it was tested.
Does SOC 2 require an annual penetration test?
No. The Trust Services Criteria never name a penetration test or a frequency. What an auditor checks is that you defined a testing policy, that it is reasonable for your risk, and that you followed it. Most companies write annual into their own policy because customers ask for it, and then the auditor holds them to their own words.
How often does PCI DSS require penetration testing?
Internal and external penetration testing at least once every 12 months and after any significant change, under requirements 11.4.2 and 11.4.3. Segmentation controls must be tested at least every 12 months under 11.4.5, and every six months for service providers under 11.4.6. PCI DSS is the only common framework that prescribes both the frequency and the content.
Is quarterly penetration testing worth it?
Rarely, as the same engagement four times. It is worth it when the application genuinely changes materially each quarter, and even then the better shape is continuous automated coverage plus one deep manual test a year. Four identical manual engagements produce three reports nobody has had time to act on.
We shipped a big release. Do we need a new test?
If the release changed authentication, authorisation, the tenancy model, a network boundary, or added a new externally reachable service, yes, and a scoped test of just that change is normally two to four tester days rather than a full engagement. If it added features inside an existing authorisation model, the annual test is usually sufficient and you should note the reasoning in your testing policy.
How far in advance should we book?
Four to eight weeks for a competent Canadian firm, and longer around the end of the calendar and fiscal year when everyone is closing audit windows. Book so the report lands with at least 90 days left in your compliance window, which gives you room to remediate and to use the included retest.