Every penetration testing FAQ, including ours, says to test at least annually and after any significant change. That is a good default. It is also incomplete, because some frameworks demand more, some assets change faster than others, and "significant change" means nothing until you define it. A cadence you cannot explain is one an auditor will question and an attacker will not care about.
This guide turns the one-line answer into a schedule. It covers the baseline, what actually counts as a significant change, the specific frequencies that PCI DSS, SOC 2, ISO 27001 and APRA CPS 234 expect, how cadence varies by asset type, and what to do in the months between tests.
The short answer
For a business with no specific regulatory driver: a full penetration test of each important system at least once every twelve months, plus a targeted test whenever that system changes significantly. Between tests, run automated vulnerability scanning monthly or continuously so known issues do not sit unnoticed for a year.
If a framework applies to you, its cadence overrides the baseline. Several are stricter than annual.
What counts as a significant change
This phrase appears in nearly every standard and is rarely defined, so define it yourself and write it down. A reasonable definition includes any of the following:
- A new application, API or customer-facing feature, especially one that handles authentication, payments or personal data.
- A major architectural change: a migration to a new cloud platform, a move to microservices, a new identity provider.
- A change to the network perimeter: new VPN, new remote access, new internet-facing service.
- A merger, acquisition or new integration that connects your systems to someone else's.
- A significant security incident, which should trigger testing of whatever was involved.
A change that meets the definition triggers a scoped test of what changed, not necessarily a full re-test of everything. Recording the decision each time is as important as the test itself.
Cadence by framework
| Framework | Expected frequency | Notes |
|---|---|---|
| PCI DSS v4 | Internal and external pentest at least every 12 months and after significant change | Segmentation testing at least every 12 months; every 6 months for service providers (Requirement 11.4) |
| APRA CPS 234 | A systematic testing programme, frequency commensurate with rate of change and criticality | Regulated entities and their material suppliers; more often for high-change, high-sensitivity systems |
| SOC 2 | At least once per observation period | For Type II the test and retest must fall inside the window |
| ISO 27001 | Risk-based; annual is the accepted norm | Plus after significant change; evidence for A.8.8 and A.8.29 |
| Essential Eight | No pentest cadence; it is a maturity model | Pentests complement rather than replace a maturity assessment |
| No framework | Annual, plus after significant change | Scan monthly between tests |
PCI DSS is the only one that prescribes numbers in detail, and its six-monthly segmentation requirement for service providers catches people out. CPS 234 is the opposite: deliberately principles-based, which means APRA expects you to justify your frequency in writing. Our guides to ISO 27001 and SOC 2 testing cover the timing for those audits in detail.
Cadence by asset type
Frameworks set the floor. The asset itself sets the real rate, because risk follows change:
- Customer-facing web applications and APIs change constantly. Annual full testing plus targeted testing of major releases is the minimum; high-velocity teams often test twice a year.
- Mobile apps follow their release cycle. Test before major versions, and at least annually.
- Cloud environments drift. An annual configuration review plus automated posture monitoring in between catches the public bucket before someone else does.
- Internal networks and Active Directory change slowly but fail badly. Annual internal testing is usually sufficient unless a framework says otherwise.
- External perimeters should be scanned continuously and tested annually.
Building a testing calendar
Put the pieces together in one document: each in-scope system, the framework that governs it, the required cadence, the last test date, the next due date, and the owner. Add your definition of significant change and a line for each change-triggered test. That calendar is the artefact every auditor asks for and the thing that stops testing from becoming an annual panic.
Stagger engagements rather than testing everything in one month. It spreads cost, spreads remediation load on your engineers, and means a finding in one system does not arrive at the same time as findings in four others.
A worked example
Take a Sydney SaaS company with a customer web portal, a public API, a production AWS account and a small office network. It is working towards SOC 2 Type II with a July to June observation period and processes card payments through a hosted provider, so PCI DSS applies only to the integration. A defensible calendar looks like this:
- August: full web application and API penetration test, early in the SOC 2 window, with retest in October.
- November: cloud security review of the AWS account, timed after the platform migration that finished in September (a significant change).
- February: external perimeter test and a scoped test of the new partner integration launched in January.
- May: internal network and Active Directory test, before the office move in June triggers a repeat.
- Monthly: automated vulnerability scanning of everything internet-facing, with results reviewed and tracked.
Four engagements spread across the year, each tied to a reason an auditor will recognise, none landing in the same month as another. The cost is roughly the same as testing everything at once; the remediation load on the engineering team is a quarter of it.
Signals you are testing too rarely
A cadence that looked right a year ago can quietly fall behind. Watch for these:
- Major features have shipped since the last test and nobody checked whether they met the significant-change definition.
- The last report is older than twelve months and an audit, a customer questionnaire or a contract renewal is within three months.
- Monthly scans keep finding the same classes of issue, suggesting a development practice problem a pentest would diagnose.
- A new framework now applies, such as PCI DSS after taking payments in-house, or CPS 234 after winning a bank as a customer.
- There has been a security incident and the systems involved have not been tested since.
Any one of these is a reason to bring the next test forward rather than wait for the anniversary.
What to do between tests
A penetration test is a point-in-time exercise. The eleven months in between are where new vulnerabilities, new code and configuration drift accumulate. Continuous or monthly vulnerability scanning is the inexpensive way to keep watch, and our post on scanning versus pentesting explains what each is for. Pair the two and the annual test becomes a check on depth, not a yearly discovery of everything that went wrong since the last one.
If you are not sure which of your systems should be on the calendar at all, our services pages describe what each engagement covers, and a scoping call is the quickest way to turn a list of systems into a schedule.