How Often Should You Do Penetration Testing? Frequency by Framework and Risk (2026)

Quick answer: at least annually, and again after any significant change to the systems in scope. That is the shape of every framework clause that names a cadence at all, and the second half is the half people ignore. PCI DSS v4.0.1 requires internal and external penetration testing at least every 12 months and after any significant infrastructure or application upgrade or change. NYDFS 23 NYCRR 500.5(a)(1) requires "penetration testing of their information systems from both inside and outside the information systems' boundaries by a qualified internal or external party at least annually". DORA Article 24(6) requires that "at least yearly, appropriate tests are conducted on all ICT systems and applications supporting critical or important functions", and Article 26(1) adds threat-led penetration testing "at least every 3 years" for the entities it identifies.

The frameworks people most often believe mandate an annual test mostly do not. SOC 2 sets no cadence whatsoever: the strings "annual", "annually", "quarterly", "semiannual" and "at least once" return zero hits across the 2017 Trust Services Criteria. ISO/IEC 27001:2022 names no frequency anywhere. NIS2 leaves the need, scope and frequency of security testing to the entity's own risk assessment. CMMC mandates testing only at Level 3.

This page is about cadence. The prior question, which frameworks mandate a penetration test at all and which merely accept one as evidence, is answered clause by clause in our companion post on pentest evidence auditors accept. Every regulatory quotation below was read from the publisher's own text on 5 September 2026.

The frequency matrix

Four things to take from that table.

Only PCI DSS mandates a testing cadence across its general population. NYDFS mandates one for the financial entities it covers, and DORA mandates one for the financial entities it covers. Everything else is either silent or, in HIPAA's case, still a proposal.

Every mandated cadence has an "and" in it. The calendar is the floor. The event is the real obligation, and it is the one auditors reconcile against your change log.

Scanning and testing run on different clocks. PCI SSC's own comparison table puts vulnerability scanning at "at least quarterly and after significant changes" against penetration testing at "at least annually and upon significant changes". Secureframe explains why both exist: quarterly scanning is there "to catch any vulnerabilities introduced by changes that have been made to your environment in the time between your annual penetration tests".

Where no framework sets a cadence, you do, and then you are held to it. Write "annual penetration test" into a SOC 2 control description or an ISO 27001 risk treatment plan and you have manufactured a binding obligation out of nothing. Worse, in a SOC 2 Type 2 that phrasing gives the auditor a population of one, so a single late test is a 100% exception rate rather than a fraction. Our guide to SOC 2 Type 2 testing timing works through that trap.

What "significant change" actually means

Nobody defines it for you, and that is deliberate. PCI SSC's Penetration Testing Guidance is explicit that a significant change "is not prescribed by PCI DSS", that what counts depends heavily on the entity's risk assessment process and the configuration of a given environment, and that if a change could affect the security of the network or allow access to cardholder data, the entity may consider it significant. The purpose is stated plainly: testing after a significant change exists to confirm that controls assumed to be in place still work after the upgrade or modification.

So you write the definition, and then you live with it. A definition that is too loose produces an untestable obligation and an auditor finding when your change log shows work you never tested. A definition that is too tight produces monthly engagements you cannot fund. The workable middle is a named list of trigger events, agreed with whoever owns the control, and reconciled against change management quarterly.

The event-driven trigger checklist

Run an out-of-cycle test, or an in-scope retest, when any of these happens. The framework naming each trigger is given so you can defend the list to an auditor.

Infrastructure changes

• New system components deployed into the in-scope environment. (PCI DSS significant change; CMMC Level 3 significant security change)

• Replacement or major upgrade of an existing in-scope component. (PCI DSS)

• Migration between cloud providers, regions or account structures.

• Changes to supporting infrastructure such as directory services, time, logging or monitoring. (PCI DSS)

• Changes to network controls: firewall rules, security groups, VPN or zero-trust access paths.

• A material system change of any kind, for NYDFS-covered entities, which triggers a prompt scan under 500.5(a)(2) and a risk-assessment refresh under 500.9(a).

Application changes

• A new application, or a new externally reachable service, entering the in-scope boundary.

• A change to how authentication, session handling or authorization is implemented. This is the highest-yield trigger in practice and the one most often skipped.

