How Often Should You Run a Penetration Test?
Cody D. Martin//Updated August 9, 2026
Once a year is the standard answer, and it is usually set by an audit cycle rather than by risk. The better trigger is change: a significant release, a new environment, an acquisition, or a shift in what data your application handles. Most companies should test annually and after major change.
Annual is the answer almost everyone gives, and for most companies it is close enough. It is worth understanding where the number comes from, because it comes from an audit calendar rather than from any assessment of your risk.
Where “annually” actually comes from
SOC 2, PCI DSS, ISO 27001 and most customer security questionnaires ask for evidence of testing within the last twelve months. So twelve months became the industry rhythm, and the date drifted to whenever the audit falls.
That is a compliance answer. It is not wrong, but it optimizes for having a report on file rather than for knowing whether your systems can be broken into.
The better trigger is change
An application that has not changed is unlikely to have developed new vulnerabilities. An application that shipped a new authentication flow last month almost certainly has.
Test when one of these happens:
- A significant release. New authentication, new payment handling, a new role or permission model, a rewritten API
- A new environment. A cloud migration, a new region, a second production cluster
- An acquisition. You now own systems nobody on your team designed
- A change in data. The application starts handling payment card data, health information, or CUI, and the regulatory picture changes with it
- A change in exposure. Something that was internal is now internet facing
A practical schedule
For most companies between twenty five and two hundred and fifty people:
| Scope | Frequency |
|---|---|
| External network and perimeter | Annually, plus after infrastructure change |
| Primary application | Annually, plus after significant release |
| Internal network | Annually, or every two years if segmentation is stable |
| Cloud configuration | Annually, with continuous posture monitoring between |
| Red team engagement | Once detection is mature enough to be worth testing |
If you are testing more than twice a year on the same unchanged scope, the money is probably better spent on continuous attack surface monitoring and one thorough annual test.
What continuous coverage does not replace
Attack surface management, vulnerability scanning and posture monitoring all watch for known problems appearing. They are worth running between tests and they close a real gap, since the window between your last test and your current exposure is where an attacker works.
They do not chain two low severity issues into one critical finding, reason about your business logic, or tell you which of four hundred results matters to your business. That is the part a person does.
The honest version
If a customer or an auditor is asking, test annually and keep the report. If you genuinely want to know whether you can be broken into, test after you change something significant, and accept that the calendar is a poor proxy for risk.
Most companies should do both, and the two rarely conflict, because significant change tends to happen more than once a year anyway.
- penetration testing
- SOC 2
- compliance
- security program
More on offensive