5 October 2026 · 8 min read · By Michael van Mameren, Lead Penetration Tester (OSCP)
How Often Should You Run a Penetration Test? The Cadence Each Framework Expects
Once a year is the answer most organisations give. It is the minimum, not the target. Here is what each framework actually expects, what triggers a test between cycles, and how to set a cadence that an auditor accepts and an attacker does not outrun.
The short answer
At least once every twelve months for every system that matters, plus a test after every significant change, plus a retest after every round of remediation. That is the baseline every major framework converges on. Organisations with frequent releases, regulated data or an active threat profile test more often, typically with a full annual test and lighter application tests tied to releases or quarters.
The reason annual is only the floor: the average application ships dozens of changes a year, the infrastructure underneath it changes with every cloud update, and the techniques attackers use move faster than either. A test from eleven months ago describes a system that no longer exists.
What each framework expects
The explicit or de facto cadence per framework, with the clause that sets it.
| Framework | Expected cadence | Source |
|---|---|---|
| PCI DSS v4.0.1 | Internal and external test every 12 months and after significant change; segmentation every 12 months (6 for service providers) | Requirements 11.4.2, 11.4.3, 11.4.5, 11.4.6 |
| DORA | All ICT systems supporting critical or important functions tested at least annually; TLPT every 3 years for designated entities | Articles 24, 26 |
| ISO 27001:2022 | No fixed frequency; documented risk-based cadence, annual accepted by certification bodies | A.8.8, A.8.29, clause 9.1 |
| SOC 2 | Annual by practice; test, remediation and retest inside the Type II observation period | CC4.1, CC7.1 points of focus |
| NIS2 | No fixed frequency; policies to assess effectiveness of measures, annual accepted | Article 21(2)(f) |
| HIPAA | Periodic evaluation today; proposed 2025 Security Rule sets 12 months for testing and 6 for scanning | 45 CFR 164.308(a)(8); 2025 NPRM |
| Cyber insurance | Annual test increasingly a condition of cover | Policy questionnaires |
What counts as a significant change
Every framework says test after significant change and leaves the definition to you. Write it down. These are the triggers we see most.
- A new customer-facing application, portal or API, or a major release that changes authentication, authorisation or payment flows
- Cloud migration, new cloud accounts, or a change in hosting provider
- Changes to network segmentation, VPN, remote access or identity provider
- Mergers, acquisitions or onboarding of a new third party with network or data access
- A security incident or breach, before the incident is closed
- A new compliance obligation (entering DORA or NIS2 scope, a new SOC 2 report, PCI scope change)
- Twelve months since the last test, regardless of anything else
A testing calendar that works
Three tiers, scaled to risk. Most organisations fit one of these.
Tier 1: single annual cycle
Suits organisations with a stable estate and few releases. One combined external and internal test per year, scheduled at least three months before the audit date so remediation and retest fit inside the window. Add a targeted test when a significant change lands.
Tier 2: annual plus release-driven
Suits SaaS and product companies. The annual infrastructure test stays, and each major application release gets a focused application test. Quarterly cadence is common. This is the pattern SOC 2 Type II and PCI DSS auditors like to see.
Tier 3: continuous programme
Suits regulated or high-exposure organisations: banks and insurers under DORA, healthcare, critical infrastructure under NIS2. Annual full test, quarterly application tests, continuous vulnerability scanning, a red team or TLPT every one to three years, and retests within thirty days of every remediation round.
Timing the test against the audit
The most common scheduling error is testing in the month before the audit. The report arrives with open findings, the auditor records them, and the remediation evidence is missing. Schedule the annual test three to four months before the audit date, remediate within the following month, retest, and walk into the audit with closed findings. For SOC 2 Type II, make sure the test, remediation and retest all fall inside the observation period.
How HackersHub runs recurring programmes
We agree the calendar once: the annual full test, the release-driven application tests, and a standing retest window. Scope is reviewed at each cycle rather than copied, so new systems enter the programme as they go live, and reports are mapped to every framework you report against. One lead tester owns the account, which is what makes year-over-year comparison meaningful.
Frequently asked questions
Set a cadence your auditor accepts
We build the testing calendar with you, scope each cycle fresh and keep one lead tester on your account. Talk to an expert.