• A new integration that grants a third party access to in-scope data.

• Material changes to how account data is captured, processed, transmitted or stored. (PCI DSS)

• Acceptance of a significant release into production, where ISO 27001 A.8.29 is applicable.

Boundary and scope changes

• Any change to segmentation controls. (PCI DSS 11.4.5, and the trigger here is any change, not a significant one)

• A change to the assessed scope or the system boundary. (PCI DSS; SOC 2 system description)

• An acquisition, a divestment, or the onboarding of a new environment inherited from either.

• A new customer tenancy model, or a change to how customer data is segregated.

External events

• A relevant incident, whether yours or a close peer's, that suggests your controls were assumed rather than verified.

• A newly weaponised vulnerability class affecting technology you run.

• A customer or regulator requiring assurance on a specific date, which is a scheduling trigger rather than a risk one but drives the same booking.

• A supervisory instruction, which DORA makes explicit: a competent authority "may, where necessary, request the financial entity to reduce or increase" the TLPT frequency.

Two practical notes. First, an out-of-cycle test does not have to be a full engagement. A change-scoped test against the affected component, documented as such, satisfies the trigger and costs a fraction of an annual. Second, a retest of previously identified findings is not a change trigger test; they are different artefacts and auditors ask for both.

Setting cadence from change rate rather than from a calendar

The mandated floor is annual. Whether annual is enough is a different question, and the honest way to answer it is with your own deployment data rather than with a vendor's recommendation.

The reasoning runs like this. A penetration test is a point-in-time assurance about a system in a specific state. Its validity decays at the rate the system changes. A platform that ships once a quarter and has not changed its authentication model in two years retains most of a test's value for most of a year. A platform that ships forty times a week, adds an externally reachable service every sprint and is actively rewriting its permissions model has consumed most of that value inside a month.

None of that is a framework requirement. It is a risk judgment, and the frameworks that decline to set a cadence say as much: NIS2's implementing regulation asks entities to "establish, based on the risk assessment... the need, scope, frequency and type of security tests", and NYDFS ties its scan frequency to the risk assessment directly.

What one test a year actually buys, and what it does not

The case for testing more often than the floor is not rhetorical, and our own data is the cleanest evidence we can offer for it.

Stingrai's State of Penetration Testing 2026 analysed 1,206 verified findings from 55 penetration tests run between October 2024 and August 2026. 92.7% of tests surfaced at least one High or Critical finding. That is the base rate on tested systems, most of which had been tested before. It is not a statement about negligent organisations; it is a statement about how quickly exploitable issues accumulate in systems that change.

The remediation numbers set the second constraint. Across findings with a tracked resolution time, the median Critical closed in 10.5 days and the median High took 38.0 days. Criticals get emergency attention. Highs get queued, and five and a half weeks is the honest planning figure for them. The dataset also carried a 0.74% false-positive rate, low enough that a finding is a finding rather than a triage exercise.

Put those together and the arithmetic on an annual-only programme is uncomfortable. One test produces a burst of findings, a fix cycle that runs into the second month, and then ten months in which change accrues with no adversarial verification against it. Quarterly scanning narrows that gap for known-class issues, which is exactly the role Secureframe describes for it, but a scanner does not find the authorization flaws, IDOR and business logic failures that dominate real breach paths. That gap between the scanner's reach and the annual test's date is the actual argument for continuous testing, and it is worth stating without inflating it: more frequent testing does not make you compliant faster, and it does not replace the engagement your auditor expects. It shortens the window in which a change is live and unverified.

Where continuous testing genuinely helps, and where it does not

Continuous testing is oversold in this market, so here is the honest split.

It helps with:

• The eleven-month gap. Coverage that runs against the surface as it changes catches issues introduced between engagements rather than at the next annual.

• The change trigger list above. Most items on that list are events a continuous programme reacts to automatically, and a scheduled engagement cannot.

• SOC 2 Type 2 populations. A control evidenced once a year is a population of one. A control evidenced continuously across the observation window is a population the auditor can sample.

• Retest turnaround. Verifying a fix within days rather than waiting for the next engagement is what turns a closed ticket into evidence.

It does not:

