How Often Should You Penetration Test? Frequency, Scans, and the Retest Nobody Books
Penetration testing frequency should follow your environment's change rate: most organizations need an external penetration test every six months and an internal test at least once a year, with additional tests after major infrastructure, application, or cloud changes. Monthly vulnerability scanning tracks the gap between tests, while fix verification retests confirm that each fix actually held.
The question usually arrives with a budget line attached. "Do we need to penetration test this year?" is rarely "when should the next one run?" The calendar answer, once a year, is what the RFP template suggests and what the assessor's checklist accepts. It is also the answer that produces the laggard number: a half-life of 249 days for high-risk findings in organizations that treat the test as a one-time compliance task [2].
The number that should drive the decision is not the year, it is the change rate of your environment. CISA's KEV catalog held 1,748 entries as of October 2026, and the four most recent additions, entered between October 14 and October 16, carried federal remediation deadlines of three to ten days [1]. BOD 26-04, issued June 10, 2026, made that risk-based cadence explicit for federal systems, and the private-sector teams we work with now hold themselves to the same logic: the vulnerability clock does not pause because your test is next quarter [3].
In retest engagements, we consistently watch the scope quietly shrink. The network that changed between the test and the fix is not retested, so the clean retest describes the old scope, not the current one. A penetration test is a photograph of one environment on one day. The question is how many photographs you need to keep the film honest.
Clone Systems' position: a calendar sets the floor, not the plan. An annual test alone is a compliance artifact, and an environment that changes weekly deserves a testing rhythm: external tests every six months, internal tests yearly, monthly scanning in between, and change-triggered retests. The difference between the two approaches is measured in days, 10 versus 249 [2].
What Does "How Often Should You Penetration Test" Actually Ask?
It asks when your last validated answer about your security stopped being true. A penetration test is not a recurring check like a filter change. It is a claim with an expiration date, and the expiration is set by how fast the environment changes underneath it.
NIST SP 800-115, the technical guide to information security testing and assessment, describes testing as an ongoing process of finding vulnerabilities, analyzing them, and verifying that mitigation worked, not as an annual event [4]. The compliance overlays add the floors: PCI DSS expects an external test at least annually and after significant changes (11.4.3) [7], an internal test at least annually (11.4.2) [7], and remediation verified by retest (11.4.4) [8]. Those floors are what the assessor checks. They are not what your exposure looks like in between.
| Signal | What it tells you | Cadence it supports |
|---|---|---|
| Compliance floor (PCI DSS 11.4) | The test is current on paper | Annual minimum |
| KEV additions (1,748 entries in October 2026) | The threat set moved since the last test | Change-triggered recheck [1] |
| Monthly scan results | Patch and configuration drift between tests | Scanning in the gaps |
| Major changes (architecture, application, cloud, M&A) | The tested environment no longer exists | New or re-scoped test |
| Retest results | Whether last year's fixes actually held | Scheduled verification |
The table is the whole argument in one place: frequency is a set of clocks, not a date.
Why the Annual Penetration Test Stops Telling You the Truth
The annual test was designed for a slower world. Back then, the environment between tests was roughly the same environment as during the test. Now the gap is where the risk lives.
The CISA data shows the gap from the attacker's side. Four KEV entries added in the week of October 14, 2026 (Fortinet multiple products, BeyondTrust Remote Support, Atlassian multiple products, and Palo Alto Networks PAN-OS) carried federal due dates between October 17 and October 19, 2026, and BOD 26-04 ties the deadline to the risk of the vulnerability, not to the patch cycle [1][3]. An organization whose last external test ran six months ago has no validated answer about any of those products: not whether the version is in use, not whether the path is reachable, not whether the mitigation the vendor documented actually holds.
From the defender's side, the same gap shows up in remediation. Cobalt's 2026 State of Pentesting, built on more than 16,500 tests across nearly 3,000 organizations, puts the half-life of high-risk findings at 10 days for leading teams and 249 days for laggards [2]. Laggards are defined in the report as the organizations that treat penetration testing as a one-time compliance task [2]. The annual calendar is the most common shape of that behavior, which means the calendar itself is a risk signal. The same report finds that programmatic teams resolve 45 percent of critical findings within three days, against 10 percent for compliance-driven teams, a 4.5x gap [2].
What Should Change the Frequency of Your Penetration Tests?
A change-triggered test runs when the thing you tested is no longer the thing you have. The triggers we watch for in engagements:
- Architecture or network changes. New segments, new gateways, a changed routing path, a new cloud region. The last test says nothing about any of it, and a segmentation claim made before the change is unverified after it.
- Application changes. New features, new integrations, a rewritten login flow, a new API. Web application findings have the shortest half-lives of any class, because they sit on code that ships continuously.
- Major vendor or identity changes. A new SaaS platform, a new identity provider, a new remote access appliance. The most recent CISA batch of four KEVs was all vendor product exploits [1], and a new appliance is a new KEV surface on day one.
- Mergers, acquisitions, and new offices. The tested estate and the real estate are now different documents.
- After an incident or a near miss. The control that failed is exactly the one the test needs to re-prove.
A practical rule we give clients: if a change touches any in-scope system, the test date on the attestation should be after the change, or the change should be documented as outside the scope of the old test. The assessor will accept a documented gap for a short period. The attacker will not accept it for a single day.
How Do You Keep Coverage Between Penetration Tests?
Scanning is the bridge, and it is where most programs either overclaim or under-cover. A monthly external and internal scan, credentialed where the environment allows, tracks the patch state of the assets the test found. CISA's own framing for the KEV catalog is that it should be "an input to your vulnerability management prioritization framework" [1], and BOD 26-04 requires federal teams to monitor KEV updates and mitigate within the risk-based timelines [3]. The private-sector version of that loop is a monthly scan checked against KEV and the vendor advisories that matter to your stack.
But scanning and testing measure different things, and the coverage between tests only works when you know which is which. A scan tells you what is present; a test tells you what an attacker can do with it. The full comparison is in our post on penetration testing vs vulnerability scanning, and the scan-side cadence, quarterly as a floor, monthly for public-facing systems, and after every significant change, is covered in how often you should run vulnerability scans.
The Clone Systems Testing Rhythm Model sets five clocks for every environment:
- External test: every six months, or immediately after a significant external change.
- Internal test: at least yearly, timed against the last change that touched internal paths.
- Scanning: monthly, external and internal, checked against CISA KEV and the relevant vendor advisories.
- Change trigger: any significant change to in-scope systems restarts the relevant clock.
- Retest: every fix gets a verification date in the calendar at the time the finding is reported, not after the client remembers to ask.
The Three-Question Rhythm Test (run it before you approve the budget):
- Can I name the date of my last external test and the date of my last internal test separately?
- Have any significant changes shipped since those dates? If yes, is there a test or a documented scope decision after them?
- Do my fixes have verification dates, or do they close on a ticket comment?
If you cannot answer all three, the program is running on one clock, and one clock is a calendar, not a rhythm.
How Does Change-Driven Frequency Show Up in Compliance?
Compliance is where the calendar answer comes from, and it is worth understanding what the standard actually requires versus what the attestation implies.
PCI DSS v4.0.1 sets the floor, not the ceiling: external penetration testing at least annually and after significant changes to the environment (11.4.3) [7], internal testing at least annually (11.4.2) [7], and retesting to verify that remediation was effective (11.4.4) [8]. An organization that tests externally every six months and after each major release is not violating anything, and its evidence is stronger, because the "after significant changes" clause is exercised rather than interpreted. The internal scope question is where most programs are weakest: the systems that produce findings are usually shared management planes, identity infrastructure, and standing vendor access, not the cardholder data environment itself. Our breakdown of what the internal scope should actually cover is in why PCI DSS internal penetration testing finds the systems your scope diagram missed.
The retest requirement is the one that change-driven programs satisfy by construction and calendar programs satisfy by hope. A retest confirms the reported finding is no longer exploitable on the scoped system, and that is all it claims. Our post on why passing a retest is not the same as fixing the root cause covers the failure mode where the same finding returns next year, in a slightly different room.
For teams that also carry a SOC 2 obligation, the auditor's expectation is evidence that testing happened and that findings were addressed, and the report format matters more than the date on the cover. SOC 2 penetration testing: the report your auditor checks walks through the five points an auditor looks for.
If the question in front of you is which of these tests you actually need next, scope first and price second. Managed Penetration Testing Services starts from the systems and changes you name, and penetration test cost: what moves the number explains why two quotes for the same scope can differ by 5x.
How Clone Systems Can Help
We build the rhythm with you, in the order it has to happen:
- Scoping against your change history. We look at what has changed since your last test and size the scope to the environment you actually have. Managed Penetration Testing Services.
- The five-clock model, written into the engagement. External, internal, scanning, change trigger, and retest dates, each with a named owner, so the program survives the person who set it up.
- Retests with dates in the report. Every finding gets a verification date at issue time, so the fix is proven, not assumed.
- Continuous coverage when the calendar is not enough. If the change rate is the problem, continuous penetration testing keeps the surface tested between engagements.
Not sure where your program sits on the rhythm? Talk to our team and we will map your last test, your change history, and the clocks that are missing.
Frequently Asked Questions
How often should you penetration test? External penetration testing every six months and internal testing at least yearly is the rhythm for most organizations, with additional tests after significant changes. Compliance floors such as PCI DSS 11.4 require an annual minimum and retesting after remediation, but the environment's change rate is what sets the real cadence.
Is an annual penetration test enough? It meets the minimum compliance floor, but it leaves up to a full year where the environment is unvalidated. Cobalt's 2026 data shows organizations that treat testing as a one-time task have a 249-day half-life on high-risk findings, against 10 days for programmatic teams [2].
What counts as a significant change that requires a new test? Architecture or network changes, new applications or major releases, new identity or remote access platforms, and M&A activity. If the change touches any in-scope system, the previous test no longer describes the current environment.
How is penetration testing frequency different from vulnerability scanning frequency? Scans run monthly or better and tell you what is present; tests run on the calendar and on change triggers and tell you what an attacker can do with it. Scanning tracks the gap between tests, but it does not replace the exploitation validation that a test provides.
Do I need a retest after fixing penetration test findings? Yes. A retest verifies that the specific finding is no longer exploitable on the scoped system, and PCI DSS 11.4.4 expects exactly that verification. A clean scan is not a retest: it shows the vulnerability marker is gone, not that the exploit path is closed.
Conclusion
The calendar answer is easy, and it is what the compliance file asks for. The change-rate answer is what keeps the file honest. External tests every six months, internal tests yearly, monthly scanning checked against the KEV catalog, and retests with dates in the calendar: that is a penetration testing frequency, and the difference it makes is not a checkbox, it is the gap between 10 days and 249.
If your last test is a photograph of an environment you no longer have, the next step is not another date, it is a scope. Contact Clone Systems and we will map the clocks you are missing before you spend on the test that fills them.
References
[1] CISA, Known Exploited Vulnerabilities (KEV) Catalog, accessed October 19, 2026. Catalog listed 1,748 entries; the four most recent additions (CVE-2025-61624 Fortinet, CVE-2026-102764 BeyondTrust, CVE-2026-21589 Atlassian, CVE-2026-0322 Palo Alto Networks PAN-OS) were added October 14 to 16, 2026, with due dates October 17 to 19, 2026. https://www.cisa.gov/known-exploited-vulnerabilities-catalog [2] Cobalt, State of Pentesting Report 2026 (publisher landing page; figures from the report summary, full report is a PDF). https://resource.cobalt.io/state-of-pentesting-2026 [3] CISA, BOD 26-04: Prioritizing Security Updates Based on Risk, issued June 10, 2026. https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk [4] NIST, SP 800-115, Technical Guide to Information Security Testing and Assessment. https://csrc.nist.gov/pubs/sp/800/115/final [5] Clone Systems, Penetration Testing vs Vulnerability Scanning: Why the Difference Matters. https://www.clone-systems.com/blog/penetration-testing-vs-vulnerability-scanning [6] Clone Systems, How Often Should You Run Vulnerability Scans? https://www.clone-systems.com/blog/how-often-should-you-run-vulnerability-scans [7] Clone Systems, Why PCI DSS Internal Penetration Testing Finds the Systems Your Scope Diagram Missed. https://www.clone-systems.com/blog/pci-dss-internal-penetration-testing-scope-gap [8] Clone Systems, Why Passing a Penetration Test Retest Isn't the Same as Fixing the Root Cause. https://www.clone-systems.com/blog/why-passing-a-penetration-test-retest-isnt-the-same-as-fixing-the-root-cause [9] Clone Systems, SOC 2 Penetration Testing: The Report Your Auditor Checks. https://www.clone-systems.com/blog/soc-2-penetration-testing-the-report-your-auditor-checks [10] Clone Systems, Penetration Test Cost: What Moves the Number and Why Two Quotes for the Same Scope Can Differ by 5x. https://www.clone-systems.com/blog/penetration-test-cost-what-moves-the-number [11] Clone Systems, Managed Penetration Testing Services. https://www.clone-systems.com/managed-penetration-testing-services/