How often should a business run penetration testing?
The honest answer is that annual testing is a floor imposed by procurement, not a security conclusion. Frequency should follow how fast your systems change and how much damage a breach would do.
Updated 8/8/2026 · The Tool Money Lab editorial team · Foundation · 8 min read
← Cybersecurity Learning Centre
- Three inputs set the cadence: how often systems change, how exposed they are, and what you are contractually obliged to do.
- Annual testing became the default because it matches audit cycles, not because risk resets yearly.
- Any significant architectural change — new authentication, new payment flow, new public API — is a trigger regardless of the calendar.
- Retesting after remediation is separate from the cadence and should happen every time something is fixed.
- Where change is constant, continuous testing with periodic specialist engagements beats a single larger annual test.
Why 'once a year' became the default
Annual penetration testing is an artefact of audit and procurement rhythm. Compliance evidence is collected yearly, insurance is renewed yearly, enterprise customers re-run vendor reviews yearly — so testing was scheduled to satisfy those cycles.
That reasoning is administrative, not technical. Risk does not accumulate on an annual schedule; it accumulates with every change to the systems you expose. A business that deploys twice a year and a business that deploys twice a day carry very different residual risk eleven months after a clean report, and no framework pretends otherwise.
Treat annual testing as the minimum defensible position when someone is asking for paperwork, then decide separately what your own estate actually needs.
The three inputs that set your cadence
Work through these in order. They compound: high change plus high exposure plus regulatory obligation puts you firmly in continuous territory.
- Change velocity — how often does anything internet-facing change? Weekly deployments make a yearly snapshot close to decorative.
- Exposure and consequence — what is reachable without credentials, and what would a compromise cost in data, downtime, penalties and trust?
- Obligation — what do your contracts, regulators, insurers and enterprise customers explicitly require, and in what wording?
A defensible baseline by profile
The table below is a starting point for negotiation with your own risk appetite, not a standard. Adjust upward whenever change or consequence is higher than the profile suggests.
| Profile | External testing | Scoped specialist engagement | Retesting |
|---|---|---|---|
| Small business, static website, no customer data | Continuous or quarterly scanning | Optional; on major change | After every fix |
| SaaS company shipping weekly | Continuous testing of the external surface | Annually, plus on significant architectural change | After every fix |
| Regulated SMB (payments, health, financial data) | Continuous, with documented intervals to match the framework | Annually at minimum; some regimes require more | After every fix, with records retained |
| Enterprise with internal estate and security function | Continuous external plus continuous validation internally | Multiple scoped engagements per year by system criticality | Verified and logged centrally |
Event triggers that override the calendar
Cadence answers 'how often by default'. These events mean 'test now', whatever the schedule says.
- A new authentication mechanism, single sign-on integration or change to session handling.
- A new payment flow, or any change to how card or bank data is processed or stored.
- A newly public API, customer portal or file-upload capability.
- Migration to a new cloud provider, region or hosting model.
- An acquisition or merger that adds infrastructure you did not build.
- A security incident — testing after the fact validates that the root cause is genuinely closed.
Retesting is not part of the cadence
The most common gap in an otherwise well-run programme is unverified remediation: findings reported, tickets closed, no independent confirmation that the weakness is gone rather than displaced.
Retesting should follow every fix to a significant finding, and it should leave a record. In subscription models it is typically included and therefore free to request; in project models it is billed, which is exactly why it gets skipped. Budget for it explicitly if your model does not include it.
What to do if you can only afford one test a year
Spend it where consequence concentrates rather than spreading it thin. One deep engagement against authentication, payments and the parts of your product that handle personal data is worth more than a shallow sweep of everything.
Then cover breadth cheaply: continuous vulnerability assessment of the external surface, enforced multi-factor authentication, a patching routine with an owner, and tested backups. Those four cost a fraction of a test and remove most of the commodity risk that testing would otherwise spend its time documenting.
FAQ
It is often enough to satisfy an auditor and rarely enough to reflect real risk in a business that deploys frequently. Treat it as the compliance floor and set your actual cadence from change velocity and exposure.
PCI DSS distinguishes between scanning and penetration testing, with different intervals and triggers for each. Read the current requirement wording for your validation level rather than relying on a summary.
Full engagements after every deployment are impractical. Continuous automated testing plus human cycles gives you change-responsive coverage, with scoped engagements reserved for significant architectural change.
A scoped external or application engagement is commonly one to two weeks of testing plus reporting time. Larger or internal scopes take longer, and reporting quality is worth waiting for.
Usually less often, because internal estates change more slowly and are less exposed — but the consequence of internal compromise is higher, so most mature programmes test internally at least annually or run continuous validation.
It means nothing was found within that scope, using those techniques, on that date. It is evidence of diligence, not a guarantee, and its accuracy decays with every subsequent change.
Whoever owns risk in the business, informed by security. It is a risk-appetite decision with a budget attached, not a purely technical one.
This guide is deliberately vendor-neutral. When you are ready to evaluate products, these are the TTML pages that continue the topic.
Glossary:zero trust
Our reviews are based on vendor documentation, publicly available product information, independent testing where available, and ongoing editorial updates. We do not sell rankings. Where a page carries affiliate links we may earn a commission at no additional cost to you, and that relationship never changes the conclusion — see our affiliate disclosure and review methodology.
- Last reviewed
- Reviewed by
- The Tool Money Lab Editorial Team — independent software research
- Evidence sources
- Vendor Documentation · Public Standards Documentation (PCI DSS, SOC 2, ISO/IEC 27001)
Stay Ahead of AI
Receive our weekly Intelligence Brief. Independent AI reviews, comparisons, new tools and practical recommendations delivered every Friday.
- ✓ New AI tools
- ✓ Honest reviews
- ✓ Best AI deals
- ✓ New comparisons
- ✓ Industry trends
- ✓ No spam.