• Remove the mandated engagement. PCI DSS still wants a 12-month internal and external test with a documented methodology. DORA still wants TLPT every three years on live production systems. NYDFS still wants an annual test from inside and outside the boundary. Continuous coverage sits above those obligations, not instead of them.

• Replace human depth on its own. The complex authorization, business logic and chained-attack findings that matter most come from testing that reasons about the application, not from a schedule.

• Fix anything. The 38.0-day median on Highs is a remediation-capacity problem, and testing more often makes it more visible rather than smaller. Funding the fix window is the prerequisite, not the afterthought.

Stingrai delivers both models deliberately: one-time annual penetration tests for the compliance artefact, and continuous testing programmes for the coverage between them. Our PTaaS platform is where the continuous half runs.

What to write in your policy

Your policy language is the obligation an auditor holds you to, so write it once, carefully.

• State a floor, not a fixed date. "At least annually" survives a slipped week. "Every January" does not.

• Name the change trigger explicitly. "And after significant changes to the in-scope environment, as defined in section X" converts an ambiguity into a documented process.

• Define significant change in your own words, in your own document. PCI DSS declines to define it precisely because it depends on your environment. Use the trigger checklist above as the starting list.

• Include a detection and catch-up process. A documented process for noticing a missed activity, determining why, performing it as soon as possible and recording all of that turns a scheduling slip into a documented exception rather than a control failure.

• Separate the scanning cadence from the testing cadence. They are different controls with different clocks and different evidence.

• Commit to retesting, with a timeframe tied to your severity SLAs. This is what CC4.2 and PCI DSS 11.4.4 are each looking for in their own vocabulary.

• Do not promise a tester qualification you are not going to verify. If your control says "CREST-accredited third party", the auditor will check. If it says "a qualified independent tester", they will check that instead, which is a lower and more defensible bar.

Mistakes that cost more than the test

• Treating "annual" as the whole requirement. Every mandated cadence has a change trigger attached, and the change trigger is what your change log will be reconciled against.

• Inventing a cadence in a control description. SOC 2 and ISO 27001 set none. Writing one in creates an obligation and, in a Type 2, a population of one.

• Confusing quarterly scanning with quarterly testing. PCI DSS 11.3.2 is quarterly external scanning by an Approved Scanning Vendor. Requirement 11.4 testing is every 12 months. They are different controls and neither substitutes for the other.

• Reading the PCI penetration testing guidance supplement as current clause numbers. The supplement is from 2017 and cites the retired Requirement 11.3 numbering. Its cadence principle and significant-change guidance still hold; its clause references do not.

• Assuming HIPAA already requires annual testing. The 12-month requirement exists only in a proposed rule that has moved to Long Term Actions on the Unified Agenda. Plan for it; do not claim it is in force.

• Booking the annual test at the end of a SOC 2 observation window. With a 38.0-day median close on Highs, the fix and retest land outside the period.

• Never testing the segmentation. Under PCI DSS 11.4.5 the trigger is any change to segmentation controls, which is a lower bar than "significant", and it is the requirement most often missed entirely.

• Buying more frequent testing without funding remediation. Testing more often surfaces the backlog faster. It does not clear it.

How Stingrai fits

Stingrai is an offensive security firm founded in 2021, headquartered in Toronto with a London office. We are a CREST-accredited penetration testing service provider at firm level, our team has published 18 CVEs, and we hold 5.0 out of 5.0 across 19 Clutch reviews.

Our penetration testing supports your PCI DSS, SOC 2, ISO 27001, HIPAA, DORA, NIS2 and CMMC programmes by producing evidence on the cadence each one asks for: a documented methodology, a dated scope of work as its own deliverable, findings mapped to the control you are evidencing, retesting written into the engagement, and a shareable completion letter for customers who need proof without the technical detail. The compliance opinion belongs to your auditor or assessor.

We run both models on purpose, because the frameworks above need both. A one-time annual penetration test produces the artefact that satisfies a 12-month clause. A continuous testing programme covers the eleven months of change that the annual test cannot see, and produces the event-driven evidence the change triggers demand without a new procurement cycle each time.

