How often should you run a penetration test?
The honest answer starts with "it depends", but that doesn't help you plan. The workable rule of thumb most organisations land on is simple: at least once a year, and after every significant change. Below you'll read where that rule comes from, what counts as "significant", what compliance frameworks like PCI DSS and NIS2 actually require, and when once a year is too little.
Test at least annually, plus after every significant change to your applications or infrastructure. If you process sensitive data, run public-facing applications or ship releases often, more frequent testing is wise. And after fixing findings, a retest always belongs.
Why "annually" is the baseline
A penetration test is a point-in-time snapshot. It shows how resilient your system was at the moment of testing, with the code, the configuration and the known vulnerabilities of that moment. The next day, that picture can already shift: you ship a new feature, a vendor publishes a patch, or a fresh vulnerability appears in a component you rely on. The further you get from the test date, the less the report still says about your situation today.
That's why almost everyone works with a fixed floor. A year is no magic number, but a pragmatic balance: long enough to stay affordable, short enough to avoid carrying unknown gaps for years. The UK's NCSC puts the core point plainly: if a test is your only way of validating security, vulnerabilities can sit undetected for a long time between tests. Annual is a floor, not a ceiling.
The two triggers: the calendar and the change
Frequency isn't a single number; it's two independent triggers running side by side. One on time, one on event.
The calendar
A fixed, recurring test. For most organisations that means once a year on the most important applications. It catches the slow drift: new vulnerabilities in existing systems that appeared without any code change.
The change
A test after every significant change, regardless of when the last one was. A major release or migration changes the attack surface. Waiting for the annual round means the new risk stays untested for months.
Follow only the calendar and you miss the risks that arise between two annual rounds. Test only on change and you miss the quiet ageing of systems that were never touched. The combination covers both.
What counts as a "significant change"?
This is the term people stumble over, because it's deliberately broad. A good test: does this change something about how an attacker could get in, or about what they could reach? If so, it's significant. Concrete examples:
- A new application, or an existing one that's been heavily rebuilt
- A migration to the cloud or a new hosting or infrastructure environment
- Changes to authentication or authorisation (a new login system, SSO, or roles and permissions)
- Changes to network or segmentation settings, firewalls or access rules
- New payment, data or integration links with external parties
- A major feature release that adds new functionality or new data flows
Small bug fixes and cosmetic tweaks don't count. It's about changes that grow or shift the attack surface. Not sure whether something is significant enough? Then it usually is, or it's at least worth discussing.
Not sure whether an upcoming change justifies a new test? Run it past us in a free 30-minute intake. We'll work out together what does and doesn't need testing, with no obligation.
Schedule a free intake →What the compliance frameworks say
For many organisations the frequency is partly decided by a standard or law they have to meet. The frameworks differ, but point in strikingly the same direction.
| Framework | What it requires on frequency |
|---|---|
| PCI DSS (payment card data) | An internal and an external penetration test at least every 12 months and after every significant change. Service providers must additionally validate segmentation every 6 months. |
| NIS2 / Dutch Cybersecurity Act | No fixed frequency prescribed, but the duty of care requires you to demonstrably assess the effectiveness of your measures. A recurring pentest is the standard evidence for that. |
| ISO 27001 | Prescribes no exact interval, but expects regular technical testing of vulnerabilities as part of the management system. In practice this is often filled in annually. |
The common thread: even where no exact frequency is stated, every standard expects you to be able to show that your security works and to re-check that with some regularity. More on that NIS2 requirement in our explainer on the Dutch Cybersecurity Act taking effect on 1 July 2026.
When once a year is too little
Annual is the floor, not the automatic answer. Several factors justify a higher cadence:
- Sensitive or regulated data. If you process medical data, payment data or large volumes of personal data, the impact of a breach is greater and the testing frequency should go up.
- Public-facing, critical applications. Anything permanently reachable from the internet is under constant pressure and deserves more frequent attention.
- Many fast releases. If you ship new versions weekly or daily, an annual test ages quickly. A combination of continuous checking and periodic deeper tests fits better.
- A previous incident. After a breach or near miss, a targeted test is wise to confirm the gap is closed and that no second route is open.
Organisations in these categories often choose continuous, automated monitoring or scanning between manual tests, with at least one thorough manual penetration test a year on the most important systems. Scanning catches the known and the low-hanging fruit; the manual test finds the logic and chained flaws a scanner structurally misses.
The retest is part of the deal
A question often forgotten in the frequency discussion: how often do you test after fixing findings? The answer is always. A pentest that ends with a list of vulnerabilities is only half done. Only a retest confirms that the applied fixes really close the gaps and don't introduce new ones. It's not a full new test, but a targeted verification of the earlier findings.
At Resync that retest is included with the engagement by default. So you get not just a report, but a retest statement that lets you show in black and white that the problems have been resolved. Want to see what such a report looks like? Have a look at the sample pentest report.
For most organisations this rhythm works well: one thorough manual pentest a year on the most important applications; an extra test after every significant change; continuous or periodic scanning in between; and a retest after every remediation round. If you deal with PCI DSS, sensitive data or frequent releases, dial the frequency up from that baseline.
Conclusion
"How often" is not a question with a single number as its answer, but the practice is easy to grasp. At least annually, plus after every significant change, plus a retest after remediation. If you process sensitive data or change a lot, the frequency goes up. The underlying goal is always the same: not to prove once that your security works, but to be able to demonstrate it again and again. Not sure which rhythm fits your situation? A free intake gives clarity fast.
Set the right testing cadence together.
In a free 30-minute intake we work out which systems should be tested when, matched to your risk and compliance. Fixed price, retest included.
Schedule a free intake →