How Often Should You Pentest? Frequencies by System and Rule

The baseline is one penetration test per year and one after every significant change. That cadence satisfies PCI DSS, most customer contracts, ISO 27001 auditors and the effectiveness checks under NIS2. Where you should test more often is decided by three things: how exposed the system is, how often it changes, and what a successful attack would cost. Where you can test less often: systems that are internal, stable and not worth much to an attacker.

Here is how that works out per system and per rule.

Recommended frequency by system

System	Baseline	Additional trigger	Why
Internet-facing web application with accounts or payments	Yearly	Every major release; change of identity provider or payment flow	Highest exposure, logic changes with every release
API used by partners or apps	Yearly	New versions, new consumers	Authorisation bugs are version-specific
Mobile app	Per major release, at least yearly	New platform version, new backend	App and backend change together
Cloud tenant	Yearly	IAM changes, new accounts or subscriptions, migration	Misconfigurations appear with every new service
External infrastructure	Yearly	New public services, new locations	Cheap and fast, 2 to 5 days
Internal network and Active Directory	Every 1 to 2 years	Mergers, domain changes, new remote access	Changes slowly, but one finding is usually critical
IoT product	Before launch, then yearly during support	Every major firmware release, new cloud backend, new radio	CRA Annex I Part II requires regular tests
Automotive ECU	Per start of production and major software release	New variant, new diagnostic functions, new connectivity	Type approval and ISO/SAE 21434 validation
OT and plant segment	Full assessment every 2 to 3 years	New remote access, new machine, segmentation change	Yearly architecture review in between; see OT pentest without downtime

The regulatory minimums

• PCI DSS v4.0.1, Requirement 11.4: external and internal penetration tests at least once every 12 months and after any significant infrastructure or application change. Segmentation tests at least every 12 months, every 6 months for service providers. Requirement 11.3 adds quarterly vulnerability scans.
• NIS2, Article 21(2)(f): policies and procedures to assess the effectiveness of your measures. No interval in the directive; yearly is the accepted practice and matches the management’s yearly review duty.
• Cyber Resilience Act, Annex I Part II: effective and regular tests and reviews of the product’s security over the support period. No interval in the regulation; we recommend yearly plus per major release as the evidence.
• DORA, Article 26: threat-led penetration testing at least every three years for significant financial entities, plus the yearly testing programme of Article 24 and 25.
• ISO 27001, TISAX, KRITIS: no fixed interval for pentests; auditors expect yearly for exposed systems and want to see the cadence written into your vulnerability management.

If two rules apply, take the stricter one. See is a pentest mandatory for what applies to you.

What counts as a significant change

Test again, outside the yearly cycle, after any of these:

• A new authentication method, identity provider or single sign-on integration
• A new public interface: API, portal, app, remote access, customer self-service
• A change of hosting, cloud provider or network architecture
• A major release that touched authorisation, payment, file handling or data export
• A merger, an acquisition or a new site joining the network
• A security incident, in the affected systems and the paths into them
• For products: a new firmware major version, a new radio or connectivity module, a new update mechanism
• For plants: a new remote maintenance path, a new machine on the network, a change of zones and conduits

A change test is usually shorter than a full test, because it focuses on what changed: 2 to 4 days for a web application, which is 2,500 to 6,000 euros at typical rates.

Rotation for a limited budget

Nobody tests everything every year. The pattern that works:

1. Every year: the internet-facing systems, the systems with customer data or payments, and anything that changed significantly.
2. Every two years: the internal network, the cloud tenant if stable, the mobile apps if releases are rare.
3. Every three years: a broad scenario-based test, for example an assumed-breach test from a compromised workstation, or a complete-product test including the cloud backend.

Write the rotation into your vulnerability management process with the next date per system. Auditors accept a documented rotation; they do not accept “we test when we have budget”.

Between the tests

A pentest is a snapshot. Between two snapshots, a vulnerability scanner catches new CVEs and configuration drift, weekly or continuously; see penetration test vs vulnerability scan. The scanner also makes the next pentest cheaper, because the known issues are already fixed and the tester’s days go into logic and chains. A managed SOC such as Zyberdome adds the detection layer for the time in between.

How we handle it

We recommend a cadence per system in the first report and remind you before the next date. Repeat tests of a known system are faster than the first, usually by a day or two, and the price follows. Retests of fixed findings are included in every fixed-price offer. Book a free 15-minute call if you want a testing calendar for your systems.