Snipe, our autonomous web application testing agent, is custom-trained on more than 6,000 HackerOne Hacktivity disclosure reports and on skills distilled from our own testers' methodology. It hunts complex authorization, IDOR and business logic flaws rather than stopping at scanner-class bugs, performs both black box testing and white box source review, generates AutoFix pull requests, and can run as a gating check on every pull request, which is the tightest cadence available: testing at the moment the change is made rather than at the next calendar slot. Our penetration testers work alongside Snipe throughout each engagement, directing where it looks and extending the attack paths it opens, with both contributing findings across every severity.

Published pricing is on the Stingrai pricing page: the Autonomous Pentest from US$3,000 one-time and the Hybrid Pentest at US$6,800 one-time, both covering one web application and its APIs, and the same two tiers continuously at US$450 and US$1,275 per month on a 12-month engagement. The Autonomous tier carries a published No High or Critical Finding, Don't Pay guarantee. For a wider scope, request a quote.

Frequently Asked Questions

How often should you do penetration testing?

At least annually, and again after any significant change to the systems in scope. That is the pattern in every framework that sets a cadence: PCI DSS v4.0.1 requires internal and external testing at least every 12 months and after significant infrastructure or application change, NYDFS 500.5(a)(1) requires testing "at least annually", and DORA Article 24(6) requires yearly testing of systems supporting critical or important functions. Above that floor, cadence is a risk judgment driven by how fast your systems change.

Is annual penetration testing enough?

It is enough to satisfy the frameworks that require it, and often not enough to keep pace with change. Across 1,206 verified findings from 55 penetration tests in Stingrai's dataset, 92.7% of tests surfaced at least one High or Critical finding, and the median High took 38.0 days to close. On a system that ships weekly, one annual test leaves roughly ten months of change with no adversarial verification against it. Quarterly scanning narrows that gap for known-class issues; it does not reach authorization or business logic flaws.

How often does PCI DSS require penetration testing?

PCI DSS v4.0.1 requires internal penetration testing under Requirement 11.4.2 and external penetration testing under 11.4.3, both at least once every 12 months and after any significant infrastructure or application upgrade or change. Segmentation testing under 11.4.5 runs at least every 12 months and after any change to segmentation controls, and service providers move that segmentation clock to six months under 11.4.6. Quarterly external scanning by an Approved Scanning Vendor is a separate control, Requirement 11.3.2, and does not satisfy 11.4.

How often do you need a penetration test for SOC 2?

SOC 2 sets no cadence. The strings "annual", "annually", "quarterly", "semiannual" and "at least once" appear zero times across the 2017 Trust Services Criteria. Any frequency you are held to came from your own control description, a customer contract, or your compliance platform's recommendation. The binding constraint for a Type 2 is placement rather than frequency: the test has to fall inside the observation window, which our Type 2 timing guide covers month by month.

How often is a penetration test required for ISO 27001?

ISO/IEC 27001:2022 sets no penetration testing frequency, and never names penetration testing in a clause or Annex A control title. Controls flow from your risk treatment under clause 6.1.3, and the frequency that binds you is whatever you wrote into your own policy, risk treatment plan or a customer contract. The annual rhythm often attributed to ISO comes from certification body surveillance audits under ISO/IEC 17021-1, which is when the auditor visits rather than how often you test.

Does HIPAA require annual penetration testing?

Not today. The proposed HIPAA Security Rule published in the Federal Register on 6 January 2025 would add proposed 45 CFR 164.312(h)(2)(iii)(B), requiring that "penetration testing must be performed at least once every 12 months or in accordance with the covered entity's or business associate's risk analysis... whichever is more frequent", alongside vulnerability scanning at least every six months. That is a proposal. RIN 0945-AA22 has moved to Long Term Actions on the Unified Agenda, so plan for the requirement without claiming it is in force.

How often does DORA require penetration testing?

DORA sets two clocks. Article 24(6) requires that financial entities other than microenterprises "ensure, at least yearly, that appropriate tests are conducted on all ICT systems and applications supporting critical or important functions", and Article 25(1) names penetration testing as one of the test types that programme may use. Article 26(1) then requires identified entities to "carry out at least every 3 years advanced testing by means of TLPT", performed on live production systems, with the competent authority able to increase or reduce that frequency.

Does NIS2 set a penetration testing frequency?

No. The word "penetration" appears in the NIS2 directive only in its recitals, describing managed security services, never in Article 21's list of required measures. Commission Implementing Regulation (EU) 2024/2690 then makes the cadence explicitly self-set: entities must "establish, based on the risk assessment carried out pursuant to point 2.1, the need, scope, frequency and type of security tests", document the type, scope, time and results, and apply mitigating actions to critical findings.

What counts as a significant change that triggers a penetration test?

Nobody defines it for you. PCI SSC's guidance states that a significant change is not prescribed by the standard because it depends on the entity's risk assessment process and the configuration of the environment, and that a change which could affect the security of the network or allow access to cardholder data may be considered significant. In practice the defensible approach is a written trigger list covering new or replaced in-scope components, changes to authentication or authorization, new external services, changes to segmentation or scope, third-party integrations, and acquisitions, reconciled against your change log each quarter.

How often should you run a vulnerability scan compared with a penetration test?

Scanning runs roughly four times as often. PCI SSC's own comparison puts vulnerability scanning at "at least quarterly and after significant changes" against penetration testing at "at least annually and upon significant changes". Secureframe explains the logic: quarterly scanning exists "to catch any vulnerabilities introduced by changes that have been made to your environment in the time between your annual penetration tests". Our comparison of the two covers what each one proves.

Should I retest after remediation, and how quickly?

Yes, and the timing should follow your own severity SLAs rather than a fixed rule. PCI DSS 11.4.4 requires that findings be corrected and that testing be repeated to verify the corrections, so a closed ticket alone does not satisfy it. SOC 2's CC4.2 requires management to track whether deficiencies are remedied on a timely basis, which a dated retest evidences cleanly. Scope the retest into the original engagement rather than discovering it as a change order.

Does continuous testing replace the annual penetration test?

No, and any vendor saying otherwise is overselling. PCI DSS still requires a 12-month internal and external test with a documented methodology, DORA still requires TLPT every three years on live production systems, and NYDFS still requires an annual test from inside and outside the boundary. What continuous testing changes is the gap between those engagements: it shortens the window in which a change is live and unverified, produces event-driven evidence for the change triggers, and turns a SOC 2 population of one into a population an auditor can sample.

Related reading

• Pentest evidence auditors accept: SOC 2, ISO 27001, PCI DSS and CMMC, the clause-level answer to which frameworks mandate testing at all.

• SOC 2 Type 2 penetration testing timing, where the test belongs inside the observation window.

• PCI DSS penetration testing: Requirement 11.4, the clause the only broad mandate lives in.

• Does CMMC require a penetration test?, level by level through 32 CFR part 170.

• Penetration testing for Vanta, Drata and Secureframe, what each compliance platform's check requires and how often.

• Penetration testing versus vulnerability assessment, the two clocks compared.

• How to scope a penetration test, which decides what a change trigger actually covers.

References

1. PCI Security Standards Council. Information Supplement: Penetration Testing Guidance, version 1.1. September 2017, retrieved 5 September 2026. https://listings.pcisecuritystandards.org/documents/Penetration-Testing-Guidance-v1_1.pdf. Source of the quarterly scanning against annual testing comparison, the statement that a significant change is not prescribed by PCI DSS, and the organisational independence bar for testers. Predates PCI DSS v4, so its own clause references point at the retired Requirement 11.3 numbering.

2. PCI Security Standards Council. Document Library. Retrieved 5 September 2026. https://www.pcisecuritystandards.org/document_library/. Confirms PCI DSS v4.0.1 as the current standard, the source of Requirement 11.4 and its 12-month and significant-change cadences.

3. New York State Department of Financial Services. 23 NYCRR Part 500, Cybersecurity Requirements for Financial Services Companies, second amendment text effective 1 November 2023. Retrieved 5 September 2026. https://www.dfs.ny.gov/industry_guidance/regulations/final_adoptions_fs/rf_fs_2amend23NYCRR500_text_20231101_alt. Section 500.5(a)(1) annual penetration testing, 500.5(a)(2) risk-driven scanning and material-change trigger, 500.9(a) annual risk assessment, and the section 500.22 transitional periods.

4. European Parliament and Council. Regulation (EU) 2022/2554 (DORA). Retrieved 5 September 2026. https://eur-lex.europa.eu/eli/reg/2022/2554/oj. Article 24(4) independent testers, Article 24(6) yearly testing of systems supporting critical or important functions, Article 25(1) test types including penetration testing, and Article 26(1) and (2) on threat-led penetration testing every three years on live production systems.

5. European Parliament and Council. Directive (EU) 2022/2555 (NIS2). Retrieved 5 September 2026. https://eur-lex.europa.eu/eli/dir/2022/2555/oj. Article 21(2)(e) and (f), the two measures nearest to security testing, and the absence of penetration testing from the articles.

6. European Commission. Commission Implementing Regulation (EU) 2024/2690. Retrieved 5 September 2026. https://eur-lex.europa.eu/eli/reg_impl/2024/2690/oj. Annex point 6.5, requiring a security testing policy and making the need, scope, frequency and type of tests a risk-based decision by the entity.

7. US Department of Health and Human Services, Office for Civil Rights. HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information. Federal Register, Vol. 90, No. 3, 6 January 2025, retrieved 5 September 2026. https://www.govinfo.gov/content/pkg/FR-2025-01-06/pdf/2024-30983.pdf. Proposed 45 CFR 164.312(h)(2)(iii), penetration testing at least once every 12 months by a qualified person, and (h)(2)(i)(A), vulnerability scanning at least every six months.

8. Office of Information and Regulatory Affairs. Unified Agenda of Federal Regulatory and Deregulatory Actions, RIN 0945-AA22. Retrieved 5 September 2026. https://www.reginfo.gov. Confirms the HIPAA Security Rule proposal is listed under Long Term Actions.

9. AICPA and CIMA. 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (With Revised Points of Focus, 2022). Retrieved 5 September 2026. https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022. Criterion CC4.1 and its point of focus naming penetration testing, criterion CC7.1's vulnerability scanning point of focus, and the absence of any cadence language across the document.

10. ISO. ISO/IEC 27001:2022, Information security management systems. https://www.iso.org/standard/27001. The standard that names no penetration testing frequency anywhere.

11. Office of the Federal Register. 32 CFR part 170, Cybersecurity Maturity Model Certification Program. Retrieved 5 September 2026. https://www.ecfr.gov/current/title-32/subtitle-A/chapter-I/subchapter-G/part-170. CA.L3-3.12.1e at 170.14(c)(4)(xx), the only penetration testing mandate in CMMC, at least annually or on significant security change.

12. Secureframe. Preparing for a SOC 2, Type 2 Audit. Retrieved 5 September 2026. https://support.secureframe.com/en/articles/15111418-preparing-for-a-soc-2-type-2-audit. The annual external testing recommendation and the explanation of why quarterly scanning sits alongside annual testing.

13. Secureframe. FAQs: Vulnerability management: scanning, remediation, and evidence. Retrieved 5 September 2026. https://support.secureframe.com/en/articles/15111314-faqs-vulnerability-management-scanning-remediation-and-evidence. External penetration testing at least once every 12 months.

14. Vanta. Frequently Asked Question: Are Penetration tests and Bug Bounty Programs Required for my Audit? Retrieved 5 September 2026. https://help.vanta.com/en/articles/11346117-frequently-asked-question-are-penetration-tests-and-bug-bounty-programs-required-for-my-audit. The annual external testing recommendation.

15. Drata. Example Evidence for Not Monitored Controls (ISO 27001). Retrieved 5 September 2026. https://help.drata.com/en/articles/11895559-example-evidence-for-not-monitored-controls-iso-27001-revised-following-5-7-2024-updates. Penetration tests at least annually or after significant changes to the environment.

16. Stingrai. The State of Penetration Testing 2026. https://www.stingrai.io/blog/state-of-penetration-testing-2026. 1,206 verified findings across 55 penetration tests, the 92.7% High or Critical rate, the 10.5 day and 38.0 day median remediation times, and the 0.74% false-positive rate.

17. Stingrai. Pricing. Retrieved 5 September 2026. https://www.stingrai.io/pricing. Published one-time and continuous package prices for one web application and its APIs.